Tom,
In CAS 5.1 there are some additional logout features,
https://apereo.github.io/cas/5.1.x/installation/Configuration-Properties.html#logout.
Although it is not exactly what you are asking, it may provide some additional
insight. See also,
https://apereo.github.io/cas/5.1.x/installation/Logout-Single-Signout.html.
Ray
On Mon, 2017-12-04 at 01:21 -0800, Tom Andersson wrote:
Hello all,
We a struggling with some logout / session management related issues with our
CAS OAuth clients. We are using CAS 5.0 and have use cases, where on CAS
logout, the OAuth access tokens of a user would need to be removed, but only
tokens granted for that specific SSO session. The current use case is related
to a service which uses the implicit grant flow to authenticate users.
Technically, as far as I understand, we would need to link access tokens to SSO
sessions (CAS doesn't seem to link the tokens in such a way), so that on SLO,
the access tokens granted for the SSO session could be revoked.
I understood that the SLO functionality is really not supported for the OAuth
protocol and I haven't found a way to handle this in CAS. Thus, we are thinking
about creating some external service, which could keep track of SSO sessions
and related access tokens, and then revoke the access tokens when receiving SLO
notification from CAS. So I looked into the SLO notification functionality
(back-channel), and seems like at least in the implicit grant case, the
notification contains the Service Ticket ID that was granted as part of the
authentication flow. Next problem is, that of course our external service has
not received such identifier in the login process and possibly the flow would
need to be changed to transmit this ID to the client (possible in the same
redirect request with the access token?).
Hopefully you get the picture of what we're attempting. The goal would be to
invalidate access tokens for a specific SSO session, but still keep access
tokens for possible other sessions of the same user (otherwise we could just
remove all tokens).
A few questions:
* Are we doing something completely wrong here? Maybe this is not the way to
handle SSO sessions and OAuth access at all? Could there be some other ways of
looking at the problem at hand?
* Is the approach of modifying the authentication flows (authorization code
grant or implicit grant) in such a way that our external service would have
some handle to the SSO session, meaningful at all? The service would then hold
a list: "ST-123": ["AT-1", "AT-2", "AT-3"...]. Or is it actually the TGT that
we should be able to transfer to the service on login, and also deliver the
same TGT on SLO notification? Somehow this feels wrong.
There are also a few issues, which may be bugs, related to this:
* The logoutUrl setting of a service configuration doesn't seem to propagate,
we always have logoutUrl pointing to the service URL of the callbackAuthorize
service.
* All access tokens seem to have a service mapping to the callbackAuthorize
-service. Is this by design? So we can not know which service an access token
has actually been granted for (unless searching for it based on the client ID
in the callbackAuthorize service URL)
Thanks for any ideas!
Tom
--
Ray Bon
Programmer analyst
Development Services, University Systems
2507218831 | CLE 019 | r...@uvic.ca
--
- 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/1512408048.1769.4.camel%40uvic.ca.
