multi-tenant SP

[Yitzchak Scott-Thoennes]

Just upgraded from service provider 2.5.3 to 3.4.1 and thought I would post
how I'm doing multi-tenant, with specific locations using specific IdPs.

In my apache config (apache 2.4.52) I have:

<Location "/shibboleth/initiate">
    AuthType shibboleth
    Require shibboleth
    SetHandler modperl
    PerlResponseHandler ...
</Location>
<Location "/shibboleth/initiate/customer0">
    ShibRequireSessionWith "testshib"
    Require valid-user
</Location>
<Location "/shibboleth/initiate/customer1">
    ShibRequireSessionWith "customer1"
    Require valid-user
</Location>
plus additional locations.

In shibboleth2.xml I have the SSO element commented out, multiple
SessionInitators and the AssertionConsumerService tags (that the SSO tag
normally does for you), plus metadata:

            <SessionInitiator type="SAML2" Location="/Login"
isDefault="true" id="testshib"
                              entityID="https://samltest.id/saml/idp"

NameIDFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" />
            <SessionInitiator type="SAML2" Location="/Login"
isDefault="false" id="customer1"
                              entityID="https://sp.example.org/customer1" />
            ... more session initiators
            <md:AssertionConsumerService Location="/SAML2/POST" index="1"
                Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"/>
            <md:AssertionConsumerService Location="/SAML2/POST-SimpleSign"
index="2"

Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign"/>
            <md:AssertionConsumerService Location="/SAML2/Artifact"
index="3"

Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"/>
            <md:AssertionConsumerService Location="/SAML2/ECP" index="4"
                Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS"/>
            <md:AssertionConsumerService Location="/SAML/POST" index="5"

Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post"/>
            <md:AssertionConsumerService Location="/SAML/Artifact" index="6"
                Binding="urn:oasis:names:tc:SAML:1.0:profiles:artifact-01"/>
            ...
        </Sessions>
        ...
        <MetadataProvider type="XML" validate="true" url="
https://samltest.id/saml/idp"
             backingFilePath="SAMLtest.xml" reloadInterval="180000" />

        <!-- InCommon IdP metadata -->
        <MetadataProvider type="XML" url="
http://md.incommon.org/InCommon/InCommon-metadata-idp-only.xml"
             backingFilePath="InCommon-metadata-idp-only.xml"
reloadInterval="14400">
           <MetadataFilter type="RequireValidUntil"
maxValidityInterval="2419200"/>
           <!-- temporarily remove <MetadataFilter type="Signature"
certificate="inc-md-cert.pem"/>  -->
           <MetadataFilter type="EntityRole">
              <RetainedRole>md:IDPSSODescriptor</RetainedRole>
              <RetainedRole>md:AttributeAuthorityDescriptor</RetainedRole>
           </MetadataFilter>
        </MetadataProvider>

Note that the SessionInitiator id corresponds to the apache config.

The documentation does mention removing the SSO tag for complex cases; it
would be nice if it actually showed what all the SSO tag is doing for you.
The ACS tags I have instead I think I got from the shibboleth version
before the SSO tag.

I do see the error in the logs about using /Login multiple times; as far as
I know I don't actually need that endpoint, and the error doesn't seem to
cause any problem.

Added "xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" to the SPConfig at
the beginning, for the ACS tags to be recognized.

In addition to the above, the perl handler checks that the IdP used for a
location is actually the one expected (so establishing a shibboleth session
for one location doesn't authenticate a user for any of the locations,
since ShibRequireSessionWith only seems to affect people with no shibboleth
session), and if it is not, it redirects to /Shibboleth.sso/Logout?return=
+ the location being handled, to force a new correct session.   Otherwise,
the perl response handler creates our software's login session and
redirects out of the shibboleth directories.  (There are many other ways
customers can log in, SAML2 not through shibboleth, openidconnect,
email/pass, openid, facebook, other types of SSO, with different customers
having different auth methods enabled.)

Comments appreciated.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20230322/ed71feed/attachment.htm>