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
- 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/1933a987fcdf31ddea2165256e1302b794854b8a.camel%40uvic.ca.

Reply via email to