shib-cas-authenticator, proxy tickets, and third-party services

[Janemarie Duh]

We are running CAS v6.6.3 and Spring Boot v2.7.3 with two production nodes behind an LB. Hazelcast is used for managing tickets. CAS ticket timeouts are the default.

We are using shib-cas-authenticator v4.0.0 for external auth from our Shibboleth IdP (v4.1.6). Most, but not all, SAML services on the IdP go to CAS and there are numerous services that are CAS-only.

We have an implementation of Campus Cloud by Ready Education (makers of CampusGroups) as a portal to access third-party services that are integrated with the IdP or CAS. The Ready Education (RE) service itself uses SAML and shib-cas for SSO. The desired behavior is a user who is logged into RE / Campus Cloud should not be prompted to auth to a service they access from a tile within RE. The RE session itself only ends when a user clicks 'log out'.

There is no CAS client in front of RE. What RE does is create and pass its own auth token that CAS checks for using custom JAVA code. I'm not certain whether CAS creates tickets / sessions based on the presence of that token.The two CAS-only services we added as tiles to RE work as expected. The links on the tiles are in the form of $CAS_login_url?$service_url.

The one Shib-CAS service we added to RE doesn't work as desired. The service login URL initiates a SAML transaction and the user is prompted to authenticate. Our IdP controls SSO sessions, not CAS. Shib isn't aware of the RE auth token, plus it wouldn't know what to do with it. The question of how to make Shib aware of the RE token, possibly by configuring it to receive, store, and pass back the token to CAS might be a question for the Shib list.

Because of the shib-cas-authenticator integration, I'm starting with this list. Is anyone using RE's Campus Cloud or another portal platform with shib-cas-authenticator?

Though we're not particularly looking to replace the existing RE token java code, I question whether the implementation couldn't be streamlined by using CAS proxy tickets, particularly if they could be used in the Shib-CAS flow to provide seamless SSO.

Alternatively, could CAS create an ST based on the presence of the RE token to pass with the entityID of the Shib-CAS service in the assertion back to the IdP?

Any insight is much appreciated.

     Janemarie


--

Janemarie Duh

UD Information Technologies

Identity and Access Management Specialist

du...@udel.edu

[Ray Bon]

Janemarie,

Proxy tickets are for backend service communication. The user does not interact with the other service. It is not the same thing as proxied/delegated authentication.

If I understand correctly, shibboleth is handling the username/password and therefore the SSO session.

Does the one SAML service redirect to shibboleth or cas?

If the SAML request goes to cas, perhaps it can be delegated to shib, https://apereo.github.io/cas/6.6.x/integration/Delegate-Authentication.html

Ray

On Fri, 2023-08-04 at 13:24 -0400, Janemarie Duh wrote:

Notice: This message was sent from outside the University of Victoria email system. Please be cautious with links and sensitive information.

[Janemarie Duh]

Ray,

Thank you for your response.

Yes, your understanding is correct. For the one SAML service - there will be more - Shib hands off authn to CAS but Shibboleth controls the SSO session.

A barrier to Shib handling authn rather than CAS is that CAS logins are protected by 2FA. We don't have a solution in place yet for MFA on Shib for a number of reasons. Actually, in this case, that might not be an issue, but unless Shib could be made aware of the Ready Education auth token, or there is a Shib-native way to recognize the existing RE session, the user would still be prompted to log in a second time upon accessing service2.

Re: proxy tickets and back-end communication, wouldn't the proxy exchange work in cases where users access service2 from service1 and thus not require the user to log into service2? Particularly, if service2 was using CAS for authn, not shib-cas-authenticator?

          Janemarie

--
- 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+u...@apereo.org.
To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/dc2aa3b54a2635f7ed550ad3be88af8bcbe83958.camel%40uvic.ca.

[Ray Bon]

Janemarie,

Re proxy tickets. The user would not interact with service 2, just with service 1. Service 1 can make make calls to service 2 for data, etc.; or service 1 could screen scrape service 2, or some other mechanism, to make it look like the user is accessing service 2. But the user only ever logs in to service 1 (only one service ticket is issued). Service 1 and service 2 have to be registered in cas as proxy services, https://apereo.github.io/cas/6.6.x/authentication/Configuring-Proxy-Authentication.html, and they need to know about cas so that service 1 can get proxy tickets and service 2 can validate them.

Cas can also support SAML. So perhaps adding that feature to cas and registering the  service with cas instead of shib might help. https://apereo.github.io/cas/6.6.x/authentication/Configuring-SAML2-Authentication.html

However, if the service URL is initiating a saml transaction, it sounds like this should be solved in the configuration of the tile in RE.

Ray