CAS+Oauth

724 views
Skip to first unread message

Mahantesh Prasad Katti

unread,
Apr 7, 2016, 1:31:50 AM4/7/16
to cas-...@apereo.org

Hi All,

 

We have an SSO system in place that is based on CAS. We are also planning to move towards oauth for implementing a centralized authorization strategy that would be backed by JSON web token. I wanted to know the following:

 

1.       In theory it looks feasible. However, if anybody has done the same exercise, would like to know the complexity of the same in terms of customizing and extending CAS. Any references would help.

2.       Also, does CAS work with any other protocol apart from SAML that is lighter weight and standards based?

 

Regards,

Prasad

 

Mahantesh Prasad Katti

unread,
Apr 8, 2016, 3:44:53 AM4/8/16
to cas-...@apereo.org

All,

 

I just wanted to circle back on this. I am sure you would be busy and not had a chance to look this. So yes. I would really appreciate if you could share any similar experiences that you may have run into.

 

Regards

Prasad

--
You received this message because you are subscribed to the Google Groups "CAS Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cas-user+u...@apereo.org.
Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/.
To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/83FA22EE27AA7949A5F616D4DD6AF71E16EC946A%40INBLRMBX001.INDECOMM.LOCAL.
For more options, visit https://groups.google.com/a/apereo.org/d/optout.

Jaroslav Kacer

unread,
Apr 8, 2016, 5:39:20 AM4/8/16
to cas-...@apereo.org

Hi Prasad!

 

Yes, we have implemented an OAuth2 system that consist of the following parts:

-          CAS 4.0 as the authentication provider

-          A UI application

-          An application that provides REST services

 

The CAS part was relatively easy. We just followed this documentation:

http://jasig.github.io/cas/4.0.x/installation/OAuth-OpenId-Authentication.html

 

The two other applications are written in Spring Boot and use Spring’s OAuth means of configuration (annotations on configuration classes etc).

 

The UI application uses CAS OAuth as the authentication provider, so you must log in via CAS to use it.

When a REST call to the 2nd app is made, the OAuth token travels with the request in an HTTP header. The REST application then verifies the token against CAS.

 

Apart Spring Boot problems, we encountered just one problem related to CAS:

The OAuth Profile URL needs a parameter but Spring Boot’s OAuth support is not ready for providing it – it assumes the Profile URL is always without any parameters. We solved this by a little hack to Spring Boot’s OAuth calls.

 

If you have any specific questions, please ask.

 

Best Regards,

   Jarda

 

 

--------------------------------------------------

Jaroslav KAČER

IDC | Web Channel Team | Application Developer

E-Mail: jka...@idc.com

Skype: jkacer.idc

 

Jaroslav Kacer

unread,
Apr 8, 2016, 7:46:44 AM4/8/16
to Mahantesh Prasad Katti, cas-...@apereo.org

Hi!

 

No, the token is just a string. In case of CAS, the token = CAS ticket granting ticket.

But you can get some user roles from the Profile call when you verify the token.

The result of the Profile call is a JSON object with 2 fields:

-          User ID

-          List of roles

I believe there is a way how to configure CAS to fill in the role list. However, we did not do this. Instead, we evaluate user roles directly in the application, based on the provided User ID.

 

Concerning LDAP, I think CAS supports LDAP, at least there is a module for it.

I have no practical experience with this kind of integration but it’s discussed here on the list quite often.

 

For the diagram: Sorry, I don’t have any. But if I find one, I’ll post it here too.

 

Best Regards,

   Jarda

 

--------------------------------------------------

Jaroslav KAČER

IDC | Web Channel Team | Application Developer

E-Mail: jka...@idc.com

Skype: jkacer.idc

 

 

From: Mahantesh Prasad Katti [mailto:Mahante...@Indecomm.net]
Sent: 8. April 2016 12:35 odp.
To: Jaroslav Kacer <jka...@idc.com>
Subject: RE: CAS+Oauth

 

Thanks Jarda for your response. Much Appreciated. Another question is how did you implement authorization? Did the oauth token provide the authorization info.? Does the CAS server authenticate against the LDAP?

 

Do you have any flow diagrams that I can refer to in order to understand how the interactions hapeen? Again thanks for taking time to respond?

 

Regards,

Prasad

 

