[cas-dev] PrincipalConverter

[Stephen A. Cochran]

I guess I'm not sure why a new class is needed.

In our setup we use x509 (our own trusted CA) and a web form to  
authenticate users. The web form goes against our own directory  
server (called the Dartmouth Name Directory (DND), basically the same  
concept as LDAP). Both return the user's conical name, either from  
the cert itself or from the directory.

One of our needs is to provide our unique ID to applications, so both  
the x509 and the User/Pass auth handlers create a DartmouthPrincipal  
instead of a standard Principal. This extended class has several  
extra attributes which are filled in by the DartmouthPrincipal class  
from the full conical name.

So here's an example to make it clearer.

1.  Say I don't have a cert. At the web form I type in "sac" and my  
password. "sac" are my initals, our directory system allows users to  
choose their own nicknames, and while not guaranteed to be unique,  
users learn to pick unique ones for quick signons.

2. "sac" and the pass are sent to the DND server and the nickname is  
expanded to the full conical name "Stephen A. Cochran". Assuming my  
pass is accepted, the auth handler creates a DartmouthPrincipal  
passing in "Stephen A. Cochran". The only difference here from using  
a cert is the cert would already have the full conical name and is  
authenticated. It would then pass the name from the cert into a  
DartmouthPrincipal as above.

3. The DartmouthPrincipal class constructor fills in the user field  
with "Stephen A. Cochran at DARTMOUTH.EDU" (see tangent at end on the  
reason for this). This matches our Kerberos principals and is  
guaranteed to be unique. But names change (marriage, divorce, etc),  
so best practices are that applications tie users to their UID, which  
in my case is 66035. The DartmouthPrincipal was extended to include  
the UID, EMAIL, and another internal number specific to Dartmouth.  
All of these are filled in from the DND via a search. Notice that the  
individual Auth Handlers don't have to duplicate this, the  
DartmouthPrincipal handles it all.

4. XML response is sent back with the username of "Stephen A.  
Cochran at DARTMOUTH.EDU". The response has been extended to include the  
uid, email, etc so no application has to add LDAP or DND code, we  
want to provide anything that an app might need to store/use about  
the user that is already available in the main directory server.

In this way you could extend the principal class to take a incoming  
name from the cert and then match it against the local UID. All the  
auth handlers would create instances of your extended principal  
instead of the default one. Or if you dont' want to change the code  
in the auth handlers, just rewrite the default Principal class.

Steve Cochran
Dartmouth College


Tangent: We also specifically chose to add the "@DARTMOUTH.EDU" to  
the end of the user as our way to define "realms". This allows us to  
authenticate against different user stores but still allow  
applications to decide who is authorized. My default example is  
authenticating students that have applied to Dartmouth to check their  
application status. They need to authenticate to a dartmouth system,  
but they are not part of the main Dartmouth directory yet. We wanted  
one WebSSO to handle these different user stores, and so we tag each  
username with a realm to let apps choose what realms to allow in. The  
admissions system should let is users from the admissions oracle  
table but the library or email system shouldn't.