On Fri, Nov 19, 2010 at 12:37 PM, Alex Karasulu <akaras...@apache.org> wrote: > > > On Fri, Nov 19, 2010 at 12:29 PM, Kiran Ayyagari <kayyag...@apache.org> > wrote: >> >> On Fri, Nov 19, 2010 at 12:14 PM, Alex Karasulu <akaras...@apache.org> >> wrote: >> > Hi Emmanuel, Antione, >> > >> > On Fri, Nov 19, 2010 at 11:41 AM, Emmanuel Lecharny >> > <elecha...@gmail.com> >> > wrote: >> >> >> >> Hi guys, >> >> >> >> yesterday, we had an interesting convo with Antoine, about the >> >> definition >> >> of a dedicated Authenticator, and how to configure it. >> >> >> > >> > Excellent. Thanks for posting to the ML about it. >> > >> >> >> >> First, the Authenticator interface can be implemented but it's probably >> >> a >> >> better idea to extend the AbstractAuthenticator, as it brings some >> >> references to teh underlying DirectoryService for free, plus some >> >> default >> >> implementations to init and dispose the Authenticator. One thing to >> >> take >> >> care of is the PasswordPolicy which can be enabled or disabled. We have >> >> to >> >> determinate the best way to deal with this service. >> >> >> > >> > PasswordPolicy AFAICT is something that kicks in when updating or >> > creating a >> > new password. This mechanism of delegating authentication to some >> > external >> > authentication service in this case AD does not change the password. >> > Hence >> > why I'm thinking we don't need to worry about PP. >> > Or am I missing something here? >> > >> PP also comes into picture while performing a bind and compare(of >> password) operations >> an e.x to determine the number of failed authentication attempts >> but all this makes sense only if the user entries are stored in the >> local server (ApacheDS in this case). > > Are we tracking login results (successes/failures) per user in their profile > (LDAP entry)? yes we do and these details are stored in the user entry itself > Are we tracking login attempts when the bind principal is non-existant and > if so where we doing that? we cannot, if we don't have the user entry locally on the server > We should also perhaps track the last IP where > the login occurred to prevent those trying to dictionary attack via some > account but this is not so much related to PP. >> yeah >> >> >> >> Another aspect is the Authenticator configuration : how to inject it >> >> and >> >> have it available when the server is stopped and restarted? The >> >> solution is >> >> probably to extend the existing configuration, which is based on the >> >> DIT. >> >> That means defining a specific Bean, plus the associated OC and AT. We >> >> have >> >> to think about it, and I would suggest we try to write a prototype that >> >> demonstrates the way to extend the configuration. It has to be >> >> documented, >> >> as the Authenticator is an extension point. >> >> >> > >> > Yes some configuration will be needed to activate and leverage this >> > Authenticator. >> > I do understand that there is some limited time and we need a simple >> > implementation specifically for AD (most users will use this external >> > authentication service) which is a great starting point. However let me >> > post >> > some ideas that I had very early on about this matter that several >> > perspective clients years ago expressed they needed. >> > First though before going on I want to mention that this is getting >> > really >> > close in nature to what SASL was designed for but I think this mechanism >> > might be much more flexible. With that let me continue ... >> > Prescriptive Delegation >> > --------------------------------- >> > Not every principal or user in ApacheDS will need to be delegated. >> > Essentially this comes down to selective delegation. Whether to use >> > ApacheDS >> > authentication directly, or delegate and to which external >> > authentication >> > mechanism to delegate to is something that users mentioned they would >> > like >> > with this capability. Theirs even a more acute case where sometimes the >> > binding principal might not even exist in ApacheDS yet you want >> > delegation >> > to occur. >> > The holistic means to solve this problem is by using the administrative >> > model to specify regions of the DIT you can dice and slice to have fine >> > grained control over authentication delegation. With the administrative >> > model you can specify subtree specifications and refinements that will >> > select specific entries in the DIT. When a bind occurs against selected >> > areas different delegation mechanisms can be associated with those >> > selections using subentries associated with them. This prescriptive >> > specification of selected entries allows you to specify bind principals >> > and >> > DIT regions that do not even exist and still enable delegated >> > authentication. This might be good especially if you don't want to deal >> > with >> > recreating entries for all users in AD for example. >> > Multiple External Authentication Mechanisms >> > ---------------------------------------------------------------- >> > Now you might not just be delegating to AD but to for example OpenID. So >> > it >> > would be nice to be able to allow for any kind of delegated >> > authentication >> > to occur. The delegation machinery leveraging the administration model >> > for >> > selection can be generic yet the subentries that map the selection to an >> > external authentication mechanism can use pluggable mechanisms like AD >> > or >> > OpenID. Even PAM like behavior can be enabled in a stack. >> > >> > LDAP Principle to External Mechanism Mapping >> > -------------------------------------------------------------------- >> > Whether or not the bind principal exists inside ApacheDS or not, we may >> > have >> > to transform or rather map that principal into the namespace of the >> > external >> > authentication mechanism. The way this is done will be mechanism >> > dependent >> > obviously. >> > If prescriptive delegation occurs leveraging the administrative model >> > then >> > it's possible to have 1:1 mapping between ApacheDS principals to >> > ActiveDirectory principals without the need to have mirrored entries in >> > ApacheDS for ActiveDirectory users. >> > If prescriptive delegation is not used and AD users are mirrored in >> > ApacheDS >> > with a 1:1 mapping of distinguishedNames then there's no need for >> > mapping. >> > Users will have to set out to design their DIT in this manner to reflect >> > their AD layout of users. This might be tedious and cause other >> > problems. >> > Anyways without the 1:1 mapping even when the external authentication >> > mechanism is another LDAP server like AD, we're going to have to manage >> > principle name transformations/mappings. >> > Just wanted to transfer these thoughts to the group but please don't >> > presume >> > I am expecting these approaches to be implemented in the first >> > incarnation >> > or at all even. This is knowledge gathered over years from enterprise >> > user >> > feedback and we should have them at least in mind. >> >> >> >> I'm pretty sure it's not such a big deal, but we need time, and we have >> >> littel :) I would suggest we follow closely Antoine's effort and try to >> >> leverage what he is doing to improve the server *and* the >> >> documentation... >> >> >> > >> > +1 >> > -- >> > Alex Karasulu >> > My Blog :: http://www.jroller.com/akarasulu/ >> > Apache Directory Server :: http://directory.apache.org >> > Apache MINA :: http://mina.apache.org >> > To set up a meeting with me: http://tungle.me/AlexKarasulu >> > >> >> >> >> -- >> Kiran Ayyagari > > > > -- > Alex Karasulu > My Blog :: http://www.jroller.com/akarasulu/ > Apache Directory Server :: http://directory.apache.org > Apache MINA :: http://mina.apache.org > To set up a meeting with me: http://tungle.me/AlexKarasulu >
-- Kiran Ayyagari
