Condensing multiple SSO integrations?

[Jeremiah Garmatter]

Hello,

My organization is migrating to a product called Workday.

This product encourages you to spin up different "tenants" (instances) of the product.

Unfortunately, each of these tenants requires a separate SAML integration.

Is there some way I could condense them into one integration?

The metadata is nearly identical between them. There may be a different key and the URLS may differ in a small portion of the path, otherwise they are the same.

To be honest, I'm not sure what a feature like this would look like but if anyone has ideas I'm open to suggestions. CAS 7.3.1, SAML integrations.

[Ray Bon]

Jeremiah,

SAML services do not have the concept of regular expression matching entityID.

Are you able to set the entityID and encryption key in workday SAML config? 

Each tenant will have a unique AssertionConsumerService. If you maintain the metadata locally, you can have multiple ACS stanzas.

Combining tenants like this will prevent you from creating a separation of concerns in your user base since authn decisions are made on the entityID.

Ray

---

From: 'Jeremiah Garmatter' via CAS Community <cas-...@apereo.org>
Sent: April 23, 2026 13:13
To: CAS Community <cas-...@apereo.org>
Subject: [cas-user] Condensing multiple SSO integrations?

 

--
- 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 visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/fb0b3db3-2624-4870-a7e5-d2955e74b06cn%40apereo.org.

[Jeremiah Garmatter]

Thanks Ray,

I can set both the entity id and keys in each tenant.

If I understand correctly, you suggest that I use the same entityID and key between each tenant but add a <md:AssertionConsumerService ... /> line to the "common metadata".

No matter which tenant they hit, my IdP will see the request as if it came from a single SP.

I thought the ACS had something to do with redirecting the user back to the SP. How does that work when you have more than one?

[Misagh]

There are a few ways to solve this problem and all vary in degrees of
complexity and depend on how much pain you're willing to suffer, and
how you want the integration with the SP to look like going forward.

A balanced approach likely would be:

1. The SP metadata for each individual tenant would be collected.
2. All that content would be pasted into a single XML file inside an
<EntitiesDescriptor> element
3. Consider harmonizing the entity IDs for each tenant, i.e. they all
begin with https://my.workday.com/xyz
3. Register a single service entry with CAS, reference the single XML
file for metadata and for the service id specify something like:
"^https://my.workday.com.*"

Pros and cons. Test thoroughly.

[Jeremiah Garmatter]

Thank you for the suggestions.

I'll look into these ideas. They sound exactly what I'm looking for.

[Jeremiah Garmatter]

I am happy to report that my tests were successful!

By keeping the signing key, signing cert, and entity ID the same between my test instances, I was able to register each instance as a single service within CAS.

All I had to do was add each instance's AssertionConsumerService to the metadata.

This will greatly improve the registration process for Workday.

Thanks for the help.