[cas-dev] is the actual AuthenticationManagerImpl sufficient?
Scott Battaglia
scott_battaglia at rutgers.edu
Thu Jun 22 23:49:48 EDT 2006
AuthenticationManagers currently do do everything. They've just broken
it down into subcomponents to allow for code re-use and to make it
easier to understand. It makes sense to continue to keep the actions
separate as authentication and resolving are two separate actions (I can
authenticate you without ever really knowing who you are).
Its no more difficult to write an AuthenticationManager that does
everything vs. an AuthenticationManager that follows the same algorithm
but delegates to the proper subcomponents (i.e. AuthenticationHandler,
CredentialsToPrinciapalResolver, etc.). In fact, the latter is better,
as it allows us to more easily re-use code and leverage other people's
contributions.
There are many scenarios where the AuthenticationHandler is not the only
actor that knows how to resolve credentials. An AuthenticationHandler's
only purpose is to validate credentials, i.e. X.509 certificates. In
some cases this means that it could know exactly what needs to be done
to resolve that to a Principal, but it many cases it does not. I.e. in
your LDAP example, the handler knows where the user information is
stored. However, in some cases, all an AuthenticationHandler does it
validate the credentials (i.e. the X.509 Certificate) without ever being
able to resolve the credentials or knowing where to look to resolve.
-Scott
Pascal Aubry wrote:
> Scott Battaglia wrote:
>> It seems what we are looking for is merely a way to associate an
>> authentication handler with a CredentialsToPrincipalResolver (and
>> optionally, the MetaDataPopulators).
>>
> Exactly.
>> Basically, we need an implementation of the AuthenticationManager that
>> says if AuthenticationHandler X was successfully executed (and return
>> trued), run CredentialsToPrincipalResolver Y rather than loop through
>> trying to find the correct CredentialsToPrincipalResolver.
>>
>> Is that correct?
>>
> This is one way to see it. I think that there is a more simple way to
> do it. Authentication managers would do everything, i.e.:
>
> * authenticate
> * resolve the credentials to a principal
> * populate the metadata
>
> For each handler such as supports(credentials) == true, call
> authenticate(credentials). The signature of this last method differs:
>
> * it would return null if authentication simply fails (i.e. next
> handlers should be tried)
> * it would throw an AuthenticationException on failure (i.e. no
> other handler should be tried)
> * on authentication success, it would return an Authentication
> instance, made up of:
> o the Principal, resolved by the handler
> o the metadata
>
> /**
> * Method to authenticate, resolve the principal and get the
> metadata that
> * corresponds to the authentication.
> *
> * @param credentials The credentials to check.
> * @return an Authentication instance on success, null on failure.
> * @throws AuthenticationException if the authentication failed
> and next handlers should be skipped.
> */
> Authentication authenticate(Credentials credentials);
>
>> And AuthenticationManager of this type should not be difficult to create.
>>
> The one shown above should also be very easy to write (even easier),
> and I think it fits the best to our needs.
> In a way, what I say is 'credentialsResolver X and MetadataPopulator X
> should be called if AuthenticationHandler X succeeds', when you say
> something more general: 'credentialsResolver Y and MetadataPopulator Z
> should be called if AuthenticationHandler X succeeds'. IMHO, no need
> to associate credential resolvers and metadata populators to
> authentication handlers, since the authentication handler itself is
> the (only) actor that knows how to resolve the credentials and
> populate metadata.
> Do you see cases where it would not be the case?
> PA
>> -Scott
>>
>> Pascal Aubry wrote:
>>
>>> Velpi wrote:
>>>
>>>
>>>>>> CAS supports multiple AuthenticationHandlers through the usage of
>>>>>> the default AuthenticationManagerImpl (with the option for people to
>>>>>> provide their own AuthenticationManager).
>>>>>>
>>>>>>
>>>>> One thing that can not be done with the actual GH is aliasing, let me
>>>>> explain. Three years ago, a French working group, made up of Fench
>>>>> experts and driven by our Ministry of Education, emitted
>>>>> recommendations on the way identity management should be done in
>>>>> French schools and universities (I was part of the group, named AAS -
>>>>> Authentication, authorization and SSO). One of recommendations was
>>>>> aliasing, i.e. letting users authenticate with an alias they choose
>>>>> (up to the identity provider to insure that both logins and aliases
>>>>> are unique). This is impossible with the actual GH since the main
>>>>> authentication class (the one that calls specific handlers)
>>>>> implements WatchfulPasswordHandler, when TrustHandler was needed.
>>>>> There is a real need for this in our community, so I can not go on
>>>>> with new developments without adding this to my roadmap (except if it
>>>>> is possible already with the CAS3, please confirm).
>>>>>
>>>>>
>>>> I think you can do that now already, up to a certain level. Aliasing
>>>> for authentication shouldn't be a problem when using the search&bind
>>>> LDAP handler.
>>>> I'm trying to solve a similar thing for x509 logins right now:
>>>> Build a custom CredentialsToPrincipalResolver that does a lookup in
>>>> the user repository to search the right principal for the alias (in
>>>> the x509 case the "alias" is part of the certificate). (this means we
>>>> can use username/password and x509 interchangeable, possibly forcing
>>>> users with an attribute in the repository)
>>>>
>>>>
>>> Yes, aliasing works with the search&bind LDAP handler (i.e. users can
>>> provide alias/password to log in), but the netId is the alias, not the
>>> uid (i.e. the application receive the alias when validating tickets).
>>> This is obviously not what we want (just think of logging and attribute
>>> retrieval at application-level).
>>>
>>>
>>>
>>>>> However, I am not satisfied with AuthenticationManagerImpl, let me
>>>>> explain you why (maybe I am wrong because I did not spend much time
>>>>> on it). I would like to rely on several handlers, and I would like
>>>>> all the handlers to provide the 'aliasing' feature (see above). With
>>>>> the AuthenticationManagerImpl actually provided, the authentication
>>>>> id performed this way:
>>>>> stage 1. all the authentication that support the credentials supplied
>>>>> are tried until one succeeds.
>>>>> stage 2. all the principal resolvers (that also support the
>>>>> credentials) are tried until one succeeds.
>>>>> If this architecture fits with most of the needs, it is clearly not
>>>>> sufficient if we have several handlers, some of them implementing the
>>>>> aliasing feature. In this case, the handler that authenticates is the
>>>>> only one that can resolve the principal. BTW, I think it is the same
>>>>> with metadata populators.
>>>>>
>>>>>
>>>> I don't see the problem here since the failed resolvers/handlers will
>>>> not cause any problems, then again I might be missing sth...
>>>> However last week it also came to my mind that in some situation it
>>>> might be better to be able to appoint a certain Cred2PrincipResolver
>>>> to a certain authHandler. (or assigning groups to groups or so)
>>>>
>>>>
>>>>
>>>>> I do not see how we can use AuthenticationManagerImpl, for instance
>>>>> if authenticating with two LDAP directories, with two possibilities:
>>>>> 1. bind with the credentials supplied (may be successful if the netId
>>>>> is a uid)
>>>>> 2. search the DN that corresponds to the username (thanks to a filter
>>>>> on an 'alias' LDAP attribute), and then bind with the DN and the
>>>>> passsword supplied (may be successful if the netId is an alias).
>>>>> This probably needs further developments, I really need your opinion
>>>>> on this.
>>>>>
>>>>>
>>>> If I'm not mistaken, 1&2 are performed automatically by the
>>>> BindLdapAuthenticationHandler (does search&bind). It can also be
>>>> configured to be succesfull if the netid should be equal to another
>>>> LDAP attribute (I'm sure the genericHandler supports this too because
>>>> we're using that now).
>>>>
>>>>
>>> It does but very inefficiently, let me explain a little deeper.
>>> Let us stand that users are authenticated against two LDAP directories
>>> (A & B), identified with their alias (the dn/uid is searched in the
>>> directory thanks to a filter based on the 'alias' LDAP attribute) and
>>> authenticated by binding to the directories (the dn/uid and the password
>>> are used to connect to the directory, and the authentication is
>>> successful if the connection succeeds).
>>> If using the actual AuthenticationManagerImpl, two principal resolvers
>>> should be called, one for each directory. The role of those resolvers
>>> would be to ask each directory 'what is the uid that corresponds to this
>>> alias?'.
>>> Obviously, this question should only be asked to the directory with
>>> which the user has been authenticated.
>>> Is it clearer now?
>>> PA
>>>
>>>
>>>
>> _______________________________________________
>> cas-dev mailing list
>> cas-dev at tp.its.yale.edu
>> http://tp.its.yale.edu/mailman/listinfo/cas-dev
>>
>
>
> --
> http://perso.univ-rennes1.fr/pascal.aubry
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> cas-dev mailing list
> cas-dev at tp.its.yale.edu
> http://tp.its.yale.edu/mailman/listinfo/cas-dev
>
More information about the cas-dev
mailing list