8

I have a few web applications that I'm trying to tie in via CAS, but I'm a little confused about the authorization, which I read CAS isn't supposed to do. Yet, I see something like groups, but don't know what they are.

Anyway, my scenario is pretty common, and is as follows:

We need to restrict access to each of our apps that are going to support SSO. Within each of our apps, there are roles. These roles are used to prevent certain users from accessing various parts of the site. In addition, admin users should be allowed to assign users access to the apps they are an admin of. Also, an admin of one system may not be an admin of another system. Is it possible to satisfy all of these scenarios with CAS? Or should I be looking at a completely different type of SSO?

-- to explain --

CAS - http://www.jasig.org/cas :

Central Authentication Service project, more commonly referred to as CAS. CAS is an authentication system originally created by Yale University to provide a trusted way for an application to authenticate a user. CAS became a Jasig project in December 2004.

6
  • 2
    It would help if you explained what CAS was...
    – Steve
    Sep 27, 2011 at 18:05
  • I disagree. I'm looking for people who have experience with CAS and ideally with other SSO methods. CAS stands for Central Authentication Service.
    – Bradford
    Sep 27, 2011 at 18:08
  • 1
    @Bradford I've got plenty of experience with centralized authentication / single sign-on systems. I don't recognize the acronym "CAS" either. I hope you don't pull that for an interview question.
    – Jeff Ferland
    Sep 27, 2011 at 18:29
  • @JeffFerland ha. I won't. I wouldn't know how to pronounce it. Would it be case or kass?
    – Bradford
    Sep 27, 2011 at 18:39
  • 5
    @Bradford It still doesn't hurt to explain what "CAS" is, for those of us who don't. It also helps others who are searching for the full name instead of the acronym.
    – Steve
    Sep 27, 2011 at 20:21

4 Answers 4

7

No, CAS is just an Authentication Service, but you can surely impose Authorization using the mechanism, which is the base of doing authentication for your CAS.

Say, if you are using LDAP to authenticate the Accounts for CAS. Then, for the requirement like yours.....

You can create UserGroups in LDAP and assign respective User IDs to their groups.

Now, at web application you keep the log-in via CAS which on success contacts LDAP (or whatever Auth-Mechanism you have at backend) and fetches the UserGroups assigned to the User.

Now, on the basis of UserGroups fetched, you can allow/disallow access to web-app features.

4

First of all: CAS - http://www.jasig.org/cas :

Central Authentication Service project, more commonly referred to as CAS. CAS is an authentication system originally created by Yale University to provide a trusted way for an application to authenticate a user. CAS became a Jasig project in December 2004.

Second: no, I don't think it can do authorization. We use it here and we have different system to do the authorization after CAS has authenticated some user.

3

The short answer is No, it is not CAS's job to do Authorization, it is supposed to only to Authentication.

That said, there are many ways to use CAS in an Authentication/Authorization scenario. I am working on such a custom solution right now myself. I believe there are ways to do some spring security wizardry to get around to it, but the way I have it implemented right now is simply to protect my apps by using a custom role filter, that checks for the presence of existing roles passed to the application by using the CAS client lib for java. So all I need to do to protect my apps in tomcat is to include the CAS client jar, my custom filter jar and to specify what resources to protect in my web.xml.

Feel free to ask if you need further guidance.

2

CAS just performs authentication. Authorization is up to the service provider. With older versions of CAS, you could use the SAML validate endpoint to get attributes from CAS. With the new jasig-CAS 4.0 server, you can get attributes from the CAS 3.0 protocol.

This still means authorization is up to the service, but the service is able to request attributes from CAS so it never needs to touch your back end LDAP store, database, etc. Preventing direct access to your internal directory service may not seem like such a big deal on your internal network, but consider the case where the service provider is a 3rd party. CAS allows your users to authenticate with you, and you choose to allow relevant attributes to the service provider (e.g. group memberships). The service is responsible for enforcing those roles, but you still ultimately control the access.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .