NetID Login Service - Advanced Configuration Settings

This document gives examples of advanced Shibboleth SP configurations.

Overview

The NetID Login Service, which runs on Shibboleth, is UW-Madison's central Authentication and Authorization service. This document explains configuration settings for advanced application configurations.

Advanced Configuration Settings

CLUSTERING APPLICATIONS

To cluster an SP, you need to use the same private and public key pair on all servers, as well as the same entityId. However, there is session data stored in the shibd process, which is not automatically replicated to all the hosts. A load-balancer with sticky sessions can be used to keep users on the same cluster host for their entire session.

Shibboleth documentation: Clustering

MULTIPLE APPLICATIONS

Shibboleth allows you to define and run multiple applications on a single host using <ApplicationOverride> blocks.

Multiple Hostnames

If there are multiple applications running on a server with different hostnames, each application will need its own Application Override block with distinct EntityID and applicationId attributes.

<ApplicationOverride id="https://www.firstapplication.wisc.edu/shibboleth" entityID="https://www.firstapplication.wisc.edu/shibboleth">
    <Sessions lifetime="28800" timeout="1800" checkAddress="false" consistentAddress="false" relayState="ss:mem" handlerURL="/Shibboleth.sso" cookieProps="https">
        <SSO entityID="https://login.wisc.edu/idp/shibboleth">
            SAML2 SAML1
        </SSO>
    </Sessions>
</ApplicationOverride>
<ApplicationOverride id="https://www.secondapplication.wisc.edu/shibboleth" entityID="https://www.secondapplication.wisc.edu/shibboleth">
    <Sessions lifetime="28800" timeout="1800" checkAddress="false" consistentAddress="false" relayState="ss:mem" handlerURL="/Shibboleth.sso" cookieProps="https">
        <SSO entityID="https://login.wisc.edu/idp/shibboleth">
            SAML2 SAML1
        </SSO>
    </Sessions>
</ApplicationOverride>

These should be accompanied by their own Apache configurations to map them to the appropriate resources on the server.

<Location />
  AuthType shibboleth
  ShibRequestSetting applicationId https://www.firstapplication.wisc.edu/shibboleth
  ShibRequestSetting requireSession 1
  require shib-session
</Location>
<Location />
  AuthType shibboleth
  ShibRequestSetting applicationId https://www.secondapplication.wisc.edu/shibboleth
  ShibRequestSetting requireSession 1
  require shib-session
</Location>

In case of IIS this needs to be set up in the Request Mapper element of the shibboleth2.xml file

<RequestMapper type="Native">
    <RequestMap applicationId="default">
        <Host name="www.firstapplication.wisc.edu" applicationId="https://www.firstapplication.wisc.edu/shibboleth" authType="shibboleth" requireSession="true"/>
        <Host name="www.secondapplication.wisc.edu" applicationId="https://www.secondapplication.wisc.edu/shibboleth" authType="shibboleth" requireSession="true"/>
    </RequestMap>
</RequestMapper>

Multiple Paths

If there are multiple applications running on a server with different paths under the same hostname, each application will need its own Application Override block with distinct EntityID and applicationId attributes along with a modified handlerURL for Shibboleth handlers.

<ApplicationOverride id="https://www.application.wisc.edu/first/shibboleth" entityID="https://www.application.wisc.edu/first/shibboleth">
    <Sessions lifetime="28800" timeout="1800" checkAddress="false" consistentAddress="false" relayState="ss:mem" handlerURL="/first/Shibboleth.sso" cookieProps="https">
        <SSO entityID="https://login.wisc.edu/idp/shibboleth">
            SAML2 SAML1
        </SSO>
    </Sessions>
</ApplicationOverride>
<ApplicationOverride id="https://www.application.wisc.edu/second/shibboleth" entityID="https://www.application.wisc.edu/second/shibboleth">
    <Sessions lifetime="28800" timeout="1800" checkAddress="false" consistentAddress="false" relayState="ss:mem" handlerURL="/second/Shibboleth.sso" cookieProps="https">
        <SSO entityID="https://login.wisc.edu/idp/shibboleth">
            SAML2 SAML1
        </SSO>
    </Sessions>
</ApplicationOverride>

These should be accompanied by their own Apache configurations to map them to the appropriate resources on the server.

<Location /first>
  AuthType shibboleth
  ShibRequestSetting applicationId https://www.application.wisc.edu/first/shibboleth
  ShibRequestSetting requireSession 1
  require shib-session
</Location>
<Location /second>
  AuthType shibboleth
  ShibRequestSetting applicationId https://www.application.wisc.edu/second/shibboleth
  ShibRequestSetting requireSession 1
  require shib-session
