Maybe somebody else in the EG (Arjan, myself, Alex or who has time and
feels comfortable) could review and merge the PR. Given there's also still
an older "soteria" module we might want to get rid of, I created a "0.1"
tag in that repo, so any changes could be compared to that snapshot or if
necessary even rolled back.
Regards,
Werner
On Wed, Feb 17, 2016 at 1:50 PM, Rudy De Busscher <rdebusscher_at_gmail.com>
wrote:
> I have implemented something to support the scenario I described earlier.
> (PR to the repo)
>
> I didn't had the time to check the Links that you gave me Arjan, to see
> what the other implementations use as names. Nor the Picketlink and Elytron
> links specified by Pedro. I'll probably look at them later.
>
> So feel free to propose better names for the members of the annotations or
> give feedback on the code.
>
> With a second example app, I showed it how it can work.
>
>
>> *_at_LdapIdentityStoreDefinition(*
>> * url = "ldap://localhost:33389/",*
>> * baseDn = "uid=ldap,ou=apps,dc=jsr375,dc=net",*
>> * password = "changeOnInstall",*
>> * searchBase = "dc=jsr375,dc=net",*
>> * searchExpression = "(&(uid=%s)(objectClass=person))",*
>> * groupBaseDn = "ou=group,dc=jsr375,dc=net"**)*
>
>
> Uses the search of the caller within the tree.
>
> The original definition still works and gets selected when *baseDn* isn't
> specified.
>
> regards
> Rudy
>
>
>
>
> On 17 February 2016 at 03:13, Pedro Igor Silva <psilva_at_redhat.com> wrote:
>
>>
>> Hi,
>>
>> We have some ongoing work in WildFly Elytron[1] too. There you can
>> find authentication, attribute mapping, role mapping and group mapping.
>>
>> You can also take a look at PicketLink LDAPIdentityStore [2], which
>> was tested against different implementations. This one also provides some
>> query capabilities.
>>
>> Regards.
>> Pedro Igor
>>
>> [1]
>> https://github.com/wildfly-security/wildfly-elytron/tree/master/src/test/java/org/wildfly/security/ldap
>> [2]
>> https://github.com/picketlink/picketlink/blob/master/modules/idm/impl/src/main/java/org/picketlink/idm/ldap/internal/LDAPIdentityStore.java
>>
>> ----- Original Message -----
>> From: "arjan tijms" <arjan.tijms_at_gmail.com>
>> To: jsr375-experts_at_javaee-security-spec.java.net
>> Sent: Tuesday, February 16, 2016 8:06:42 PM
>> Subject: [jsr375-experts] Re: Feedback LDAP implementation of Identity
>> Store
>>
>> Hi,
>>
>> On Tue, Feb 16, 2016 at 10:02 PM, Rudy De Busscher <rdebusscher_at_gmail.com
>> >
>> wrote:
>>
>> > The more general approach is
>> >
>> > 1. Get a connection to the LDAP server.
>> > 2. Bind as the application user.
>> > This user should have enough permissions to search the area of LDAP
>> where
>> > users are located.
>> > 3. Search for the DN (distinguished name) of the user to be
>> authenticated.
>> > 4. Bind as user to be authenticated using DN from step 3.
>> >
>>
>> Yes, this sounds as another viable option. This is indeed what I meant
>> earlier, I just implemented one way (the way we happened to use), but
>> there
>> are quite an amount of other ones.
>>
>>
>>
>> > And thus I'm afraid that each Application server will keep his own
>> > implementation of the LDAP store, with all the additional features not
>> > possible with the standard parameters we have defined for the
>> > *LdapIdentityStoreDefinition* annotation.
>> >
>>
>> Yes, that's indeed what you often see. Java EE defines a standard data
>> source definition, but the standardised parameters are a little bit poor.
>> The native ones offered by nearly every server are much richer. Still, for
>> many purposes the standard data source is good enough.
>>
>> What we could do is carefully analyse what options all existing LDAP
>> identity stores have. The following links may be of help:
>>
>>
>> https://docs.jboss.org/jbosssecurity/docs/6.0/security_guide/html/Login_Modules.html
>> https://docs.oracle.com/cd/E19776-01/820-4495/ggkuk/index.html
>> http://docs.oracle.com/cd/E15523_01/web.1111/e13707/atn.htm#SECMG170
>>
>> https://tomcat.apache.org/tomcat-9.0-doc/realm-howto.html#Standard_Realm_Implementations
>> http://caucho.com/resin-4.0/admin/security-overview.xtp#Authenticators
>>
>> http://www.eclipse.org/jetty/documentation/9.2.6.v20141205/configuring-security-authentication.html#configuring-login-service
>>
>> If we have most of the options the LDAP stores of these servers have, we
>> should be reasonably good to go.
>>
>> Where the license allows it it may also be instructive to look at the
>> source code of existing implementations. GlassFish at least should be
>> compatible.
>>
>> For extra options/features that each vendor may want to introduce there
>> are
>> at least three options I think:
>>
>> 1. The vendor offers a second LDAP identity store with extended options
>> next to our standardised one. This extended store does implement the
>> IdentityStore interface, and the vendor offers some proprietary way to
>> selected and configure it (e.g. a @com.vendor.ExtendedLDAPStoreDefinition)
>>
>> 2. The existing vendor's LDAP identity store is being used, and we offer a
>> bridge identity store that bridges to this. The bridge effectively wraps
>> whatever proprietary store is configured via whatever proprietary method.
>> This kind of bridge is useful for more situations I think.
>>
>> 3. Like JPA's query hints and @DataSourceDefinition we offer some kind of
>> properties list or map, so vendor specific properties can be set. The most
>> popular of these can be standardised in a later revision of JSR 375.
>>
>> Thoughts?
>>
>> Kind regards,
>> Arjan Tijms
>>
>
>