[keycloak-dev] module re-org complete?
Marek Posolda
mposolda at redhat.com
Mon Jan 25 15:42:51 EST 2016
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 at redhat.com
> <mailto:mposolda at 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 at redhat.com
>> <mailto:mposolda at 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 at redhat.com <mailto:mposolda at 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 at redhat.com <mailto:sthorger at 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 at redhat.com <mailto:sthorger at redhat.com>>
>>>> wrote:
>>>>
>>>>
>>>>
>>>> On 20 January 2016 at 23:27, Bill Burke
>>>> <bburke at redhat.com <mailto:bburke at 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 at lists.jboss.org
>>>> <mailto:keycloak-dev at lists.jboss.org>
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160125/52eec8f8/attachment-0001.html
More information about the keycloak-dev
mailing list