Multiple SingleSignOnService URLs for one IdP

[Frank]

We are trying to connect our SP to an IdP that has multiple "portals" for users to log into.  Each portal has a different URL that we have configured in saml20-idp-remote.php.  However, the response from the IdP has the same entityID regardless on which portal we initiated the SSO process through.  This is causing the error below to be thrown as the entityID is not matching what was used to initialize the request.  Is there anyway to have multiple SingleSignOnService URLs that all have a response with the same entityID?

Thank you!

SimpleSAML_Error_Error: UNHANDLEDEXCEPTION

Backtrace:
1 www/_include.php:45 (SimpleSAML_exception_handler)
0 [builtin] (N/A)
Caused by: SimpleSAML_Error_Exception: Cannot retrieve metadata for IdP 'AAAAAA' because it isn't a valid IdP for this SP.
Backtrace:
2 modules/saml/lib/Auth/Source/SP.php:112 (sspmod_saml_Auth_Source_SP::getIdPMetadata)
1 modules/saml/www/sp/saml2-acs.php:91 (require)
0 www/module.php:135 (N/A)

[Peter Schober]

* Frank <junk...@gmail.com> [2016-09-14 06:06]:

> Is there anyway to have multiple SingleSignOnService URLs that all
> have a response with the same entityID?

Not in SAML Metadata. For each Binding you can only have a single
SingleSignOnService element (as it's not an indexed endpoint).

Now if all entities in your deployment only used SimpleSAMLphp
metadata (i.e., nested PHP arrays) it's probably not unconvievable,
but likely not currently supported for the reason given above.

-peter

[Mike Grady]

Peter is right, there would be no useable way to represent it in SAML metadata, but  we've certainly taken advantage of the fact that using SimpleSAML as an IdP Proxy, with a variation on the MultiAuth module, it has "virtual SSO endpoints" in the sense that you can tell the SP the endpoint is the standard endpoint with an added "source=whatever" argument to it. That source argument is then available to tie back to a specific authn source, and avoid discovery. But in all cases, the IdP has just one entityID. But you can't list those "virtual endpoints" in SAML metadata, because you'd just have a bunch of say SAML2 POST SSO endpoints, and an SP wouldn't have any way of knowing which to use. Yon can only list the "unadorned SAML2 POST endpoint"  in the metadata.

But for services where they just have you configure the SSO endpoint, instead of deriving it from the SAML metadata, then you can just tell it that the endpoint is .../saml2/idp/SSOService.php?source=XXXXX

You could, of course, change that query argument or do it with added PATH info, as long as you write the code to do something with that. We have done it with "../saml2/idp/SSOService.php/XXXXX" also, where again, the XXXXX told us the authn source "on the other side of the Proxy" we were to use.

[Frank]

Thank you for your responses!  I think that we will just setup multiple SPs on vhosts to solve the issue.