Using a different LDAP attribute for the principal ID for Google Apps SAML only?

[Brodie Rao]

Scott Battaglia wrote:
> 
> -Scott Battaglia
> PGP Public Key Id: 0x383733AA
> LinkedIn: http://www.linkedin.com/in/scottbattaglia
> 
> On Wed, Jul 9, 2008 at 2:35 PM, Brodie Rao <brodie.rao at cpcc.edu 
> <mailto:brodie.rao at cpcc.edu>> wrote:
> 
>     I'm using CAS server 3.2.1 with an LDAP server and I'd like to have it
>     use a different attribute for finding the principal ID for Google Apps
>     SAML requests. Is it possible to configure the CAS server to send a
>     different principal ID for SAML requests? More specifically, I want it
>     to return the mailNickname LDAP attribute for Google Apps, and
>     sAMAccountName for any other request (which is the attribute queried on
>     by the LDAP authentication handler).
> 
>  
> In general its very difficult to swap the id attribute for one name. 
>  One of the general assumptions is a canonical username ;-)  Especially 
> since authentication/principal resolution is only done whenever 
> credentials are supplied.  You could probably write your own Service 
> object that does the lookup when a SAML2 service is created and do it 
> that way if you wanted.  You could base it off the GoogleAccountsService 
> that already exists and configure that instead of the normal one.

I don't want to change the username the user logs in with, just the 
principal ID returned to the application by the CAS server. That way I 
can use the same CAS server with the same usernames, while giving Google 
Apps a principal ID that actually makes sense for it: the email 
nickname. Google Apps makes the assumption that usernames are also email 
addresses, and it's presented in its UI this way as well.

>     If that's not possible, is it possible to configure a second instance of
>     the CAS server mounted at a different URL that shares the same ticket
>     store as the first server? That way I could point Google Apps to that
>     second instance, and keep existing applications pointed at the first
>     instance.
> 
> 
> CAS can share ticket stores.  We've got a few options including 
> JBossCache, MemCache, and Terracotta.  The last two will be as of 3.3.

I was hoping I wouldn't have to code anything to get this working, but 
it sounds like clustering is the better way to go about it anyway. The 
documentation for clustering with JBossCache makes the process seem 
daunting though, and I don't actually want to cluster across different 
machines, I just want two CAS application instances on the same Tomcat 
server.

I did look into what it would take to do it with one instance, but 
looking at the code it seemed that I couldn't specify different 
principal resolvers for specific contexts at this level. Would it be 
straightforward to make GoogleAccountsService use a separate principal 
resolver?