Is Multi-Tenancy best option for handling domain name switch?

SAML for ASP.NET
1

Hi

My client is switching domain names and for illustration purposes let’s say they are changing from abc.com to xyz.com.

At the moment SSO is initiated from the identity provider by submitting a request to https://abc.com/SAML/AssertionConsumerService.aspx

I was wondering whether Multi-Tenancy would allow me to support requests sent to either https://abc.com/SAML/AssertionConsumerService.aspx or https://xyz.com/SAML/AssertionConsumerService.aspx so that users can switch over gradually.

<SAMLConfigurations xmlns="urn:componentspace:SAML:2.0:configuration"> 
  <SAMLConfiguration Name="tenant1"> 
    <ServiceProvider Name="SP1"/> 
    <PartnerIdentityProviders> 
      <PartnerIdentityProvider Name="IdP1"/> 
      <PartnerIdentityProvider Name="IdP2"/> 
    </PartnerIdentityProviders> 
  </SAMLConfiguration> 
 
  <SAMLConfiguration Name="tenant2"> 
    <ServiceProvider Name="SP2"/> 
    <PartnerIdentityProviders> 
      <PartnerIdentityProvider Name="IdP3"/> 
      <PartnerIdentityProvider Name="IdP4"/> 
    </PartnerIdentityProviders> 
  </SAMLConfiguration> 
</SAMLConfigurations>

When I tried this I got an error advising ‘One or more XML configuration schema errors occurred’.

In the above example, taken from the documentation each PartnerIdentityProvider has a unique Name however in my scenario both service providers would have the same list of PartnerIdentityProvider with the same names.

Would that be the problem?

Thanks in advance.

2

The simplest approach is to set the DisableDestinationCheck configuration flag to true. This disables the check of the destination field in the SAML response against the configured assertion consumer service URL. That way either https://abc.com/SAML/AssertionConsumerService.aspx or https://xyz.com/SAML/AssertionConsumerService.aspx can be used. Once the domain name switch has completed, you can remove this flag.

Here’s an example of specifying the flag.

<PartnerIdentityProvider 
  Name="https://ExampleIdentityProvider"
  Description="Example Identity Provider"
  DisableDestinationCheck="true"
  SingleSignOnServiceUrl="https://localhost:44390/SAML/SSOService.aspx"
  SingleLogoutServiceUrl="https://localhost:44390/SAML/SLOService.aspx">
  <PartnerCertificates>
    <Certificate FileName="Certificates\idp.cer"/>
  </PartnerCertificates>
</PartnerIdentityProvider>

You could use a multi-tenancy configuration but this is a lot more involved and not recommended for this use case. However, if you did want to take this approach, you can use the ValidateConfig project under the Examples\Configuration folder to get more details regarding the syntax errors. Just run ValidateConfig from the command line and specify your saml.config file.

3

Many thanks for the response and the DisableDestinationCheck seems like a great option.

I just have one more question.

At the moment I have the below in my saml.config file

<ServiceProvider Name="https://abc.com/" Description="Portal" AssertionConsumerServiceUrl="~/SAML/AssertionConsumerService.aspx">
  <LocalCertificates>
    <Certificate FileName="Certificates\abc.pfx" Password="Ci2mWaYbyXq"/>
  </LocalCertificates>
</ServiceProvider>

And an example of a PartnerIdentityProvider would be

<PartnerIdentityProvider Name="https://sts.windows.net/123.../" Description="123 Partner" SignAuthnRequest="true">
  <PartnerCertificates>
    <Certificate FileName="Certificates\123.cer"/>
  </PartnerCertificates>
</PartnerIdentityProvider>

In order to facilitate submissions posted to https://xyz.com/SAML/AssertionConsumerService.aspx would I not need to include a reference to the xyz.pfx certificate file in the service provider?

Thanks in advance

4

The abc.pfx is only used to sign SAML authn requests or SAML logout messages, or to decrypt encrypted SAML assertions.

From your description, SAML SSO is initiated at the identity provider. Therefore, SAML authn requests aren’t sent and therefore won’t be signed.

The configuration doesn’t include SAML logout URLs so SAML logout messages aren’t sent and therefore won’t be signed.

I can’t tell from the configuration whether SAML assertions are encrypted although in most cases they aren’t. Assuming they aren’t, abc.pfx won’t be used.

You could safely remove the local certificate configuration as it isn’t in use.

5

Thanks. That’s worked a treat. Thanks for all your help.

6

You’re very welcome.