directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kiran Ayyagari <kayyag...@apache.org>
Subject Re: Writing a specific Authenticator, and add some configuration for iy
Date Fri, 19 Nov 2010 10:43:11 GMT
On Fri, Nov 19, 2010 at 12:37 PM, Alex Karasulu <akarasulu@apache.org> wrote:
>
>
> 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)?
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

Mime
View raw message