From: Jaroslav Kacer [mailto:jka...@idc.com]
Sent: Friday, April 08, 2016 2:23 PM
To: Mahantesh Prasad Katti
Subject: RE: CAS+Oauth

 

Hi Prasad!

 

Yes, we have implemented an OAuth2 system that consist of the following parts:

-          CAS 4.0 as the authentication provider

-          A UI application

-          An application that provides REST services

 

The CAS part was relatively easy. We just followed this documentation:

http://jasig.github.io/cas/4.0.x/installation/OAuth-OpenId-Authentication.html

 

The two other applications are written in Spring Boot and use Spring’s OAuth means of configuration (annotations on configuration classes etc).

 

The UI application uses CAS OAuth as the authentication provider, so you must log in via CAS to use it.

When a REST call to the 2nd app is made, the OAuth token travels with the request in an HTTP header. The REST application then verifies the token against CAS.

 

Apart Spring Boot problems, we encountered just one problem related to CAS:

The OAuth Profile URL needs a parameter but Spring Boot’s OAuth support is not ready for providing it – it assumes the Profile URL is always without any parameters. We solved this by a little hack to Spring Boot’s OAuth calls.

 

If you have any specific questions, please ask.

 

Best Regards,

   Jarda

 

--------------------------------------------------

Jaroslav KAČER

IDC | Web Channel Team | Application Developer

E-Mail: jka...@idc.com

Skype: jkacer.idc

 

 

From: cas-...@apereo.org [mailto:cas-...@apereo.org] On Behalf Of Mahantesh Prasad Katti
Sent: 8. April 2016 9:45 dop.
To: cas-...@apereo.org
Subject: [cas-user] RE: CAS+Oauth

 

All,

Jaroslav Kacer

unread,
Apr 8, 2016, 7:51:27 AM4/8/16
to Mahantesh Prasad Katti, cas-...@apereo.org

Plain Spring MVC + Spring Security OAuth should work too.

Spring Boot was a requirement in our case, it wasn’t my choice.

 

Apart from Spring, I know about Apache Oltu. But I have no practical experience with using it in a larger web application.

You can give it a try: http://oltu.apache.org/

 

Best Regards,

   Jarda

 

--------------------------------------------------

Jaroslav KAČER

IDC | Web Channel Team | Application Developer

E-Mail: jka...@idc.com

Skype: jkacer.idc

 

 

From: Mahantesh Prasad Katti [mailto:Mahante...@Indecomm.net]
Sent: 8. April 2016 12:37 odp.
To: Jaroslav Kacer <jka...@idc.com>
Subject: RE: CAS+Oauth

 

Again, did you consider any other options apart from Spring Boot?

 

Regards,

Prasad

From: cas-...@apereo.org [mailto:cas-...@apereo.org] On Behalf Of Mahantesh Prasad Katti
Sent: 8. April 2016 9:45 dop.
To: cas-...@apereo.org
Subject: [cas-user] RE: CAS+Oauth

 

All,

Mahantesh Prasad Katti

unread,
Apr 8, 2016, 8:03:15 AM4/8/16
to Jaroslav Kacer, cas-...@apereo.org

Ok. Coming back to your first mail, and specifically referring to when UI logs into CAS, the token is delivered to the UI and then UI then makes a call to the app2 services  with this bearer token. Is my understanding correct? The way I have used CAS [only] currently is that post login to my application [which is monolithic] through CAS, I am redirected to my application callback URL with a SERVICE_TICKET.

 

However, in a micro-services environment we would have UI deployed in a separate container . so the token would be delivered to the UI which would then use the same to call services on other micro services apps. Is it how the design is for you?

 

Regards

Jaroslav Kacer

unread,
Apr 8, 2016, 12:20:43 PM4/8/16
to Mahantesh Prasad Katti, cas-...@apereo.org

Hi!

 

Yes, it’s correct.

The application caches the token; it is valid for the same time period the corresponding TGT is.

In case of Spring Security OAuth applications, it is held in the OAuthRestTemplate that is responsible for OAuth authentication against CAS.

If you don’t use Spring Security OAuth, you will probably have to cache it somehow.

 

What you describe is certainly possible; it’s the classic way of using CAS.

However, in our case we chose a different approach. The authentication does not use the CAS protocol at all; it uses OAuth instead and (as a pure coincidence J ), the provider of OAuth tokens is CAS.

 

