Hi Matt, you could try org.acegisecurity.adapters.cas3.CasAuthenticationHandler of the Acegi Framework. This CAS Handler delegate to AcegiAuthenticationManager which could use LdapAuthenticationProvider. I think you only have to include acegi jars into cas' localPlugins directory and edit deployerConfigContext.xml and build your custom cas.war.
see: http://www.acegisecurity.org/guide/springsecurity.html#cas-server-3 Jens 2007/10/22, Matt Raible <[EMAIL PROTECTED]>: > > 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 >
