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 2016-04-13 10:44 GMT+02:00 Mahantesh Prasad Katti < mahantesh.ka...@indecomm.net>: > 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. > > > > Regards, > > Prasad > > > > *From:* Jérôme LELEU [mailto:lele...@gmail.com] > *Sent:* Wednesday, April 13, 2016 11:43 AM > *To:* Mahantesh Prasad Katti > *Cc:* Jaroslav Kacer; cas-user@apereo.org > *Subject:* Re: [cas-user] RE: CAS+Oauth > > > > Hi, > > > > I'm convinced by JWT as well. You meant returning JWT as access tokens, > right? > > > > Thanks. > > Best regards, > > Jérôme > > > > > > 2016-04-13 4:40 GMT+02:00 Mahantesh Prasad Katti < > mahantesh.ka...@indecomm.net>: > > 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 > > > > *From:* Jérôme LELEU [mailto:lel...@gmail.com] > *Sent:* Wednesday, April 13, 2016 5:15 AM > *To:* Mahantesh Prasad Katti > *Cc:* Jaroslav Kacer; cas-user@apereo.org > *Subject:* Re: [cas-user] RE: CAS+Oauth > > > > 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 > > > > > > > > > > 2016-04-12 16:04 GMT+02:00 Mahantesh Prasad Katti < > mahantesh.ka...@indecomm.net>: > > “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 > > > > *From:* cas-user@apereo.org [mailto:cas-user@apereo.org] *On Behalf Of *Jérôme > LELEU > *Sent:* Tuesday, April 12, 2016 7:25 PM > *To:* Mahantesh Prasad Katti > *Cc:* Jaroslav Kacer; cas-user@apereo.org > *Subject:* Re: [cas-user] RE: CAS+Oauth > > > > 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 > > > > > > 2016-04-12 15:27 GMT+02:00 Mahantesh Prasad Katti < > mahantesh.ka...@indecomm.net>: > > 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 > > > > *From:* Jérôme LELEU [mailto:lel...@gmail.com] > *Sent:* Tuesday, April 12, 2016 6:08 PM > *To:* Jaroslav Kacer > *Cc:* Mahantesh Prasad Katti; cas-user@apereo.org > *Subject:* Re: [cas-user] RE: CAS+Oauth > > > > 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 > > > > > > > > 2016-04-12 10:10 GMT+02:00 Jaroslav Kacer <jka...@idc.com>: > > 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 > > 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 > <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 > *Subject:* [cas-user] RE: CAS+Oauth > > > > Thanks much. Time for me to get to action mode. J > > > > Regards, > > Prasad > > > > *From:* Jaroslav Kacer [mailto:jka...@idc.com <jka...@idc.com>] > *Sent:* Friday, April 08, 2016 9:51 PM > *To:* Mahantesh Prasad Katti; 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 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. > > > > 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:mahantesh.ka...@indecomm.net > <mahantesh.ka...@indecomm.net>] > *Sent:* 8. April 2016 2:03 odp. > *To:* Jaroslav Kacer <jka...@idc.com>; 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 <jka...@idc.com>] > *Sent:* Friday, April 08, 2016 5:17 PM > *To:* Mahantesh Prasad Katti; 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 > > Skype: jkacer.idc > > > > > > *From:* Mahantesh Prasad Katti [mailto:mahantesh.ka...@indecomm.net > <mahantesh.ka...@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 <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-user@apereo.org [mailto:cas-user@apereo.org > <cas-user@apereo.org>] *On Behalf Of *Mahantesh Prasad Katti > *Sent:* 8. April 2016 9:45 dop. > *To:* 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 > <cas-user@apereo.org>] *On Behalf Of *Mahantesh Prasad Katti > *Sent:* Thursday, April 07, 2016 11:02 AM > *To:* 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. > 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. > 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. > 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 > <https://groups.google.com/a/apereo.org/d/msgid/cas-user/BY2PR02MB1332C21DFECA7E39E1787496CF950%40BY2PR02MB1332.namprd02.prod.outlook.com?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/CAP279LwWf_-wM5iEMSzkqVk6y84gMRifShLP_7etCc0ee%3Dw79w%40mail.gmail.com > <https://groups.google.com/a/apereo.org/d/msgid/cas-user/CAP279LwWf_-wM5iEMSzkqVk6y84gMRifShLP_7etCc0ee%3Dw79w%40mail.gmail.com?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/CAP279Lx2O7jdOXemkYWMtDqftn0Groamy-U_iwBe_k2MteRqCg%40mail.gmail.com. For more options, visit https://groups.google.com/a/apereo.org/d/optout.
