On Fri, Nov 19, 2010 at 11:41 AM, Emmanuel Lecharny <firstname.lastname@example.org>
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?
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 ...
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...