The point of the examples is to show Keycloak features. For LDAP, it's
about showing how to configure LDAP Federation provider and mappers. For
Kerberos it's SPNEGO authentication with credential delegation used in
the app.
IMO for examples it doesn't matter if you use "real" production ready
LDAP server or not. The mappers etc should work with any LDAP server
vendor. The only reason for ApacheDS is that it's Java based and easy to
run for "hello-worldish" scenario.
Same like Wildfly is using H2 by default due it's java based without any
setup required, however in production you will switch to some different
"real" database.
Marek
On 25/01/16 18:58, Stian Thorgersen wrote:
We will keep it as is for now that's for sure, we have other
things to
focus on right now.
Personally at least I don't see much value in an example that doesn't
use a real LDAP server. I wonder if anyone actually uses that example
at all.
On 25 January 2016 at 17:37, Marek Posolda <mposolda(a)redhat.com
<mailto:mposolda@redhat.com>> wrote:
Just looked at this possibility. It would mean much bigger number
of steps for people to try out examples.
For classic LDAP they will need to: download from webpage, unzip,
run, import the LDIF file
However for Kerberos it's much more steps as default ApacheDS
setup doesn't have kerberos enabled. So additionally they need to
download Apache Directory studio (more than 100 MB download),
enable kerberos server through Directory Studio, configure
interceptors, sasl principal etc.
Current programmatic configuration used in examples means that
people can run the embedded ApacheDS server in single step through
mvn exec:java . Much less pain and much easier setup.
Is the separate util/embedded-ldap module really so big issue?
Despite manual download and setup, the other possibility to get
rid of it may be to duplicate some code for ApacheDS setup into
the examples itself. It would mean some code duplication, however
util/embedded-ldap module would be removed.
Still I don't like the duplications, my preferred option is to
keep as it is.
Marek
On 25/01/16 13:07, Stian Thorgersen wrote:
> I know, but the examples should get ApacheDS from
>
https://directory.apache.org/apacheds/, not a hacked/modified
> version.
>
> On 25 January 2016 at 12:58, Marek Posolda <mposolda(a)redhat.com
> <mailto:mposolda@redhat.com>> wrote:
>
> Sure, ApacheDS is exactly what we're using in examples and
> what's used by testsuite by default. Module
> util/embedded-ldap has dependency on apache-ds and it's just
> adding few additional fixes and enhancements.
>
> Marek
>
>
> On 25/01/16 12:48, Stian Thorgersen wrote:
>> Shouldn't the examples be based on a real LDAP server
>> instead? For example
https://directory.apache.org/apacheds/?
>>
>> On 25 January 2016 at 12:36, Marek Posolda
>> <mposolda(a)redhat.com <mailto:mposolda@redhat.com>> wrote:
>>
>> On 21/01/16 13:19, Stian Thorgersen wrote:
>>> util/embedded-ldap can we move this to testsuite?
>> It's used by both testsuite and examples ("ldap" and
>> "kerberos" examples).
>>
>> That was main motivation to move them to separate
>> module, so examples are not dependent on testsuite.
>>
>> Marek
>>
>>>
>>> On 21 January 2016 at 13:18, Stian Thorgersen
>>> <sthorger(a)redhat.com <mailto:sthorger@redhat.com>>
wrote:
>>>
>>> saml/saml-core I take it that's used by client and
>>> server? Should we just move saml-core to the root?
>>> Seems unnecessary to have a parent module with only
>>> one module inside.
>>>
>>> On 21 January 2016 at 13:08, Stian Thorgersen
>>> <sthorger(a)redhat.com
<mailto:sthorger@redhat.com>>
>>> wrote:
>>>
>>>
>>>
>>> On 20 January 2016 at 23:27, Bill Burke
>>> <bburke(a)redhat.com
<mailto:bburke@redhat.com>>
>>> wrote:
>>>
>>> "backends" (jpa, mongo, infinispan) were
>>> consolidated under
>>> keycloak-model-(jpa, mongo, infinispan).
>>>
>>> Integration module was moved around into:
>>> adapters/
>>> adapters/oidc
>>> adapters/saml
>>> spi/
>>>
>>> connections, broker, social, events etc.
>>> were consolidated.
>>>
>>> Modules I did not consolidate:
>>>
>>> federation/*
>>>
>>> I kept federation separate as I'm wondering
>>> what will happen with
>>> kerberos and IBM JDK. LDAP module depends
>>> on kerberos, so I kept that
>>> separate too.
>>>
>>> events/syslog
>>>
>>>
>>> I'm deleting this. Shouldn't have been added in
>>> the first place as syslog can be done with the
>>> syslog appender for regular logging. Besides no
>>> one actually requested it.
>>>
>>>
>>> Not sure if this is something we was
>>> removable or not as it depends on a
>>> thirdparty library.
>>>
>>> client-registration/*
>>>
>>>
>>> Moved to integration. It's client lib for
>>> client registration service.
>>>
>>> wildfly/*
>>>
>>>
>>> Needs to stay as is. It's all specifics to WF
>>> and they can't be combined.
>>>
>>>
>>> I don't know much about these modules so I
>>> kept them separate.
>>> Stian/Marko can decide what they want to do
>>> here.
>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>>
http://bill.burkecentral.com
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev(a)lists.jboss.org
>>> <mailto:keycloak-dev@lists.jboss.org>
>>>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>>
>>>
>>>
>>
>>
>
>