CAS authorization

[Dale Ogilvie]

Andrew,

My suggestion was to implement an extension to services management to
add per-user service authorization.

6. NEW!! CAS authorizes user for service (CAS level authorization) 
7. NEW!! If authorization FAILS -> "sorry you are not authorized to use
that service" STOP

I guess that you were referring to Spring Security (ACEGI) as a cas
client authorization, or do I have the wrong end of the stick?

I haven't seen anything from anyone in terms of implementing per-user
service authorization on the CAS server. The closest existing feature is
the one which currently denies access to a service if it does not exist
in the Services Management tool. This feature would be an extension to
this.

Currently I have no plans to write this, but who knows...

Dale


-----Original Message-----
From: cas-bounces at tp.its.yale.edu [mailto:cas-bounces at tp.its.yale.edu]
On Behalf Of Andrew Ralph Feller, afelle1
Sent: Wednesday, 24 September 2008 4:37 a.m.
To: Yale CAS mailing list
Subject: Re: CAS authorization

Most people use something like Spring Security 2.0 also known as ACEGI.


On 9/23/08 9:51 AM, "Jeremy Wickham" <jrw16 at its.msstate.edu> wrote:

> I was looking through the CAS mailing list and came across your email 
> about CAS authorization. I was curious to know if you have found out a

> way to implement the authorization piece into CAS.  We are actually 
> wanting to want the server to authorize the user instead of leaving 
> that up to the client, leaving the control of authorization of the
applications to us.
> 
> Any insight that you have into CAS authorization will be much help.
> 
> Thanks!
> 
> 
> Jeremy Wickham
> Senior Programmer Analyst
> Enterprise Information Systems
> jeremy.wickham at msstate.edu
> (662) 325-9173
> 
>>>> dale77 <Dale.Ogilvie at trimble.co.nz> 8/7/2008 8:38 PM >>>
> 
> My understanding is that CAS is an authentication technology, with 
> authorization being solely the responsibility of the client service.
> 
> I believe it makes sense for CAS to provide for authorization where it

> is a requirement that a service absolutely not be accessible to a 
> given user. I came up with the following flow:
> 
> 1. User hits service protected by SSO
> 2. Service redirects to CAS
> 3. User enters creds into CAS
> 4. CAS authenticates user
> 5. If authentication FAILS -> "your credentials are not authentic" 
> STOP 6. NEW!! CAS authorizes user for service (CAS level 
> authorization) 7. NEW!! If authorization FAILS -> "sorry you are not 
> authorized to use that service" STOP 8. CAS redirects back to service 
> with service ticket 9. Service validates service ticket 10. Service 
> authorizes User (service level authorization, as it is done
> today)
> 11. User accesses service
> 
> Has anyone implemented anything like the above in CAS, or do people 
> think that this sort of functionality would be desirable? The 
> advantage is that the service never hears from an "authenticated" 
> user, and authorization is managed by the CAS implementor for that
particular service.
> 
> Dale

--
Andrew R. Feller, Analyst
Information Technology Services
200 Fred Frey Building
Louisiana State University
Baton Rouge, LA 70803
(225) 578-3737 (Office)
(225) 578-6400 (Fax)

_______________________________________________
Yale CAS mailing list
cas at tp.its.yale.edu
http://tp.its.yale.edu/mailman/listinfo/cas