<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jul 15, 2015 at 3:57 AM, Ioannis Kakavas <span dir="ltr"><<a href="mailto:ikakavas@noc.grnet.gr" target="_blank">ikakavas@noc.grnet.gr</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello all,<br>
<br>
My use case is that the IdP needs to be able to authenticate users<br>
against two different LDAP directories. The tricky part is that users<br>
can be non exclusively in both with the same uid ( but with potentially<br>
different password ). In a sense, we would like the second directory to<br>
act as a fallback. If the password of the user is not correct for<br>
the first directory, the second should be tried.<br>
<br>
I have configured the IdPv3.1.2 as stated in<br>
<a href="https://wiki.shibboleth.net/confluence/display/IDP30/LDAPAuthnConfiguration#LDAPAuthnConfiguration-MultipleDirectories" rel="noreferrer" target="_blank">https://wiki.shibboleth.net/confluence/display/IDP30/LDAPAuthnConfiguration#LDAPAuthnConfiguration-MultipleDirectories</a><br>
( using anonSearch instead of bindSearch )but I get an error because<br>
it finds 2 DNs for the user, one in each directory.<br></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">ShibUserPassAuth {<br>
<br>
<br>
   edu.vt.middleware.ldap.jaas.LdapLoginModule sufficient<br>
      ldapUrl="url1"<br>
      baseDn="base1"<br>
      tls="true"<br>
      userFilter="uid={0}";<br>
<br>
   edu.vt.middleware.ldap.jaas.LdapLoginModule requisite<br>
    ldapUrl="url2"<br>
      baseDn="base2"<br>
      tls="true"<br>
      userFilter="uid={0}";<br>
};<br>
<br></blockquote><div><br></div><div>I think this is your best course of action right now, if what you want is failover when the first authentication fails.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Any suggestions on how this can be achieved using the<br>
aggregateAuthenticator ?<br></blockquote><div><br></div><div>It can't right now, although feel free to file a feature request for this.</div><div><br></div><div>--Daniel Fisher</div><div><br></div></div></div></div>