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