+1 as well. Seems like a pretty good start.
Regards, Pierre-Arnaud On 10 mai 2013, at 11:16, Emmanuel Lécharny <elecha...@gmail.com> wrote: > Hi guys, > > we have a delegatedAuthenticator which is supposed to authenticate a > user against an external LDAP server. It's not working. > > In order to have it working, there are a few things that need to be > fixed, and it depends on some decisions we have to make. > > First, we have to agree on what means a delegated authentication. We > have two options here : > 1) The user is not known by the server, so we try to bind on a remote > LDAP server and if it succeeds, we create a local session > 2) The user is known by the local server, but we don't have an > associated password, so we have to bind on another LDAP server (same > process tahn for 1). > > It's easier to deal with case 1, because we can immediately see if the > user is present or not. In case 2, we will have to tell the local LDAP > server when it should look into a remote server. This can be done in two > ways : > A) As for SASL bind, we define a search base DN, and every bind under > this DN root will have to be authenticated by an external LDAP server > B) Or we define an Administrative Area, and an associated subentry, > which defines the scope of entries that are to authenticate on a remote > LDAP server > > I must say that the B option is appealing, as it offers way more > possibilities. It's also more complex to implement and handle. > > I would suggest we start with option A. > > There is more to do : as it's about authenticating, the userPassword > will be transmitted to the remote LDAP server. It *has* to be done > through a secure connction (either LDAPS or through the user of a > startTLS extended operation). In both cases, some configuration is needed. > > I propose to implement option 2-A, with a secured connection configuration. > > Thoughts ? > > -- > Regards, > Cordialement, > Emmanuel Lécharny > www.iktek.com >