You can combine both: use the classic CAS protocol and still get OAuth tokens. We tried this approach too but then switched to an OAuth-only solution.

 

And, yes, we also have the UI app and REST app separated. Different application servers etc. There should be no problem here.

Mahantesh Prasad Katti

unread,
Apr 8, 2016, 11:14:38 PM4/8/16
to Jaroslav Kacer, cas-...@apereo.org

Thanks much. Time for me to get to action mode. J

Mahantesh Prasad Katti

unread,
Apr 12, 2016, 2:58:29 AM4/12/16
to Jaroslav Kacer, cas-...@apereo.org

Hi All,

 

After doing some reading up on CAS documentation and mapping my current requirements, here are some observations that I wanted to run by you. It will be of immense help to validate my understanding.

 

1.       CAS can act as an oauth server. However, at this point in time, it supports only “authorization code” grant type only.

2.       If I need support for other grant types, what are the options available inherently?

a.       Is it available out of the box?

b.      If not, shall I presume, we have to custom build the  same and use delegated authorization. In this case CAS still handles the authentication.

3.       In the default implementation of oauth server support, what storage medium is used for storing authorization attributes?

4.       Are there any screens/APIs that allow to register clients for client credentials grant type?

5.       In case of delegated authorization, using pac4j libraries, do the interactions between CAS and Oauth servers happen over HTTP?

 

6.       My current use of oauth entails me to use “password credential grant type” and “client credential grant type”. Is it fair to say, I would have to build my awn oauth server that integrates with CAS as opposed to using the built in support in CAS for OAuth?

 

I would really appreciate some inputs and pointers.

 

Regards,

Jaroslav Kacer

unread,
Apr 12, 2016, 4:10:19 AM4/12/16
to Mahantesh Prasad Katti, cas-...@apereo.org

Hi Prasad!

 

I’m sorry but I can only answer 1: We used it with the Authorization Code grant type and I’m not aware of other supported types. It would be good if the original authors answered this question.

 

Please note that I am at CAS 4.0. Things might have changed in 4.1 and 4.2, so do not take my answers as 100% guaranteed for the new versions.

Jaroslav Kacer

unread,
Apr 12, 2016, 5:08:48 AM4/12/16
to Mahantesh Prasad Katti, cas-...@apereo.org

If you mean defining what applications can use OAuth on CAS, then you will need something like this in your deployerConfigContext.xml, element “registeredServicesList”:

 

        <!-- OAuth Callback Authorization -->

        <bean class="org.jasig.cas.support.oauth.services.OAuthCallbackAuthorizeService">

            <property name="id" value="1" />

            <property name="name" value="HTTP" />

            <property name="description" value="oauth wrapper callback url" />

            <!-- By default, only support regex patterns if/when needed -->

            <property name="serviceId" value="${server.prefix}/oauth2.0/callbackAuthorize" />

        </bean>

 

        <bean class="org.jasig.cas.support.oauth.services.OAuthRegisteredService">

            <property name="id" value="2" />

            <property name="name" value="xxxxxxxxxxxxxxx" />

            <property name="description" value="xxxxxxxxxxxxxxxxx" />

            <!-- Supports regex patterns by default for service ids -->

            <property name="serviceId" value="xxxxxxxxxxxxxxxxx" />

            <property name="clientId" value="xxxxxxxxxxxxxxxxxxxxxx" />

            <property name="clientSecret" value="xxxxxxxxxxxxxxxxxxx" />

        </bean>

 

You may need to remove ${server.prefix}, I don’t know it it’s normally defined (just a detail).

 

Have a look here:

http://jasig.github.io/cas/4.0.x/installation/OAuth-OpenId-Authentication.html

And press the “Show Code” buttons.

 

Is this what you meant?

 

Jarda

 

--------------------------------------------------

Jaroslav KAČER

IDC | Web Channel Team | Application Developer

E-Mail: jka...@idc.com

Skype: jkacer.idc

 

 

From: Mahantesh Prasad Katti [mailto:Mahante...@Indecomm.net]
Sent: 12. April 2016 10:46 dop.
To: Jaroslav Kacer <jka...@idc.com>

Subject: RE: CAS+Oauth

 

Thanks Jarda. How about #4? How did you register your clients? Did you use any UI provided by CAS?

