How to handle unsolicited responses on the SP-side of a SAML bridge?

[Nicolas Toniazzi]

Hello,

I have configured SimpleSamlPHP as an IdP to handle SAML SSO for multiple services.

SSP in also configured as a SAML bridge to allow a user to authenticate against external identity providers. Everything is working great.

But recently, one of those identity providers has started sending unsolicited responses to the SP-side of SSP. I managed to handle them, but I don't see how I can pass the bridge: the user is authenticated on the SP-side, but not on the IdP-side.

How can I force it?

Thanks,

Nicolas.

[Peter Schober]

* Nicolas Toniazzi <nicolas....@gmail.com> [2021-09-28 17:50]:

> But recently, one of those identity providers has started sending
> unsolicited responses to the SP-side of SSP. I managed to handle them, but
> I don't see how I can pass the bridge: the user is authenticated on the
> SP-side, but not on the IdP-side.

Can you describe the problem caused by unsolicited responses?

> How can I force it?

Assuming IDP support for SAML Metadata and conformant behaviour would
adding SPSSODescriptor/@AuthnRequestsSigned="true" to your metadata
(and of course actually signing your authn requests) avoid this?
Maybe there's a less drastic[1] way to achieve this.

-peter

[1] Signing your authn requests for no good reason also exposes your
SP to unauthenticated DoS attacks for no good reason.

[Nicolas Toniazzi]

Hello,

I'll try to describe my problem with the help of a picture. Please excuse the crudity of this model, I didn't have time to build it to scale. Or paint it ;-)

Here are the different elements, with SAMLv2 on both sides:

In SimpleSAMLphp (middle), I have a custom authentication source named "portal", similar to MultiAuth, that can handle our multi-tenant services.

When the authentication initiates from, say, "Service 1" on the left, the request is handled by the "portal" source and delegated to an SP ("bridge-1") which forwards it to the proper external IdP. Everything works well, the response is then handled by SimpleSAMLphp and returned to "Service 1".

If I look at the authData in SimpleSAMLphp's session, I get a "portal" entry.

When the authentication initiates from "IdP 1", the user is authenticated in SimpleSAMLphp and I see a "bridge-1" entry in the session. But I cannot take it any further.

→ How can I get SimpleSAMLphp to authenticate the user in the "portal" source and send it back to the default "Portal" service?

[Peter Schober]

* Nicolas Toniazzi <nicolas....@gmail.com> [2021-09-29 16:57]:

> I'll try to describe my problem with the help of a picture.

Sorry, I forgot that a proxy was at play.
(That's a nice and generally applicable illustration of SAML
proxying.)

Obviously, unless the party starting SSO at the IDP adds some
parameter to the (implementation-specific, non-SAML) SSO request *to*
the IDP, there will be no RelayState present once the subject is at
the SP. (And in this case that SP isn't even any of the protected
resources but the SP-side of the SAML proxy.)

For ordinary deployments (i.e., those that don't involve SAML
proxying) that may or may not be a problem as the SP can define a
default 'RelayState' (using the eponymous parameter[1]) where it sends
the subject's browser to when no RelayState is otherwise present.

I have no idea how this would work with SAML proxying where even the
SAML-proxied-SP to send a SAML Reponse to (from the proxy-IDP) would
need to be established (or defaulted, via configuration) in the first
place. I don't know whether SSP current supports that.

-peter

[1] https://simplesamlphp.org/docs/stable/saml:sp#section_4

[pat...@cirrusidentity.com]

For ordinary deployments (i.e., those that don't involve SAML
proxying) that may or may not be a problem as the SP can define a
default 'RelayState' (using the eponymous parameter[1]) where it sends
the subject's browser to when no RelayState is otherwise present.

I have no idea how this would work with SAML proxying where even the
SAML-proxied-SP to send a SAML Reponse to (from the proxy-IDP) would
need to be established (or defaulted, via configuration) in the first
place. I don't know whether SSP current supports that.

I believe if you set in authsources.php the  RelayState = "https://yourSSPserver/ssppath/saml2/idp/SSOService.php?spentityid=PORTAL_ENTITYID" then

for unsolicited logins, the SP side of your bridge/proxy with make an IdP initiated login request to the IdP side of the bridge/proxy. The IdP side will find the user has a session and make

an unsolicited assertion to the portal.     You could also add the portals domain name to your SSP's list of authorized domains and set the RelayState to the portal's SAML request invitation endpoint (which I think is only has support in shibboleth).  Like Peter said, this assumes you always want the user going to the same place if IdP 1 or IdP 2 initiate the login.

- Patrick

[Michael Grady]

So using SimpleSAML as proxy with a custom auth module based on MultiAuth (which supports the source query argument), I know the following type of link works, as we used this model for some portal-type links:

https://your.porxysspservice.org/simplesaml/saml2/idp/SSOService.php?source=proxiedIdpIdentifier&spentityid=entityid_of_sp_to_send_response_to&RelayState=url_where_user_should_end_up_at_after_service_processes_saml_response

[Nicolas Toniazzi]

Wow, it was so simple! Adding a RelayState in the authsources.php was all I needed.

Thank you all for your help.