Re: [cas-user] Getting new JWT with CAS
Ray, thank you for clarifications. Right, it probably means instead of 302 response we need to send 401 back and then ajax script needs to call CAS in a different subdomain for a login (that indeed won't require user to provide creds if the CAS login session is still valid). Again, it's all doable, but, I hope, there are ways to avoid these complexities. At the end application has all the information about the user in the application session to place into JWT for sending to an internal microservice. Everything we really need is to generate JWT from this data in a standard centralized way or request a new JWT through CAS On Thursday, April 11, 2019 at 2:10:09 PM UTC-4, rbon wrote: > > Ken, > > I meant invalidate the app session, not the login session. If the CAS > session is still valid, user would not see login screen. > Session invalidation is more of a concern if your app stores data in the > session. > > Ray > > On Thu, 2019-04-11 at 10:56 -0700, Ken Zilber wrote: > > > > > > Thank you for the quick response. > > Sending ajax calls to a subdomain the script did not come from will be an > issue, however, there are solutions (it is doable). My point/question is > that it won't be as seamless/easy as with simple http browser calls > (javascript needs special call handlers, iframes, ...) and I would prefer > to avoid it. > > On another comment - we certainly don't want to invalidate active > application session and ask user to re-login just because our internal JWT > necessary for internal communication expired. > > On Thursday, April 11, 2019 at 1:29:39 PM UTC-4, rbon wrote: > > Ken, > > To clarify, the TGT is not sent to the client. TGC is all that is needed. > If all your apps are on same domain, does CORS apply? > > You could invalidate your app session when JWT expires. App would then > follow normal authentication behaviour and redirect to CAS. This of course > would not work if you stored data in the app session. I suppose it is > possible to have a field in the session to indication authentication (php > probably works like this). > > I have not used JWT nor CAS ajax so take my suggestion as a wild idea. > > Ray > > On Thu, 2019-04-11 at 09:18 -0700, Ken Zilber wrote: > > JWT looks as a nice way for a CASified use-facing application to > communicate with internal REST APIs/microservices. These microservices > can't be accessed by users directly, don't have state and don't need to > deal with sessions and don't need to become CAS controlled services and > correspondingly we don't need to implement CAS protocol with its Proxy > extension that looks a little bit too complex. JWT fits well in this > scenario and CAS can become a great way to generate JWTs for internal > microservice communication. > > It's also clearly described in the CAS documentation that CAS "JWT, the > token itself is not an ID token, cannot be refreshed and must be obtained > again once you deem it expired". > > JWT suppose to be a relatively short lived token as it's not easy to > invalidate it, so we do need a way to obtain a new one when it expires. In > our setting we see two options to do it: > 1. As soon as the user facing CASified application finds that JWT stored > in its user session expired it will issue 302 redirect back to the user > with request to re-login (no need for user enter login/password if TGT is > still valid). This will produce a new JWT. It will work well for the user > http requests, but becomes tricky for the user ajax-like calls due to CORS. > It's still doable particular taking into consideration that our CAS server > and applications are in the same domain, but involves custom client-side > (in the browser) support that concerns me. > 2. Taking an advantage of having CAS server and application in the same > domain we may simply make TGC available for all subdomains in our domain > (not just for CAS server). Then using user's TGT from the cookie, > application may request new JWT on behalf of the user directly from CAS > through a back channel (CAS REST API) when it's needed. I read about > concerns that storing TGT in the application session "opens up a big > security vulnerability". I don't think it would be applied in our case as > application has the TGT only till the user request exists and application > does not try to store it. Still, it would be nice to hear other opinions on > this. > > I appreciate your comments on choosing between #1 and #2 above and it > would be also great to hear about other approaches to centrally generate > JWT with CAS. Thank you. > > -- - Website: https://apereo.github.io/cas - Gitter Chatroom: https://gitter.im/apereo/cas - L
Re: [cas-user] Getting new JWT with CAS
Thank you for the quick response. Sending ajax calls to a subdomain the script did not come from will be an issue, however, there are solutions (it is doable). My point/question is that it won't be as seamless/easy as with simple http browser calls (javascript needs special call handlers, iframes, ...) and I would prefer to avoid it. On another comment - we certainly don't want to invalidate active application session and ask user to re-login just because our internal JWT necessary for internal communication expired. On Thursday, April 11, 2019 at 1:29:39 PM UTC-4, rbon wrote: > > Ken, > > To clarify, the TGT is not sent to the client. TGC is all that is needed. > If all your apps are on same domain, does CORS apply? > > You could invalidate your app session when JWT expires. App would then > follow normal authentication behaviour and redirect to CAS. This of course > would not work if you stored data in the app session. I suppose it is > possible to have a field in the session to indication authentication (php > probably works like this). > > I have not used JWT nor CAS ajax so take my suggestion as a wild idea. > > Ray > > On Thu, 2019-04-11 at 09:18 -0700, Ken Zilber wrote: > > JWT looks as a nice way for a CASified use-facing application to > communicate with internal REST APIs/microservices. These microservices > can't be accessed by users directly, don't have state and don't need to > deal with sessions and don't need to become CAS controlled services and > correspondingly we don't need to implement CAS protocol with its Proxy > extension that looks a little bit too complex. JWT fits well in this > scenario and CAS can become a great way to generate JWTs for internal > microservice communication. > > It's also clearly described in the CAS documentation that CAS "JWT, the > token itself is not an ID token, cannot be refreshed and must be obtained > again once you deem it expired". > > JWT suppose to be a relatively short lived token as it's not easy to > invalidate it, so we do need a way to obtain a new one when it expires. In > our setting we see two options to do it: > 1. As soon as the user facing CASified application finds that JWT stored > in its user session expired it will issue 302 redirect back to the user > with request to re-login (no need for user enter login/password if TGT is > still valid). This will produce a new JWT. It will work well for the user > http requests, but becomes tricky for the user ajax-like calls due to CORS. > It's still doable particular taking into consideration that our CAS server > and applications are in the same domain, but involves custom client-side > (in the browser) support that concerns me. > 2. Taking an advantage of having CAS server and application in the same > domain we may simply make TGC available for all subdomains in our domain > (not just for CAS server). Then using user's TGT from the cookie, > application may request new JWT on behalf of the user directly from CAS > through a back channel (CAS REST API) when it's needed. I read about > concerns that storing TGT in the application session "opens up a big > security vulnerability". I don't think it would be applied in our case as > application has the TGT only till the user request exists and application > does not try to store it. Still, it would be nice to hear other opinions on > this. > > I appreciate your comments on choosing between #1 and #2 above and it > would be also great to hear about other approaches to centrally generate > JWT with CAS. Thank you. > > -- - Website: https://apereo.github.io/cas - Gitter Chatroom: https://gitter.im/apereo/cas - List Guidelines: https://goo.gl/1VRrw7 - Contributions: https://goo.gl/mh7qDG --- 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. To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/4f6ded35-2cb1-48b5-9220-f821e84e2e05%40apereo.org.
[cas-user] Getting new JWT with CAS
JWT looks as a nice way for a CASified use-facing application to communicate with internal REST APIs/microservices. These microservices can't be accessed by users directly, don't have state and don't need to deal with sessions and don't need to become CAS controlled services and correspondingly we don't need to implement CAS protocol with its Proxy extension that looks a little bit too complex. JWT fits well in this scenario and CAS can become a great way to generate JWTs for internal microservice communication. It's also clearly described in the CAS documentation that CAS "JWT, the token itself is not an ID token, cannot be refreshed and must be obtained again once you deem it expired". JWT suppose to be a relatively short lived token as it's not easy to invalidate it, so we do need a way to obtain a new one when it expires. In our setting we see two options to do it: 1. As soon as the user facing CASified application finds that JWT stored in its user session expired it will issue 302 redirect back to the user with request to re-login (no need for user enter login/password if TGT is still valid). This will produce a new JWT. It will work well for the user http requests, but becomes tricky for the user ajax-like calls due to CORS. It's still doable particular taking into consideration that our CAS server and applications are in the same domain, but involves custom client-side (in the browser) support that concerns me. 2. Taking an advantage of having CAS server and application in the same domain we may simply make TGC available for all subdomains in our domain (not just for CAS server). Then using user's TGT from the cookie, application may request new JWT on behalf of the user directly from CAS through a back channel (CAS REST API) when it's needed. I read about concerns that storing TGT in the application session "opens up a big security vulnerability". I don't think it would be applied in our case as application has the TGT only till the user request exists and application does not try to store it. Still, it would be nice to hear other opinions on this. I appreciate your comments on choosing between #1 and #2 above and it would be also great to hear about other approaches to centrally generate JWT with CAS. Thank you. -- - Website: https://apereo.github.io/cas - Gitter Chatroom: https://gitter.im/apereo/cas - List Guidelines: https://goo.gl/1VRrw7 - Contributions: https://goo.gl/mh7qDG --- 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. To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/0977ff26-8b01-48ee-a182-72458a343c40%40apereo.org.
[cas-user] Refreshing/
JWT looks as a nice way for a CASified use-facing application to communicate with internal REST APIs/microservices. These microservices can't be accessed by users directly, don't have state and don't need to deal with sessions and don't need to become CAS controlled services and correspondingly we don't need to implement CAS protocol with its Proxy extension that looks a little bit too complex. JWT fits well in this scenario and CAS can become a great way to generate JWTs for internal microservice communication. It's also clearly described in the CAS documentation that CAS "JWT, the token itself is not an ID token, cannot be refreshed and must be obtained again once you deem it expired". JWT suppose to be a relatively short lived token as it's not easy to invalidate it, so we do need a way to obtain a new one when it expires. In our setting we see two options to do it: 1. As soon as the user facing CASified application finds that JWT stored in its user session expired it will issue 302 redirect back to the user with request to re-login (no need for user enter login/password if TGT is still valid). This will produce a new JWT. It will work well for the user http requests, but becomes tricky for the user ajax-like calls due to CORS. It's still doable particular taking into consideration that our CAS server and applications are in the same domain, but involves custom client-side (in the browser) support that concerns me. 2. Taking an advantage of having CAS server and application in the same domain we may simply make TGC available for all subdomains in our domain (not just for CAS server). Then using user's TGT from the cookie, application may request new JWT on behalf of the user directly from CAS through a back channel (CAS REST API) when it's needed. I read about concerns that storing TGT in the application session "opens up a big security vulnerability". I don't think it would be applied in our case as application has the TGT only till the user request exists and application does not try to store it. Still, it would be nice to hear other opinions on this. I appreciate your comments on choosing between #1 and #2 above and it would be also great to hear about other approaches to centrally generate JWT with CAS. Thank you. -- - Website: https://apereo.github.io/cas - Gitter Chatroom: https://gitter.im/apereo/cas - List Guidelines: https://goo.gl/1VRrw7 - Contributions: https://goo.gl/mh7qDG --- 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. To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/5f2d5e0a-7d7d-480c-afa5-8ffe0995cba5%40apereo.org.
