[cas-dev] PrincipalConverter

[Velpi]

Hi,

I would like to introduce what I believe is a new concept to CAS. I seem to have 
implicitly built that last week, but I would like to make it more general so it 
*may* be adopted in the general CAS code. It *might* be a solution to what 
Pascal Aubry called "aliasing" in a recent discussion.

Our use case:
Login with client certificate, client certificate is issued by a totally 
independent (national) organisation. The principal that is extracted from the 
certificate does not contain our local userID, but all our applications are 
expecting the institution's uid. So the certificate principal needs to be 
converted a principal that is our local userID that the user would use when 
doing a username/password login.

Our current solution (the code for this is now functional):
* Tomcat clientAuth
* authHandler: standard X509CredentialsAuthenticationHandler trusted issuer
* x509CredToLDAPPrincipalResolver:
- gets a principal using a standard 
X509CertificateCredentialsToIdentifierPrincipalResolver
- uses that principal to search LDAP and create a new principal from an LDAP 
attribute
[user is authenticated]


I am thinking of generalizing the idea of the "x509CredToLDAPPrincipalResolver" 
to an adapter that is configured to use a CredentialsToPrincipalResolver and 
then (a list of) what I would like to call a "PrincipalConverter".

That would change part of my use case only very little to this:
...
* authHandler: standard X509CredentialsAuthenticationHandler
* credentialsToPrincipalConverterAdapter:
- X509CertificateCredentialsToIdentifierPrincipalResolver gets principal
- LDAPPrincipalConverter searches the principal in LDAP and creates a new 
principal from an attribute value.


That would also enable the following use case, without any new code:
* authHandler: standard ...LdapAuthenticationHandler
* credentialsToPrincipalConverterAdapter:
- standard UsernamePasswordCredentialsToPrincipalResolver gets principal
- LDAPPrincipalConverter searches the principal in LDAP and creates a new 
principal from an attribute value.

I think this last use case will enable the possibility of "aliasing", no? It 
would definitely create a lot of extra flexibility in the login process.
If this can be combined with the idea of calling a specific PrincipalRevolver 
from an (a group of) authHandler(s), the initial authentication could be done 
very flexible and very efficiently (without giving in on security, I may hope).


Please be so kind to share any thoughts about this...


-- Velpi