I wanted to report additional findings back here. Apparently, the AssertionConsumerService URL is an optional attribute that doesn't need to be sent by the SP. While testing, I used my own Shibboleth SP instance. This instance sends the ACS URL during the initial AuthN request, so everything worked as expected. Unfortunately, Workday does not send the ACS during authentication so this doesn't work in my case.
The idea is still valid, but ultimately at the discretion of the SP whether they include that xml attribute or not. On Friday, May 8, 2026 at 10:31:02 AM UTC-4 Jeremiah Garmatter wrote: > 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. > > On Thursday, April 30, 2026 at 11:50:43 AM UTC-4 Jeremiah Garmatter wrote: > >> Thank you for the suggestions. >> I'll look into these ideas. They sound exactly what I'm looking for. >> >> On Friday, April 24, 2026 at 7:23:35 PM UTC-4 Misagh wrote: >> >>> 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. >>> >>> On Thu, Apr 23, 2026 at 2:31 PM 'Jeremiah Garmatter' via CAS Community >>> <[email protected]> wrote: >>> > >>> > 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. >>> > >>> > -- >>> > - 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 [email protected]. >>> > To view this discussion visit >>> https://groups.google.com/a/apereo.org/d/msgid/cas-user/fb0b3db3-2624-4870-a7e5-d2955e74b06cn%40apereo.org. >>> >>> >>> >> -- - 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 [email protected]. To view this discussion visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/90b712fd-0d22-43c5-914a-0e26ed507814n%40apereo.org.