Mahantesh Prasad Katti

unread,
Apr 12, 2016, 5:11:19 AM4/12/16
to Jaroslav Kacer, cas-...@apereo.org

Yes. Also, in addition I wanted to know if there’s CAS UI screen to do this. To generate the client ID and secret.

Jaroslav Kacer

unread,
Apr 12, 2016, 5:14:59 AM4/12/16
to Mahantesh Prasad Katti, cas-...@apereo.org

I don’t know, sorry.

But you can generate them manually, they are just strings. Something meaningful for the Client ID and a good random string for the secret. I hope it’s OK. Please correct me someone if not.

Mahantesh Prasad Katti

unread,
Apr 12, 2016, 5:17:28 AM4/12/16
to Jaroslav Kacer, cas-...@apereo.org

The reason I asked that question was that most OAuth servers [google, Facebook] provide the option to auto-generate this.

Jérôme LELEU

unread,
Apr 12, 2016, 8:26:12 AM4/12/16
to Mahantesh Prasad Katti, Jaroslav Kacer, cas-...@apereo.org
Hi,

The current cas-management-webapp handles OAuth client definition as well as regular CAS services.

Best regards,
Jérôme


Jérôme LELEU

unread,
Apr 12, 2016, 8:37:52 AM4/12/16
to Jaroslav Kacer, Mahantesh Prasad Katti, cas-...@apereo.org
Hi,

1. 2. Correct. We currently only support the authorization code grant type. Version 5.0.0 of CAS (in development) will support the implicit, resource password credentials and refresh tokens grant types. You can already test them.
Until the release, you are on your own and developing these new grant types is not easy.

3. Before CAS server 4.2, the /profile endpoint returns all attributes, since CAS 4.2, the returned attributes are the ones defined by the services like for any CAS service.

4. The cas-management-webapp in the latest CAS versions allows you to register the OAuth clients. Before, you had to add them manually. The client credentials grant type is not supported and won't be: I'm not sure to understand what could be your use case.

5. The OAuth server redirects (302 HTTP) to the CAS server for login. The OAuth client from pac4j communicates with the OAuth server according to your configuration.

6. It's a custom development you need to build unless you can wait for CAS v5. Find the best option for you, but I guess it might be easier to setup your own OAuth server.

Thanks.
Best regards,
Jérôme



Mahantesh Prasad Katti

unread,
Apr 12, 2016, 9:27:15 AM4/12/16
to Jérôme LELEU, Jaroslav Kacer, cas-...@apereo.org

4. we are building micro services based strategy. So if there is an interaction between two services that is non-human, service A would get an access token by providing the client_id and secret and invoke the service B by sending the bearer token. Client Credential Grant type is a standard oauth grant type. Is there any reason why it would not be supported?

 

5. Also, is there a way we can configure what kind of tokens get sent? Right now the tokens that get sent are opaque that need to be validated with the CAS server.

 

Thanks for sharing information.

 

Regards,

Prasad Katti

Mahantesh Prasad Katti

unread,
Apr 12, 2016, 9:44:56 AM4/12/16
to Jérôme LELEU, Jaroslav Kacer, cas-...@apereo.org

Jerome,

 

Just curious how we can test the CAS V5?

 

Regards

Prasad

 

From: Jérôme LELEU [mailto:lel...@gmail.com]

Sent: Tuesday, April 12, 2016 6:08 PM
To: Jaroslav Kacer

Jérôme LELEU

unread,
Apr 12, 2016, 9:46:20 AM4/12/16
to Mahantesh Prasad Katti, Jaroslav Kacer, cas-...@apereo.org
Hi,

The CAS v5 is currently available in the Sonatype snapshots repostiory, version: 5.0.0-SNAPSHOT -> https://oss.sonatype.org/content/repositories/snapshots/org/jasig/cas/cas-server-webapp/5.0.0-SNAPSHOT/

Best regards,
Jérôme

Jérôme LELEU

unread,
Apr 12, 2016, 9:54:53 AM4/12/16
to Mahantesh Prasad Katti, Jaroslav Kacer, cas-...@apereo.org
Hi,

4. As the CAS server was the resource server and the authorization server and the only exposed resource was the user profile, only the grant types involving users made sense, and especially the authorization code grant type. Then, we addressed a larger scope by implementing the implicit and resource owner password.
I don't think client credentials grant type is our first use case, but it could make sense in some scenarios. Feel free to open a Github issue...