</Location>

In case of IIS this needs to be set up in the Request Mapper element of the shibboleth2.xml file

<RequestMapper type="Native">
    <RequestMap applicationId="default">
        <Host name="www.application.wisc.edu">
            <Path name="first" applicationId="https://www.application.wisc.edu/first/shibboleth" authType="shibboleth" requireSession="true"/>
            <Path name="second" applicationId="https://www.application.wisc.edu/second/shibboleth" authType="shibboleth" requireSession="true"/>
        </Host>
    </RequestMap>
</RequestMapper>

Shibboleth documentation: ApplicationModel

Shibboleth documentation: RequestMapper

FORCING REAUTHENTICATION

You can require the user to reauthenticate at the IdP before getting an SP session by requesting forced reauthentication.

  • shibboleth2.xml - In the "SSO"" element, within the "Sessions" element, add the forceAuthn attribute and set it to "true".
  • Apache - Add ShibRequestSetting forceAuthn 1 in your httpd.conf or .htaccess file.
  • IIS - Add forceAuthn="true" in the "Host" element within "RequestMapper".

DOMAIN NAME ALIAS CONFIGURATION

If you have additional domain names pointing to an SP, that is integrated with the NetID Login Service, that can accept the SAML Authentication Response from the Shibboleth IDP, you will need to add the domain name as additional AssertionConsumerService endpoints in the SP Metadata

<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://originalhost.wisc.edu/Shibboleth.sso/SAML2/POST" index="1"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign" Location="https://originalhost.wisc.edu/Shibboleth.sso/SAML2/POST-SimpleSign" index="2"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location="https://originalhost.wisc.edu/Shibboleth.sso/SAML2/Artifact" index="3"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" Location="https://originalhost.wisc.edu/Shibboleth.sso/SAML2/ECP" index="4"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post" Location="https://originalhost.wisc.edu/Shibboleth.sso/SAML/POST" index="5"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:1.0:profiles:artifact-01" Location="https://originalhost.wisc.edu/Shibboleth.sso/SAML/Artifact" index="6"/>

<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://additionalhost.wisc.edu/Shibboleth.sso/SAML2/POST" index="1"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign" Location="https://additionalhost.wisc.edu/Shibboleth.sso/SAML2/POST-SimpleSign" index="2"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location="https://additionalhost.wisc.edu/Shibboleth.sso/SAML2/Artifact" index="3"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" Location="https://additionalhost.wisc.edu/Shibboleth.sso/SAML2/ECP" index="4"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post" Location="https://additionalhost.wisc.edu/Shibboleth.sso/SAML/POST" index="5"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:1.0:profiles:artifact-01" Location="https://additionalhost.wisc.edu/Shibboleth.sso/SAML/Artifact" index="6"/>
	

Once the Metadata has been updated please email help@login.wisc.edu with the Metadata attached and let us know the EntityID of the SP for which the Metadata to be updated.

Additionally we can also update the existing Metadata we have for your SP with the Alias you provide us

UNPROTECT LOCATION UNDER A PROTECTED LOCATION

Apache

Here's an example of setting up a Shibboleth-authentication required directory https://sample.wisc.edu/protected and a subdirectory https://sample.wisc.edu/protected/unprotected with no authentication required in the Apache .conf file:

<Directory "/var/www/sample.wisc.edu/htdocs/protected">
        AuthType shibboleth
        ShibRequestSetting requireSession 1
        Require shib-session
</Directory>
<Directory "/var/www/sample.wisc.edu/htdocs/protected/unprotected">
        AuthType shibboleth
        ShibRequestSetting requireSession 0
        Require shib-session
</Directory>
IIS

Here's an example of setting up a Shibboleth-authentication required directory https://sample.wisc.edu/protected and a subdirectory https://sample.wisc.edu/protected/unprotected with no authentication required in the shibboleth2.xml file:

<Host name="sample.wisc.edu">
   <Path name="protected" authType="shibboleth" requireSession="true" redirectToSSL="443" >  
      <Path name="unprotected" requireSession="false"/>
   </Path>
</Host>

LAZY SESSIONS

Apache
AuthType shibboleth
ShibRequestSetting requireSession 0
Require shibboleth
IIS

Set requireSession="false" in the <RequestMapper> section for that application.




Keywords:shibboleth2.xml shibboleth configuration config shib service provider sp   Doc ID:87575
Owner:Shreyash S.Group:Middleware
Created:2018-11-06 12:18 CSTUpdated:2018-12-06 15:05 CST
Sites:Access Management Services, Middleware
Feedback:  0   0