[cas-dev] is the actual AuthenticationManagerImpl sufficient?

[Pascal Aubry]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://tp.its.yale.edu/pipermail/cas-dev/attachments/20060622/49c95c4c/attachment.html