SSO sessions actuator endpoints

[Baron Fujimoto]

I noticed CAS documentation for SSO sessions identify actuator endpoints that seem like they would be useful to us.

<https://apereo.github.io/cas/7.0.x/authentication/Configuring-SSO.html#actuator-endpoints>

In particular, something like "/cas/actuator/ssoSessions/users/{username}" looks promising for helping to deal with compromised accounts where we'd like to kill off any existing SSO sessions for a compromised user.

But it's not clear to me how you actually use this in practice to accomplish this? In addition to how you would use the Get and Delete "flavors" of this, we'd need to strictly limit access to this capability – what are the access control options for these endpoints and how do you configure them? I couldn't find the relevant info on that page or via searches in the docs.

--

Baron Fujimoto <ba...@hawaii.edu> ::: UH Information Technology Services
minutas cantorum, minutas balorum, minutas carboratum descendus pantorum

[Ocean Liu]

Hi Baron,

Maybe you already know this, on [this documentation page](https://apereo.github.io/cas/7.0.x/authentication/Configuring-SSO.html#actuator-endpoints)

You can click the little "book" icon on the left of the endpoint, it will show you more information about this actuator endpoint, including the configuration.

About the access control option, CAS provides some basic ways to secure the endpoints, check these examples by Misagh Moayyed in his blog post [Apereo CAS - Actuator Endpoints & Monitoring](https://fawnoos.com/2023/10/25/cas70x-actuator-endpoints/#examples)

Hope this helps!

[Ocean Liu]

About how you would use the DELETE endpoint, we have never tried this before.

I am not sure if there is an app out there that can give you a web interface to do this.

But for manually deleting a session, I think you can just use browser dev tool console to init the request to delete the session like this:

```js

fetch('https://example.com/actuaor/ssoSessions/users/name', {
    method: 'DELETE'
})

```

About the `required-roles` for the access control, yeah, it looks promising. But I don't know if CAS provides a way to let you easily configure the roles without customization.

I think there is something in the CAS Management app that lets you do that.

That's all I know, good luck with everything.

And if you find more information about this, please post an update, because I am also interested in this topic!

Thank you!

On Wed, Jul 17, 2024 at 11:43 AM Baron Fujimoto <ba...@hawaii.edu> wrote:

Hi Ocean,

Mahalo, I had clicked on the book icon, but somehow missed the "Configuration" tab (doh!), so that was indeed helpful. I've used "required-ip-addresses" for access control for other endpoints, so that's familiar, but I see that "required-roles" is another option. This sounds potentially promising, but I haven't been able to find more information about how and where these roles are defined.

It's also still not clear to me how you use these endpoints if you want to use the DELETE capability. I think for our other uses of endpoints (e.g. health, info), they are GET type actions that merely report information. Unfortunately Misagh's blog post at fawnoos don't cover these cases for DELETE.

--

Ocean Liu | Enterprise Web Developer | Whitman College

WCTS Building 105F - 509.527.4973

[Baron Fujimoto]

Hi Ocean,

Mahalo, I had clicked on the book icon, but somehow missed the "Configuration" tab (doh!), so that was indeed helpful. I've used "required-ip-addresses" for access control for other endpoints, so that's familiar, but I see that "required-roles" is another option. This sounds potentially promising, but I haven't been able to find more information about how and where these roles are defined.

It's also still not clear to me how you use these endpoints if you want to use the DELETE capability. I think for our other uses of endpoints (e.g. health, info), they are GET type actions that merely report information. Unfortunately Misagh's blog post at fawnoos don't cover these cases for DELETE.

On Tue, Jul 16, 2024 at 11:57 AM Ocean Liu <li...@whitman.edu> wrote:

[Ray Bon]

We use 

cas.monitor.endpoints.endpoint.ssoSessions.required-ip-addresses=127.0.0.1

And admins log in to one of the servers and issue the delete with curl.

Ray

---

From: cas-...@apereo.org <cas-...@apereo.org> on behalf of Baron Fujimoto <ba...@hawaii.edu>
Sent: 17 July 2024 11:42
To: Ocean Liu <li...@whitman.edu>
Cc: CAS Community <cas-...@apereo.org>
Subject: [cas-user] Re: SSO sessions actuator endpoints

 

You don't often get email from ba...@hawaii.edu. Learn why this is important

--
- Website: https://apereo.github.io/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+u...@apereo.org.
To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/CAAjLUL2-j5_dFsZcBoYYfWPRmJnqzFx193C%2Bud8wk7jTs6ZYZg%40mail.gmail.com.

[Baron Fujimoto]

Oh, groovy. With the information so far, I've been able to get this to work as in Ray's example. Specifically, using the following properties:

management.endpoints.web.exposure.include=[...], ssoSessions
management.endpoint.ssoSessions.enabled=true
cas.monitor.endpoints.endpoint.ssoSessions.access=IP_ADDRESS
cas.monitor.endpoints.endpoint.ssoSessions.required-ip-addresses=127.0.0.1/32

And to invoke it using curl from the CAS server to read the ssoSessions for user=joebogus:

curl -k https://127.0.0.1:8443/cas/actuator/ssoSessions/users/joebogus

Apparently GET is the default request type, but to use DELETE:

curl -X DELETE -k https://127.0.0.1:8443/cas/actuator/ssoSessions/users/joebogus

So at least we have this as an option. Mahalo!

Poking around more, it seems like ROLE and AUTHORITY are other available Spring authorization requirements as described here <https://docs.spring.io/spring-security/reference/servlet/authorization/architecture.html>. Given that the CAS documentation says these "Require authenticated access to the endpoint along with ..." and that AFAIK the Spring security credentials are for authentication are defined statically with something like the following:

spring.security.user.name=casuser
spring.security.user.password=Mellon

Maybe this is less useful for what we'd hoped. I don't think we want to hardcode these into the cas properties. But maybe I'm wrong about how this works.

To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/YT3PR01MB994664C43753F61FC7D3B81CCEAC2%40YT3PR01MB9946.CANPRD01.PROD.OUTLOOK.COM.

[John Bergant]

You can use basic auth for these endpoints, you would want to store the password in a secure secrets file for the deployment.

cas.monitor.endpoints.endpoint.ssoSessions.access=AUTHENTICATED

spring.security.user.name=casuser

--- separate secrets file

spring.security.user.password={noop}Mellon

The curly brackets specify the encoder to use for the password.

One thing to note in 6.6.x this SSO endpoint does not remove Refresh Tokens that might have been created from a SSO session.