5. No, only opaque strings are sent for now: did you expect some JWT?

Thanks.
Best regards,
Jérôme

Mahantesh Prasad Katti

unread,
Apr 12, 2016, 10:04:46 AM4/12/16
to Jérôme LELEU, Jaroslav Kacer, cas-...@apereo.org

“I don't think client credentials grant type is our first use case “ – Did you mean it is not a priority?

 

JWT would be great. Is it on the roadmap?

 

Regards

Prasad

Mahantesh Prasad Katti

unread,
Apr 12, 2016, 10:42:25 AM4/12/16
to Mahantesh Prasad Katti, Jérôme LELEU, Jaroslav Kacer, cas-...@apereo.org

Also when is CAS V5 scheduled for GA?

Jérôme LELEU

unread,
Apr 12, 2016, 7:45:08 PM4/12/16
to Mahantesh Prasad Katti, Jaroslav Kacer, cas-...@apereo.org
Hi,

Indeed, it was not a priority, but it's the second time I have a question about it, so it can become one.

JWT is planned for OpenID Connect support only for now: what use case do you have in mind?

Thanks.
Best regards,
Jérôme

Mahantesh Prasad Katti

unread,
Apr 12, 2016, 10:40:30 PM4/12/16
to Jérôme LELEU, Jaroslav Kacer, cas-...@apereo.org

With JWT, we can reduce the load on the auth servers and that provides a massive scale when it comes to web applications [read internet facing]. Plus it is stateless and lightweight. It throws open so many interesting design and architecture paradigms.

 

Regards,

Prasad

Jérôme LELEU

unread,
Apr 13, 2016, 2:13:18 AM4/13/16
to Mahantesh Prasad Katti, Jaroslav Kacer, cas-...@apereo.org
Hi,

I'm convinced by JWT as well. You meant returning JWT as access tokens, right?

Thanks.
Best regards,
Jérôme

Mahantesh Prasad Katti

unread,
Apr 13, 2016, 4:44:55 AM4/13/16
to Jérôme LELEU, cas-...@apereo.org, Jaroslav Kacer

Yes. jwt can carry lot of information that can lead to federated authorization. BTW, I did see that JWT is supported [at least that is what I inferred.] based on the link http://jasig.github.io/cas/4.2.x/installation/JWT-Authentication.html. Please correct me if I am wrong.

 

I have another question on the opaque token currently supported. From my understanding, the service ticket [classic CAS]is specific to each URL. However, I believe it is not so for the oauth token. So if I have a portal, and I have a oauth token, I can the use the token while accessing all the URLs/links on the portal and not generate a token for each request I generate from the portal UI. Is that a correct understanding? Essentially, what I am hinting at is moving away from session based authentication.

Jérôme LELEU

unread,
Apr 13, 2016, 4:54:26 AM4/13/16
to Mahantesh Prasad Katti, cas-...@apereo.org, Jaroslav Kacer
Hi,

In fact, JWT is supported but not in OAuth support: JWT can be passed as token request parameter on the /login endpoint, assuming you have the appropriate configuration.

Before CAS 4.2, the access token was the TGT so it didn't take into account the service.
Since CAS 4.2, the service is taken into account.

Thanks.
Best regards,
Jérôme

Mahantesh Prasad Katti

unread,
Apr 13, 2016, 5:32:38 AM4/13/16
to Jérôme LELEU, cas-...@apereo.org, Jaroslav Kacer

Just so I get this right. Does this mean [in the oauth scenario] I will have to get an access token for each request that I make in my application?

Jérôme LELEU

unread,
Apr 13, 2016, 6:08:23 AM4/13/16
to Mahantesh Prasad Katti, cas-...@apereo.org, Jaroslav Kacer
Hi,

No, you'll get an access token once you access your application, though the value of the access token will be the TGT value and it will be the same for all OAuth clients. For CAS server < v4.2 only.

Best regards,
Jérôme

Mahantesh Prasad Katti

unread,
Apr 13, 2016, 12:13:28 PM4/13/16
to Jérôme LELEU, cas-...@apereo.org, Jaroslav Kacer

