Single Service Provider with Multiple IDP's

Wed Oct 9 19:43:07 EDT 2019

Julio,

The built-in metadata generator is only intended as a template or a starting point for actual metadata.  In this case, since you've got two different websites behind a single EntityProvider, you'll need to modify your metadata manually so that wt.website.com is also considered a valid recipient of assertions.  You'll need at least:

   <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://wt.website.com/Shibboleth.sso/SAML2/POST" index="7"/>

Look at the outbound AuthnRequest to see where it's requesting users be sent after they've successfully logged in.  You'll likely see that it's still trying to send users to st.website.com/Shibboleth.sso/SAML2/POST, which is both wrong and should be explicitly prevented by policy, which probably means the SSO configuration is still off.  A MetadataFilter whitelist inside each ApplicationOverride would be wise.

Take care,

Nate.

--------

The Art of Access ®

Nate Klingenstein | Principal

https://www.signet.id/ 

-----Original message-----
From: Julio Lopez
Sent: Wednesday, October 9 2019, 4:06 pm
To: Shib Users
Subject: Re: Single Service Provider with Multiple IDP's

Reporting back.
 I've upgraded to 3.0.4.1 and configured Shibboleth
  As before, Site ID 1 (st.website.com) works for users of Company A
 Site ID 1518374912 (wt.website.com) works for Company A but we would expect the URL to be redirected to Company B IDP.
  When I connect to st.website.com/Shibboleth.sso/Metadata I get the metadata file with the following entries.
     <md:ArtifactResolutionService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://st.website.com/Shibboleth.sso/Artifact/SOAP" index="1"/>
    <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location="https://st.website.com/Shibboleth.sso/SLO/Artifact"/>

    <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://st.website.com/Shibboleth.sso/SLO/POST"/>

    <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://st.website.com/Shibboleth.sso/SLO/Redirect"/>

    <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://st.website.com/Shibboleth.sso/SLO/SOAP"/>

    <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://st.website.com/Shibboleth.sso/SAML2/POST" index="1"/>

    <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign" Location="https://st.website.com/Shibboleth.sso/SAML2/POST-SimpleSign" index="2"/>

    <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location="https://st.website.com/Shibboleth.sso/SAML2/Artifact" index="3"/>

    <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" Location="https://st.website.com/Shibboleth.sso/SAML2/ECP" index="4"/>

    <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post" Location="https://st.website.com/Shibboleth.sso/SAML/POST" index="5"/>

    <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:1.0:profiles:artifact-01" Location="https://st.website.com/Shibboleth.sso/SAML/Artifact" index="6"/>
   </md:SPSSODescriptor>
 When I connect to wt.website.com/Shibboleth.sso/Metadata I get the metadata file with the same entries.
     <md:ArtifactResolutionService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://st.website.com/Shibboleth.sso/Artifact/SOAP" index="1"/>
    <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location="https://st.website.com/Shibboleth.sso/SLO/Artifact"/>

    <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://st.website.com/Shibboleth.sso/SLO/POST"/>

    <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://st.website.com/Shibboleth.sso/SLO/Redirect"/>

    <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://st.website.com/Shibboleth.sso/SLO/SOAP"/>

    <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://st.website.com/Shibboleth.sso/SAML2/POST" index="1"/>

    <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign" Location="https://st.website.com/Shibboleth.sso/SAML2/POST-SimpleSign" index="2"/>

    <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location="https://st.website.com/Shibboleth.sso/SAML2/Artifact" index="3"/>

    <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" Location="https://st.website.com/Shibboleth.sso/SAML2/ECP" index="4"/>

    <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post" Location="https://st.website.com/Shibboleth.sso/SAML/POST" index="5"/>

    <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:1.0:profiles:artifact-01" Location="https://st.website.com/Shibboleth.sso/SAML/Artifact" index="6"/>

 It appears that Shibboleth (or IIS) is not redirecting the request to the correct IDP.
 I have attached my Shibboleth2.xml file to get a fresh set of eyes on it.
 As before, we have a single IIS site (listed in IIS as site number "2" with IP (example 65.55.12.11) where st.website.com and wt.website.com both point to.
 Thank you
 -Julio
   --------------------------------
From: Julio Lopez <julz at outlook.com>
Sent: Wednesday, October 2, 2019 7:11 AM
To: Shib Users <users at shibboleth.net>
Subject: Re: Single Service Provider with Multiple IDP's
 Thank you Nate. 

I’ll upgrade to 3.0.4, get our main site work  and report back.
 -Julio
 On Oct 1, 2019, at 4:56 PM, Nate Klingenstein <ndk at signet.id> wrote:

Julio,

You'll first need to upgrade.  2.6 is really unsupported at this point and has a range of vulnerabilities.

Second, you need a mapping from the Site ID in IIS to the hostname in Shibboleth.  You have one for st, but not for wt.

            <Site id="1" name="st.website.com"/>

            <Site id="1518374912" name="wt.website.com"/>

Third, you'll need to explicitly protect that location using the RequestMap.

https://wiki.shibboleth.net/confluence/display/SP3/RequestMap

You might have done that but omitted it from your email.

You shouldn't hardcode one of the IdP names in your shibboleth2.xml file.  Instead, have no entityID attribute and pass it in on the query string:

https://wt.website.com/Shibboleth.sso/Login?entityID=https://wt.website.com/shibboleth

https://st.website.com/Shibboleth.sso/Login?entityID=https://st.website.com/shibboleth

It might work after those changes are made, but there's a good chance you'll hit another unexpected issue.  ApplicationOverrides are hard, especially on IIS.

Take care,

Nate.

--------

The Art of Access ®

Nate Klingenstein | Principal

https://www.signet.id/ 

-----Original message-----
From: Julio Lopez
Sent: Tuesday, October 1 2019, 4:47 pm
To: users at shibboleth.net
Subject: Single Service Provider with Multiple IDP's
 Hello everyone, first time post here and I hope it makes sense.
 We run Shibboleth SP 2.6.
 We have an application that runs on a windows iis webserver (7)
 The application is hosted on a single website in IIS but responds to multiple DNS names. All DNS names point to the same external IP
 https://st.website.com 
https://wt.website.com
   Shibboleth2.xml contains the follwing
     <InProcess logger="native.logger">
        <ISAPI normalizeRequest="true" safeHeaderNames="true">
            <Site id="1" name="st.website.com"/>
        </ISAPI>
     </InProcess>
https://st.website.com is configured (and working with Okta IDP) for Company A. Staff can login via SSO.
 https://wt.website.com is configured in the shibboleth2.xml (not working with Okta IDP) for Company B a completely separate IDP instance. 
 The following is what I have listed for both sites in the Shibboleth2.xml
 https://st.website.com/SSOLogin">
                        <Sessions lifetime="28800" timeout="3600" checkAddress="false" relayState="cookie" handlerSSL="false">
                          <SSO entityID="http://www.okta.com/UNIQUEIDforCorpA">
                                  SAML2 SAML1
                          </SSO>
                        </Sessions>
 <!-- If you can provide a URL to your metadata file, use the line below: -->
 <MetadataProvider type="XML" file="C:\opt\shibboleth-sp\etc\shibboleth\st.website.com-idpMetadata.xml" />
     <AttributeExtractor type="XML" validate="true" path="attribute-map-stwebsite.xml"/>
                        <CredentialResolver type="File" key="sp-signing-key.pem" certificate="sp-signing-cert.pem"/>
 </ApplicationOverride>
 <ApplicationOverride id="wt.website.com" entityID="https://wt.website.com/shibboleth" REMOTE_USER="eppn" homeURL="https://wt.website.com/SSOLogin">
                        <Sessions lifetime="28800" timeout="3600" checkAddress="false" relayState="cookie" handlerSSL="false">
                          <SSO entityID="http://www.okta.com/UNIQUEIDforCorpB">
                                  SAML2 SAML1
                          </SSO>
                        </Sessions>
 <!-- If you can provide a URL to your metadata file, use the line below: -->
 <MetadataProvider type="XML" file="C:\opt\shibboleth-sp\etc\shibboleth\wt.website.com-idpMetadata.xml" />
     <AttributeExtractor type="XML" validate="true" path="attribute-map-wtwebsite.xml"/>
                        <CredentialResolver type="File" key="sp-signing-key.pem" certificate="sp-signing-cert.pem"/>
 </ApplicationOverride>
 </ApplicationDefaults>
  When someone from Corp B goes to the wt.website.com/SSOLogin, they're redirected to Corp A's Okta instance and not to Corp B's Okta instance.
 I'm stuck and would appreciate some help as we will be bringing on more companies in the near future. 
 Thank you!
-Julio

-- 

For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg

To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net

 -- 
For Consortium Member technical support, see https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.shibboleth.net%2Fconfluence%2Fx%2FcoFAAg&data=02%7C01%7C%7Ca8aa1dc708ff4b0ff72d08d746cb00fe%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637055710024563534&sdata=HRS%2F7fPKVwWxd2xKNcMM9yMaDUZImd1hUuVWuI3qhdQ%3D&reserved=0
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net

-- 

For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg

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/20191009/1a687e0a/attachment.html>