Selection of IdP based on an attribute from the SAML Assertion

[Amit Dongaonkar]

Thanks Peter.
This is helpful.


Thanks and Regards,

Amit Dongaonkar

________________________________
From: users <users-bounces at shibboleth.net> on behalf of Peter Schober via users <users at shibboleth.net>
Sent: Friday, June 13, 2025 8:55 AM
To: users at shibboleth.net <users at shibboleth.net>
Cc: Peter Schober <peter.schober at univie.ac.at>
Subject: Re: Selection of IdP based on an attribute from the SAML Assertion

CAUTION : EXTERNAL SENDER | Proceed carefully when clicking links or opening attachments.

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
--
For Consortium Member technical support, see https://shibboleth.atlassian.net/wiki/x/ZYEpPw
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20250613/107155f8/attachment.htm>