Thanks Jerome. Is it possible to have Classic CAS and Oauth CAS working at the same time? It’s possible that there are already some applications that are using CAS the conventional way. While newer applications may be working with Oauth based CAS. Is it possible for both to co-exist?

Jérôme LELEU

unread,
Apr 13, 2016, 12:16:37 PM4/13/16
to Mahantesh Prasad Katti, cas-...@apereo.org, Jaroslav Kacer
Yes, the OAuth server support has been designed to compliment / coexist with the default CAS protocol support...

Mahantesh Prasad Katti

unread,
Apr 14, 2016, 10:28:29 AM4/14/16
to Jérôme LELEU, cas-...@apereo.org

1.       If I need two applications to communicate using oauth enabled security, what are my options currently? Since no user consent is required, auth code grant type will not be workable option. Does that mean I need to resort to basic http authentication in that case?

2.       Also, currently i am using apache shiro for authorization where I store my roles and permissions. Is it possible to customize oauth server to refer the same for authorization?

 

Regards,

Prasad

Jérôme LELEU

unread,
Apr 14, 2016, 2:56:58 PM4/14/16
to Mahantesh Prasad Katti, cas-...@apereo.org
Hi,

1. Currently, you need to resort to basic auth. But we could work on client credentials grant type for v5.0.0...

2. I'm not sure to understand what you want to do.

Thanks.
Best regards,
Jérôme

Mahantesh Prasad Katti

unread,
Apr 15, 2016, 12:16:29 AM4/15/16
to Jérôme LELEU, cas-...@apereo.org

In our current scenario, Apache Shiro provides permissions based authorization for resources. Essentially I can define roles and add permissions to them and then assign the roles to individual users. That’s how we are doing authorization currently. However, because Oauth is primarily meant for authorization, it now has to integrate with apache shiro. I also read some documentation that apache shiro integrates well with default CAS. Hence, I was investigating how we can integrate apache shiro with default oauth  implementation as well.

 

Hope I managed to convey my thoughts a little better.

Jérôme LELEU

unread,
Apr 15, 2016, 2:08:43 AM4/15/16
to Mahantesh Prasad Katti, cas-...@apereo.org
Hi,

Authorization on CAS OAuth server side is just about the attributes you will get from the /profile endpoint and this is defined at the services configuration level. So you won't have any use for your roles / permissions like you do on client side with Shiro.

Thanks.
Best regards,
Jérôme


Mahantesh Prasad Katti

unread,
Apr 15, 2016, 7:44:46 AM4/15/16
to Jérôme LELEU, cas-...@apereo.org

Ok. By services configuration level, you mean let’s I have a /user service. And I want to restrict certain roles only to access this service. How will the default CAS oauth implementation help solve this? Is this configurable? Can it be fine grained?

 

For the pac4j project where can I find these configurations? I am using the user jleleu.

 

Regards

Jérôme LELEU

unread,
Apr 16, 2016, 4:57:52 AM4/16/16
to Mahantesh Prasad Katti, cas-...@apereo.org
Hi,

CAS services have multiple configuration options which are used by the CAS protocol. When it comes to OAuth, we only checks if the service is enabled and what attributes must be returned, we don't apply any check on roles. Though, this could certainly be improved. Any contribution will be appreciated.

What configurations of the pac4j project do you mean?

Thanks.
Best regards,
Jérôme

Jérôme LELEU

unread,
Apr 16, 2016, 4:59:39 AM4/16/16
to Mahantesh Prasad Katti, CAS Community
Hi,

It depends on the CAS server version: currently, it's the expiration policy of the service time which is used for the authorization code. In the future 4.3, you'll be able to have a specific configuration.

Thanks.
Best regards,
Jérôme


2016-04-15 14:09 GMT+02:00 Mahantesh Prasad Katti <Mahante...@indecomm.net>:

Jerome,

 

Where can I modify the expiry time for authorization code in pac4j project?

 

Regards

Prasad

 

From: cas-...@apereo.org [mailto:cas-...@apereo.org] On Behalf Of Mahantesh Prasad Katti
Sent: Friday, April 15, 2016 5:15 PM
To: Jérôme LELEU
Cc: cas-...@apereo.org
Subject: RE: [cas-user] RE: CAS+Oauth

 

