A few extra note and points of clarification... anybody who's trying to implement SSO probably already understands these issues (or at least these kinds of issues) but just in case it will help somebody:
This configuration still uses the same roller database tables and information for authorization. That is, after a user is authenticated using CAS, the code will try to look that username up in the roller db, in order to set the authorities for the user. Additionally, I imagine the Roller code - at some level - expects entries in whichever table it uses for user information so it can maintain associations between a given user and their blog, etc. This is important because it implies (in the most common scenario) that a user has to be provisioned in TWO databases - whatever CAS is authenticating against, and the Roller DB - before they can use the system. There are a couple of ways to mitigate the impact of this. First, if you wanted too you could have CAS authenticate against the Roller DB. If you want Roller to be the canonical source of authentication information for your entire SSO environment, that's fine. I doubt most people will want that though. So, assuming CAS is authenticating against some other database (maybe the organization's LDAP server or Active Directory or something) you have a couple of options. IF you can get the appropriate authorization information put into that canonical database, then you can point the UserDetailsService at that and only maintain users in one place, at least as far as authentication and authorization go. Even then I think it'll turn out that entries still have to be populated into Roller's user table(s) for maintaining associations. The positive about this scenario is that you can probably automate the process of populating the roller table. Eg, "here's a new user that's authenticated but we don't have a user record for, so let's create this user in our db" on the Roller side. A more elegant solution would be to automatically provision / deprovision the user across all systems in response to their creation in the canonical identity database. Doing this can obviously get complicated, but the basic idea would be to have something like a database trigger, or a hook point provided by the identity system, send a message to all the systems in the SSO environment saying "Hey, user JoeBob has been created, create this guy in your own database" or "Hey, user JoeBob has been deleted, get rid of your records for him." Implementing this is left as an exercise for the reader. :-) TTYL, Phil
