Selection of IdP based on an attribute from the SAML Assertion
Peter Schober
peter.schober at univie.ac.at
Fri Jun 13 12:55:08 UTC 2025
Amit Dongaonkar via users <users at shibboleth.net> [2025-06-13 14:31 CEST]:
> I have a scenario where our SP needs to decide which IdP to request
> a SAML assertion based on one of the attributes received from the
> initial assertion received.
[...]
> If the 'userType' attribute has the alphanumeric value then we need
> to reach out to a different IdP and request another SAML assertion.
The SP provides you with all the recieved, decrytped, decoded, mapped
attributes sent by the "initial" IDP's assertion.
The SP also allows you to initiate SSO with an IDP given its entityID.
Here's how to do the missing step between those two:
Using the SP's sessionHook faciluty you can inject your own code into
the processing -- running on the same machine as the Shib SP, so it
has access to the attributes from the just created session. That code
needs to be accessible by the subject's web browser somehow, at any
path of your chosing. In that code you can perform any checks (or
lookups) you want and then decide what to do with the request.
If the signalling attribute is present and has a certain value you
issue an HTTP Response Header ("Location: ") to the subject's web
browser, pointing that redirect to the SP's session initiator with the
desired IDP's entityID (which your code determines from the value of
the signalling attribute) and the originally requested ressource
('return' query parameter) as parameters, e.g.
/Shibboleth.sso/Login=entityID=$other_idp&target=$return
If the signalling attribute is missing or is missing the expected
value(s) you let them pass by simply redirecting the browser to the
value of the provided 'return' query parameeter.
Best,
-peter
More information about the users
mailing list