Several identity questions

[Andrew Petro]

Steve,

>Hopefully I didn't miss the answers to these in the archives...
>
>If you configure CAS to authenticate against different backend stores  
>such as multiple LDAP directories, or LDAP and an oracle table, does  
>the CAS protocol define any way to identify the "realm" the user was  
>authenticated from?
>  
>

No.  The CAS protocol expresses a basically arbitrary String username.  
You can, of course, encode anything you'd like into the username, such 
as username at realm.

>Assuming multiple methods of authenticating the user are configured,  
>can an application determine which method was used? ie some  
>application requires that PKI was used and can verify that through  
>the CAS server?
>  
>

No, the CAS protocol doesn't provide any way to do this.

>Last question involves a setup using multiple backends. Does CAS have  
>any feature to allow "friend" accounts that non-community members  
>could register for? Example: I could try and access something at  
>Yale, and CAS would let me create an account using my dartmouth.edu  
>email as a username and grant me a Yale CAS token to present to Yale  
>webapps. It would then be up to the web app to allow me access or not  
>depending on the authorization rules of that app and assuming some  
>kind of "realm" info was available to the web applications.
>  
>

User registration is out of scope of CAS.  CAS authenticates credentials 
against the configured authenticators.

All of what you describe is implementable.  One could write a user 
registration web application sitting along side CAS for creation of 
"friend" accounts, bootstrapping the account from an email address.  
Having created such an account, CAS would be just as happy to 
authenticate that user as any other so long as the username password 
pair for stephen.a.cochran at dartmouth.edu checks out.  So then you, as a 
"friend", would be able to obtain a service ticket for this authentication.

On ticket validation, a filter or other logic examining the declared 
service and the username could filter back out "friend" users from 
applications not equipped to cope with usernames other than local userids.

On ticket validation, the response payload could be enhanced for 
services known to be interested in additional information about how the 
user was authenticated, against which realm the user was authenticated, etc.

All of this is feasible; none of it is included out of the box.

Shibboleth and SAML also apply to these kinds of problems -- if you're 
looking for a simple, flexible, n-tier authentication system for your 
local university, I'd suggest CAS is the way to go.  If you're serious 
about cross-realm authentication and extremely detailed 
characterizations of how the user has authenticated, Shibboleth and SAML 
assertions become important.

Howard Gilbert has convinced me in the past (and I think he's still 
thinking this) that there's a place for using CAS as the bridge from the 
universal power and complexity of Shibboleth to the locally appropriate 
simplicity of applied policy and distilling the authentication down to 
the username.  That is, that one could usefully front CAS with 
Shibboleth authentication.  You would visit my application, click the 
login button, it would redirect you to Yale CAS, you would click 
"authenticate me via Dartmouth Shib" using some kind of WAYF, and you'd 
authenticate via the Dartmouth handle server etc. to Yale CAS, which 
would receive authentication and attribute assertions and then apply 
Yale-local policy to determine whether and how these credentials entitle 
you to access the Yale application you're trying to access. 

This would have the nice consequence that the same APIs and libraries 
that developers use to CASify applications become applicable for 
authenticating cross-realm users, keeping the additional complexity 
beyond the CAS abstraction boundary.

To my knowledge, no one has actually done any of this yet.

I'd be interested in exploring further the requirements / use cases that 
are driving your questions.  There's potential in CAS learning to expose 
some SAML for expressing more details about how users have authenticated 
for applications prepared to accept them.  this is something we've 
discussed in the past.  Maybe you have some requirements that can help 
guide this development.

Andrew