Ok. By services configuration level, you mean let’s I have a /user service. And I want to restrict certain roles only to access this service. How will the default CAS oauth implementation help solve this? Is this configurable? Can it be fine grained?

Misagh Moayyed

unread,
Apr 16, 2016, 10:54:08 AM4/16/16
to cas-...@apereo.org

As long as the roles are converted into CAS attributes in Oauth, which I think they are, you can use CAS to turn on an access strategy to enforce service access based on the presence of those attributes.

 

Mahantesh Prasad Katti

unread,
Apr 17, 2016, 4:36:12 AM4/17/16
to Jérôme LELEU, cas-...@apereo.org

Thanks Jerome. The reason I was asking that question was that suppose If I had to take the facebook example, if I login into a third party app using facebook, the third part app typically says it wants access to my connections, emails and pictures. Essentially it defines the scope for the third party client. Scope management is also part of the oauth framework. This is typically done using client registration. Based on what I interpret from your response, the current support is not that fine grained, though, it is on your road map. However, if I had to perform fine grained access control based on roles and permissions, I will have to build that on the client side. Please correct me if I am wrong.

Mahantesh Prasad Katti

unread,
Apr 17, 2016, 4:37:32 AM4/17/16
to Misagh Moayyed, cas-...@apereo.org

Thanks. Are there any examples that I can refer to?

 

Regards

Prasad

 

From: cas-...@apereo.org [mailto:cas-...@apereo.org] On Behalf Of Misagh Moayyed
Sent: Saturday, April 16, 2016 8:24 PM
To: cas-...@apereo.org
Subject: RE: [cas-user] RE: CAS+Oauth

 

As long as the roles are converted into CAS attributes in Oauth, which I think they are, you can use CAS to turn on an access strategy to enforce service access based on the presence of those attributes.

Mahantesh Prasad Katti

unread,
Apr 17, 2016, 4:44:21 AM4/17/16
to Jérôme LELEU, CAS Community

Ok. The reason I asked you this, was I am not able to get an access token after providing the auth code to the oauth server. I am thinking it is expiring a little quickly. Hence I was thinking of increasing expiry time of the same. Where can I find “expiration policy of the service time”? so I can increase the same?

 

Regards,

Prasad

 

 

From: Jérôme LELEU [mailto:lel...@gmail.com]
Sent: Saturday, April 16, 2016 2:30 PM
To: Mahantesh Prasad Katti; CAS Community
Subject: Re: [cas-user] RE: CAS+Oauth

 

Hi,

 

It depends on the CAS server version: currently, it's the expiration policy of the service time which is used for the

+

Misagh Moayyed

unread,
Apr 17, 2016, 10:55:54 AM4/17/16
to cas-...@apereo.org

Mahantesh Prasad Katti

unread,
Apr 17, 2016, 12:49:48 PM4/17/16
to Misagh Moayyed, cas-...@apereo.org

How would that work if I had two kinds of applications, ones that worked with default CAS protocol and some that worked with OAuth protocols? Would the applications that work with CAS protocol still work un-impacted?

Misagh Moayyed

unread,
Apr 17, 2016, 1:05:43 PM4/17/16
to cas-...@apereo.org

The setting is application/service specific in the registry. You define the rule for the service you want to affect.

Jérôme LELEU

unread,
Apr 18, 2016, 3:47:20 AM4/18/16
to Misagh Moayyed, CAS Community
It's the way you can expect the OAuth support to work, though I'll check and revisit that if necessary...



Jérôme LELEU

unread,
Apr 18, 2016, 3:54:11 AM4/18/16
to Mahantesh Prasad Katti, Misagh Moayyed, cas-...@apereo.org
Hi,

I must check the behaviour, but the demo for tests is here: https://github.com/leleuj/cas-pac4j-oauth-demo

Thanks.
Best regards,
Jérôme


To post to this group, send email to cas-...@apereo.org.

Jérôme LELEU

unread,
Apr 18, 2016, 3:57:02 AM4/18/16
to Mahantesh Prasad Katti, CAS Community
Hi,

It may depend on the CAS server version, but you should generally this configuration option in the cas.properties file: https://github.com/Jasig/cas/blob/4.2.x/cas-server-webapp/src/main/webapp/WEB-INF/cas.properties#L323

Thanks.
Best regards,
Jérôme

Reply all
Reply to author
Forward
0 new messages