[cas-dev] is the actual AuthenticationManagerImpl sufficient?

[Scott Battaglia]

It seems what we are looking for is merely a way to associate an 
authentication handler with a CredentialsToPrincipalResolver (and 
optionally, the MetaDataPopulators).

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?

And AuthenticationManager of this type should not be difficult to create.

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