example config for using CAS for SSO with Roller

[Phillip Rhodes <mi...@cpphacker.co.uk>]

Hi all, I've recently spent some time getting Roller to work in an SSO
environment with CAS and thought I'd share my config and code with the
group in case anybody else is trying to do this.  But before the config
files and code, a couple of notes:

First: if you want to get Roller working with CAS, I *highly* recommend
working through the Acegi tutorials, and get the minimal sample app
working with CAS in your environment first.  Also read over
the CAS docs and understand how to build and deploy CAS, including
configuring custom plugins.  Trust me, having some understanding of
what's going on will help a lot.

Second: what's required for Roller to work with CAS is almost
exclusively configuration in security.xml.  I added one class to
my Roller build, which is basically just a stub implementation of
a CasAuthoritiesPopulator, because one of the Acegi classes expects
to be injected with one of those.  My implementation doesn't actually
do anything though, except pass through the object returned by the
UserDetailsService.

Third: this config is *not* perfect.  It was done using some copy and
paste from the Acegi tutorial app and was adapted and tweaked until it
worked.  So there's probably left over cruft in there that's not even
necessary. Also I temporarily took out the "remember me" stuff to
simplify things until I got the base functionality working.  But while
not perfect, in my preliminary testing it does work as intended.

If anybody tries this and runs into problems, please post back to this
list and I'll help if I can.

Ok, finally, there should be two attachments. One is my security.xml.
You should be able to replace your security.xml with this, tweak a few
Urls and be close to good to go.  I think you'll also need to find the
cas client jar file and add it to your WEB-INF/lib.  Also, if you don't
have SSL enabled for your app server, you'll need to do that.  CAS
assumes the availability of SSL.

The other attachment is my users.RollerPopulator class, which is the
aforementioned stub implementation of CasAuthoritiesPopulator.  There
may be a way to avoid needing this, but I haven't dug into things deeply
enough yet to be sure.


HTH, YMMV, IANAL, etc.


Phil

Re: example config for using CAS for SSO with Roller

[Jens Dürr <je...@googlemail.com>]

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 <ma...@raibledesigns.com>:
>
> 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 <mi...@cpphacker.co.uk> 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
>

Re: example config for using CAS for SSO with Roller

[Phillip Rhodes <mi...@cpphacker.co.uk>]

Matt Raible wrote:
> 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?

Automatically provisioning users to both CAS and Roller will take some
custom coding if you approach it the way I did.  For the system I'm
working on, I wrote a simple "User Registration App" that handles all
user registration and provisioning and writes the necessary records to
three databases: CAS, Roller and JavaBB; and wrote a new CAS
authentication module to use my "CAS User" database.  This keeps
CAS and it's associated database as the canonical authentication
db for the entire system.

Strictly speaking it's not *necessary* to have  three databases, as I
could have written a CAS authentication module with the "knowledge" to
use either the existing Roller db or JavaBB db, but I went that
direction because it is more consistent with my long-term aims.  But if
 you just "point" CAS at the roller db, then you avoid the issue of
needing to provision users to extra places.  But now you've made Roller
the canonical system for authentication for the entire SSO domain, which
may or may not be appropriate.

As for getting CAS to read from LDAP, I'm not sure as I haven't tried
that.  If there is an existing CAS authentication module for LDAP then
it should just be a case of configuring CAS appropriately.  But that
might be a question better asked on the CAS list.  If there isn't
an existing module for that, it would mean writing a new CAS
authentication module.  That's not hard to do, luckily.  I wrote
a simple one for the project I'm working on.  If anybody is interested
in seeing it as an example, I'll be happy to post the code.


Thanks,


Phil

Re: example config for using CAS for SSO with Roller

[Matt Raible <ma...@raibledesigns.com>]

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 <mi...@cpphacker.co.uk> 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

Re: example config for using CAS for SSO with Roller

[Dave <sn...@gmail.com>]

On 8/11/07, Phillip Rhodes <mi...@cpphacker.co.uk> 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:

Thanks for posting these notes Phillip.


> 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.

I hope to be breaking some of those associations in 4.1 and make it
possible to externalize Roller's user and permissions management.
Check the proposal here:

http://cwiki.apache.org/confluence/display/ROLLER/Proposal+Externalize+User+And+Permissions+Management

- Dave

Re: example config for using CAS for SSO with Roller

[Phillip Rhodes <mi...@cpphacker.co.uk>]

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