On Fri, Nov 19, 2010 at 12:29 PM, Kiran Ayyagari <kayyagari@apache.org> wrote:
On Fri, Nov 19, 2010 at 12:14 PM, Alex Karasulu <akarasulu@apache.org> wrote:
> 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?
>
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)?

Are we tracking login attempts when the bind principal is non-existant and if so where we doing that? 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.

>>
>> 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