Remember, that rubyCAS only provides authentication - ie making sure that the person we're talking to belongs to the username that we've been given. It does not tell us if this user should be viewing the page we're looking at - that's up to you.
There are lots of rails authorisation (or authorization) tools out there. A good example is declarative authorization
In one of my previous projects we looked to implement centrally-hosted authorisation. Implementation ideas follow:
rubyCAS (as opposed to non-ruby CAS) happily serves up 'extra attributes' with your newly-authenticated user.
These extra attributes are usually things like name/email etc, In our case we chose to send back the user's id (from the API) and the user's type_id (which indicates if they are a partner/admin).
It should be little problem to add a 'roles' field to the api and serve this up as well.
The 'extra attributes' are available for every authentication request - so the client application will have the newest copy when a user logs in.
It's then up to the client-application to verify the freshness of the roles at appropriate points.
From then on, though, the going is easy. We can use, say, declarative_authorization perfectly naturally from then on, simply pulling the set of roles from the given field. The client-application can decide what a user can see based on the roles they are known to have.
Setting a user up with roles will be done by editing the user on the admin-application.
Now, there is a niggling limit involved that is implied by the phrase 'rubyCAS'. The extra-attributes thing works happily on rubycas-client, but may not be supported by *other* client implementations of CAS. If we wanted to add CAS-based authentication/authorisation into non-rails apps, we'd have to find a client that supported it.
Otherwise, the proof-of-concept shows that it works just fine.
This is one article in a series on Rails single-sign-on with rubyCAS
