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
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
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,
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
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
