I'm trying these instructions and I've gotten as far as configuring security.xml and getting Roller started. In addition to these instructions, I had to add casclient.jar to my WEB-INF/lib directory.
Do you know how I can add users to CAS or how to have it read users from LDAP? Thanks, Matt On 8/11/07, Phillip Rhodes <[EMAIL PROTECTED]> wrote: > 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 > -- http://raibledesigns.com
