Aggregate Authenticator LDAP multiple directories

[Daniel Fisher]

On Wed, Jul 15, 2015 at 3:57 AM, Ioannis Kakavas <ikakavas at noc.grnet.gr>
wrote:

> Hello all,
>
> My use case is that the IdP needs to be able to authenticate users
> against two different LDAP directories. The tricky part is that users
> can be non exclusively in both with the same uid ( but with potentially
> different password ). In a sense, we would like the second directory to
> act as a fallback. If the password of the user is not correct for
> the first directory, the second should be tried.
>
> I have configured the IdPv3.1.2 as stated in
>
> https://wiki.shibboleth.net/confluence/display/IDP30/LDAPAuthnConfiguration#LDAPAuthnConfiguration-MultipleDirectories
> ( using anonSearch instead of bindSearch )but I get an error because
> it finds 2 DNs for the user, one in each directory.
>

That documentation is specific to DN resolution, and it does not aggregate
the entire authentication process. It treats several disparate directories
as a single authentication source, only one LDAP bind is attempted. Since
your users exist in both directories, it will always resolve only the first
DN and consequently attempt authentication against that directory. A user
attempting the password for the second directory will never succeed. If
you're using allowMultipleDns the expectation is that the user records in
each directory are the same for the purposes of authentication.

ShibUserPassAuth {
>
>
>    edu.vt.middleware.ldap.jaas.LdapLoginModule sufficient
>       ldapUrl="url1"
>       baseDn="base1"
>       tls="true"
>       userFilter="uid={0}";
>
>    edu.vt.middleware.ldap.jaas.LdapLoginModule requisite
>     ldapUrl="url2"
>       baseDn="base2"
>       tls="true"
>       userFilter="uid={0}";
> };
>
>
I think this is your best course of action right now, if what you want is
failover when the first authentication fails.


>
> Any suggestions on how this can be achieved using the
> aggregateAuthenticator ?
>

It can't right now, although feel free to file a feature request for this.

--Daniel Fisher
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20150716/7788db28/attachment.html>