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.

Best Regards,
   Jarda

--------------------------------------------------
Jaroslav KAČER
IDC | Web Channel Team | Application Developer
E-Mail: jka...@idc.com<mailto:jka...@idc.com>
Skype: jkacer.idc


From: Mahantesh Prasad Katti [mailto:mahantesh.ka...@indecomm.net]
Sent: 12. April 2016 8:58 dop.
To: Jaroslav Kacer <jka...@idc.com>; cas-user@apereo.org
Subject: RE: CAS+Oauth

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,

Prasad

From: cas-user@apereo.org<mailto:cas-user@apereo.org> 
[mailto:cas-user@apereo.org] On Behalf Of Mahantesh Prasad Katti
Sent: Saturday, April 09, 2016 8:44 AM
To: Jaroslav Kacer; cas-user@apereo.org<mailto:cas-user@apereo.org>
Subject: [cas-user] RE: CAS+Oauth

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

Regards,
Prasad

From: Jaroslav Kacer [mailto:jka...@idc.com]
Sent: Friday, April 08, 2016 9:51 PM
To: Mahantesh Prasad Katti; cas-user@apereo.org<mailto:cas-user@apereo.org>
Subject: RE: CAS+Oauth

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 ☺ 
), 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.

Best Regards,
   Jarda

--------------------------------------------------
Jaroslav KAČER
IDC | Web Channel Team | Application Developer
E-Mail: jka...@idc.com<mailto:jka...@idc.com>
Skype: jkacer.idc


From: Mahantesh Prasad Katti [mailto:mahantesh.ka...@indecomm.net]
Sent: 8. April 2016 2:03 odp.
To: Jaroslav Kacer <jka...@idc.com<mailto:jka...@idc.com>>; 
cas-user@apereo.org<mailto:cas-user@apereo.org>
Subject: RE: CAS+Oauth

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
Prasad


From: Jaroslav Kacer [mailto:jka...@idc.com]
Sent: Friday, April 08, 2016 5:17 PM
To: Mahantesh Prasad Katti; cas-user@apereo.org<mailto:cas-user@apereo.org>
Subject: RE: CAS+Oauth

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<mailto:jka...@idc.com>
Skype: jkacer.idc


From: Mahantesh Prasad Katti [mailto:mahantesh.ka...@indecomm.net]
Sent: 8. April 2016 12:35 odp.
To: Jaroslav Kacer <jka...@idc.com<mailto: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<mailto:jka...@idc.com>
Skype: jkacer.idc


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

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

From: cas-user@apereo.org<mailto:cas-user@apereo.org> 
[mailto:cas-user@apereo.org] On Behalf Of Mahantesh Prasad Katti
Sent: Thursday, April 07, 2016 11:02 AM
To: cas-user@apereo.org<mailto:cas-user@apereo.org>
Subject: [cas-user] CAS+Oauth

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

--
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+unsubscr...@apereo.org<mailto:cas-user+unsubscr...@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<https://groups.google.com/a/apereo.org/d/msgid/cas-user/83FA22EE27AA7949A5F616D4DD6AF71E16EC946A%40INBLRMBX001.INDECOMM.LOCAL?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/a/apereo.org/d/optout.
--
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+unsubscr...@apereo.org<mailto:cas-user+unsubscr...@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/83FA22EE27AA7949A5F616D4DD6AF71E16EC9A8C%40INBLRMBX001.INDECOMM.LOCAL<https://groups.google.com/a/apereo.org/d/msgid/cas-user/83FA22EE27AA7949A5F616D4DD6AF71E16EC9A8C%40INBLRMBX001.INDECOMM.LOCAL?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/a/apereo.org/d/optout.
--
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+unsubscr...@apereo.org<mailto:cas-user+unsubscr...@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/83FA22EE27AA7949A5F616D4DD6AF71E16EC9DB5%40INBLRMBX001.INDECOMM.LOCAL<https://groups.google.com/a/apereo.org/d/msgid/cas-user/83FA22EE27AA7949A5F616D4DD6AF71E16EC9DB5%40INBLRMBX001.INDECOMM.LOCAL?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/a/apereo.org/d/optout.

-- 
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+unsubscr...@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/BY2PR02MB1332C21DFECA7E39E1787496CF950%40BY2PR02MB1332.namprd02.prod.outlook.com.
For more options, visit https://groups.google.com/a/apereo.org/d/optout.

Reply via email to