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 [email protected].
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.
