SP domain update / change

[Neil Hitchmough]

On the application that our SSO SP is setup, the domain name needs to change for branding purposes i.e

oldbrand.com to newbrand.com

Is there a way of redirecting existing SSO connections to the new domain without having to provide updated Idp metadata to each of our customers that use it to login to our application? 

Thanks

Neil

[Tim van Dijen]

In the SAML request you can specify the ACS-url where the IdP should send it's response..

If you do that you _must_ sign the request with a key known to the IdP, or it will refuse to process the request.

It could be possible, I think, but the scenario requires that you are already signing your requests in the current situation.

- Tim

Op maandag 2 oktober 2023 om 17:47:34 UTC+2 schreef ne...@mojofuel.com:

[Peter Brand]

Neil Hitchmough <ne...@mojofuel.com> [2023-10-02 17:48 CEST]:

> Is there a way of redirecting existing SSO connections to the new
> domain without having to provide updated Idp metadata to each of our
> customers that use it to login to our application?

TL;DR: Update the metadata at all IDPs. That's what metadata is for
and works in all scenarios.

(Personally I'd make sure the ACS URLs are in place and work on both
vhosts/servers. Then switch over one IDP at a time and make sure it
works. Or update the metadata you're providing once you have verfied
that IDPs consuming updated metadata will continue to work.)

The answer to your literal question probably won't work well (or at
all) but YMMY: It might be possible to have your old vhost/server
respond with HTTP 307/308 to the HTTP POST'ed SAML Responses from the
IDPs (mediated by the subject's web browser) but I doubt that relying
on web browser behaviour (to re-POST the SAML Response to the new
vhost/server) is the best idea. It might work, it might not.
(Also your own SAML SP implememtation would have to make allowances
for accepting a SAML protocol message at a different URL than what's
written inside the SAML protocol message itself. That might be fixable
with hacking or configuration but I'm saying it might require hacking
or some/creative configuration.)

With SP-initiated SSO you're telling the IDP where to send the
Response so initially there's no issue of the IDP sending the response
to the old URL: You're telling it to send it to the new URL.
*But* SAML also requires the IDP to verify the location to be sending
a SAML Response to and most IDP implementations use metadata for
that. (Sometimes literally SAML 2.0 Metadata, often internal data
structures derived from that.)
So while your SP could send SAML authentication requests with a
different ACS URL a conformant IDP would have to fail your request if
the requested ACS URL doesn't match what they have on record for your
SP -- as Tim already said.

And while Tim also suggested that signing the authn requests from your
SP might help I'm not sure many SAML IDP implementations will
automatically accept signed requests as alternative verification of
the requested ACS URL. I think you'd have to experiment with
this. With some IDPs it might work, maybe not with others. (At least
the Shibboleth IDP implementation requires a configuration change to
accept unknown-to-the-IDP-via-metadata ACS URLs even when the request
is signed by a known key and the request can be cryptographically
verified.)

And there's also IDP-initiated SSO, meaning a proprietary /
IDP-specific request to the IDP to start SSO to your SP, instead of a
standard-defined SAML authentication request (sometimes called
"unsolicited responses" because the IDP sends a SAML Response to your
SP when your SP hasn't sent a SAML authn request to that IDP first):
Those cannot possibly be signed by your SP (since there's no request
from your SP at all) and so signing couldn't work here.
Only you can know whether you'll have to take care of IDP-initiated
SSO / unsolicited responses in your deployment.

HTH,
-peter

[Peter Brand]

> Neil Hitchmough <ne...@mojofuel.com> [2023-10-02 17:48 CEST]:
> > Is there a way of redirecting existing SSO connections to the new
> > domain without having to provide updated Idp metadata to each of our
> > customers that use it to login to our application?
>
> TL;DR: Update the metadata at all IDPs. That's what metadata is for
> and works in all scenarios.

FTR, in the context of my own services (and the set of IDPs I'm
dealing with, with is large-scale WebSSO federation in the academic
sector) I'd *only* be adding another ACS URL to the published SAML 2.0
Metadata describing my existing service provider that that'd be it!

The SP would generate authentication requests at the new vhost/server
(when accessed at the new vhost/server; and requests with ACS URLs of
tle old vhost/server when accessed at the old vhost/server).
And IDPs would auto-configure themselfs to learn of the additional ACS
URL at the new vhost/server, finding the requested ACS URL to match
what they have on record for my service.

So with properly managed SAML metadata and sufficiently compliant
implementations this is a complete non-issue.
(Sadly neither of those 2 things are commonly given, certainly not for
most SAML implementations except for SimpleSAMLphp and very few others.)

-peter