<div dir="ltr"><div>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.<br></div><div><br></div><div>In my apache config (apache 2.4.52) I have:</div><div><br></div><div><Location "/shibboleth/initiate"><br> AuthType shibboleth<br> Require shibboleth<br> SetHandler modperl<br> PerlResponseHandler ...<br></Location></div><div><Location "/shibboleth/initiate/customer0"><br> ShibRequireSessionWith "testshib"<br> Require valid-user<br></Location><br><Location "/shibboleth/initiate/customer1"><br> ShibRequireSessionWith "customer1"<br> Require valid-user<br></Location></div><div>plus additional locations.</div><div><br></div><div>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:<br></div><div><br></div><div> <SessionInitiator type="SAML2" Location="/Login" isDefault="true" id="testshib"<br> entityID="<a href="https://samltest.id/saml/idp" target="_blank">https://samltest.id/saml/idp</a>"<br> NameIDFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" /><br> <SessionInitiator type="SAML2" Location="/Login" isDefault="false" id="customer1"<br> entityID="<a href="https://sp.example.org/customer1" target="_blank">https://sp.example.org/customer1</a>" /></div><div> ... more session initiators<br></div><div> <md:AssertionConsumerService Location="/SAML2/POST" index="1"<br> Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"/><br> <md:AssertionConsumerService Location="/SAML2/POST-SimpleSign" index="2"<br> Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign"/><br> <md:AssertionConsumerService Location="/SAML2/Artifact" index="3"<br> Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"/><br> <md:AssertionConsumerService Location="/SAML2/ECP" index="4"<br> Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS"/><br> <md:AssertionConsumerService Location="/SAML/POST" index="5"<br> Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post"/><br> <md:AssertionConsumerService Location="/SAML/Artifact" index="6"<br> Binding="urn:oasis:names:tc:SAML:1.0:profiles:artifact-01"/></div><div> ...</div><div> </Sessions></div><div> ...<br></div><div> <MetadataProvider type="XML" validate="true" url="<a href="https://samltest.id/saml/idp" target="_blank">https://samltest.id/saml/idp</a>"<br> backingFilePath="SAMLtest.xml" reloadInterval="180000" /><br><br> <!-- InCommon IdP metadata --><br> <MetadataProvider type="XML" url="<a href="http://md.incommon.org/InCommon/InCommon-metadata-idp-only.xml" target="_blank">http://md.incommon.org/InCommon/InCommon-metadata-idp-only.xml</a>"<br> backingFilePath="InCommon-metadata-idp-only.xml" reloadInterval="14400"><br> <MetadataFilter type="RequireValidUntil" maxValidityInterval="2419200"/><br> <!-- temporarily remove <MetadataFilter type="Signature" certificate="inc-md-cert.pem"/> --><br> <MetadataFilter type="EntityRole"><br> <RetainedRole>md:IDPSSODescriptor</RetainedRole><br> <RetainedRole>md:AttributeAuthorityDescriptor</RetainedRole><br> </MetadataFilter><br> </MetadataProvider></div><div><br></div><div>Note that the SessionInitiator id corresponds to the apache config.</div><div><br></div><div>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.</div><div><br></div><div>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.<br></div><div><br></div><div>Added "xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" to the SPConfig at the beginning, for the ACS tags to be recognized.</div><div><br></div><div>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.)<br></div><div><br></div><div>Comments appreciated.</div></div>