directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <akaras...@apache.org>
Subject Re: Writing a specific Authenticator, and add some configuration for iy
Date Fri, 19 Nov 2010 10:14:39 GMT
Hi Emmanuel, Antione,

On Fri, Nov 19, 2010 at 11:41 AM, Emmanuel Lecharny <elecharny@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?


> 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

Mime
View raw message