NetID Login Integration Overview

A collection of information and documents in reference to integrating a service provider with one of our Shibboleth IdPs

NetID Login Service - Getting Started
NetID Login and Wisconsin Federation Attribute Information
Shibboleth SP Configuration File (shibboleth2.xml)
Configuring Logout
1. No Support for Single Logout
2. Logout of Individual Applications
Enable Shibboleth Authentication for a Specific Path
1. Linux
2. Windows
Secure Cookies
Server Variables and Mapped Attributes
Advanced Configuration Settings
Integrating your application with Manifest
Authorizing End Users with Manifest Groups
OIDC NetID Integration

NetID Login Service - Getting Started

Extensive documentation for installing and configuring Shibboleth SP can be found here: https://kb.wisc.edu/iam/internal/86317

NetID Login and Wisconsin Federation Attribute Information

Information regarding common attribute questions and processes for both NetID Login (UW Madison) and Wisconsin Federatrion.

What is an SP, IdP and Attribute?

Service Provider (SP) - An SP is a web service that provides services/resources to a user that has been authorized to use it
Identity Provider (IdP) - An IdP acts as a data source for user information and acts as an authenticator to validate users before they can access the SP
SAML Attribute - An Attribute is a means for delivering information to the Service Provider about the authenticated user after logging into the application/resource

Getting the attribute-map.xml

It's recommended that your application pull in attribute-map.xml url to ensure that any updates that are made to it will be passed to your application by configuring the AttributeExtractor element in your shibboleth2.xml configuration file. The attribute-map will decode SAML attributes for your application, for more information: Shibboleth documentation on AttributeExtractor.

NetID Login attribute-map.xml (UW Madison): https://login.wisc.edu/metadata/attribute-map.xml
Wisconsin Federation attribute-map.xml: https://wayf.wisconsin.edu/metadata/attribute-map.xml

Default Attribute Release for NetID Login Service

The default attribute release consists of the attributes that are released to the Service Provider without any form of data request

uid
- User's NetID
ePPN (eduPersonPrincipalName)
- Appears as a scoped username
- The identifier is the person's login name or userID (uid) followed by a namespace.
- The domain that comes after the @ sign defines a namespace (scope) which provides a uniqueness for the identifier
  - Example: bbadger@wisc.edu
wiscEduPVI
- Another unique identifier attribute
wiscEduPrivacyFlag
- This attribute indicates if the person's educational data is protected by the FERPA Policy
eduPersonTargetedID
- A unique ID that identifies a person while preserving their privacy
- This value is unique per Service Provider

Default Attribute Release for Wisconsin Federation

Minimal Attribute Bundle
- Name Identifier: SAML2 Transient NameID
- User Attribute: eduPersonScopedAffiliation
Additional bundles found at InCommon - Default Attribute Release.

Requesting Additional SAML Attributes

If a service provider requires attributes beyond what is provided by default please make a note of what your application will need when completing the IAM intake request form.

Shibboleth SP Configuration File (shibboleth2.xml)

Configuring Logout

No Single Logout

Single Logout in the context of the UW NetID Login Service would be the action of clicking a Logout link or button that would cause the user to be logged out of all NetID Login-protected applications at once. Currently, Single Logout is not possible in the UW NetID Login Service. There are many reasons for this, and if you're interested in details this document provides a good overview.

The only complete NetID logout is closing the browser and clearing all session cookies, which is the end user's responsibility. End users can review instructions on clearing cookies and making sure their browser is safely configured here: NetID Login Service - Logout Procedure.
Logout of individual applications

Application developers can use the central NetID logout page (https://login.wisc.edu/logout) as a way of requiring users to sign back in with their NetID in order to:
- Return to the most recently used NetID-protected web application or
- Access any NetID-protected resources not previously visited during that browsing session
When the user clicks a link to the NetID logout page, their session on the login server will be cleared. However, the central logout page will not log the user out of other NetID-protected resources they've already signed into during the current browsing session (e.g. other tabs in the same browser). Those resources will remain available without the need to sign in again until the user closes the browser and clears the session cookies.

In Shibboleth, redirection to the central logout page can be done by using the Logout property of the Shibboleth handler to perform a Local Logout and attaching a return value that redirects the user to the UW NetID Login Service logout page.

Here's a sample logout link for the application example.dept.wisc.edu:
```
<a href="https://example.dept.wisc.edu/Shibboleth.sso/Logout?return=https://login.wisc.edu/logout">Logout</a>
```

Enable Shibboleth Protection for a Specific Path

Linux

Once the installation of the Shibboleth 2 SP is complete, you can require Shibboleth authentication for accessing any directory in your site/application by adding Apache directives in the .conf file or .htaccess.

A note about security: It's very important to limit cookie use to encrypted requests. SSL should be required for any URL using Shibboleth authentication. To ensure that SSL is always used, you want to redirect protected paths to SSL using native Apache functionality (i.e. redirects or rewrite rules).

httpd.conf

It's best to identify the directory by its physical path. You need to require a Shibboleth session and set Require valid-user, which will make the directory available to anyone successfully logging in with a UW NetID.

Example:
```
<Directory "/var/www/yoursite.wisc.edu/html/shib">
AuthType shibboleth
ShibRequestSetting requireSession 1
Require valid-user
</Directory>
```
There are a number of variations on these settings. For example, you can use the AuthGroupFile and Require Group attributes to limit access to the directory to specific NetIDs only. As usual with settings in the httpd.conf file, an Apache restart is required for the changes to take effect.

.htaccess

You can also configure Shibboleth protection for a directory using an .htaccess file. This method is especially helpful for web developers who do not have access to the httpd.conf file or in cases where an Apache restart is not practical.

The syntax is almost the same as in the httpd.conf example, except that the directory information is not necessary:
```
AuthType shibboleth
ShibRequestSetting requireSession 1
Require valid-user
```
The directives will apply to the directory where the .htaccess file is located and to its subdirectories.
The full range of configuration options for Apache can be found here on the Shibboleth wiki.
Windows

To require Shibboleth authentication for specific directories, you need to edit the RequestMapper section of the shibboleth2.xml. List each directory you want to protect as a Path within the application's Host element in the RequestMapper.

Shibboleth will put together the hostname followed by the paths you define, and use this information to determine which URLs to protect. These are not physical paths, but URLs, so use forward slashes to separate subdirectories. More details here on hostnames and paths.

In the example below, a new subdirectory new_path has been added for sp.example.org and the entire newsite.wisc.edu is protected by adding authType="shibboleth" requireSession="true" to the Host element.
```
<RequestMapper type="Native"> 
<RequestMap applicationId="default"> 

<Host name="sp.example.org"> 
<Path name="secure" authType="shibboleth" requireSession="true" redirectToSSL="443"/> 
<Path name="new_path" authType="shibboleth" requireSession="true" redirectToSSL="443"/> 

</Host> 

<Host name="newsite.wisc.edu" authType="shibboleth" requireSession="true" redirectToSSL="443"/> 

</RequestMap> 
</RequestMapper>
```
The redirectToSSL="443" attribute is important, because it forces the request for the protected path to SSL, preventing user information from being sent over the internet unencrypted.

The RequestMapper is a reloadable resource, so the settings will be updated every time you save the shibboleth2.xml.

Secure Cookies

For Shibboleth to provide secure authentication, users must be required to communicate with the application server and the login server over an encrypted connection, so that user-specific data is not passed over the internet in plain text. There are just a couple steps to requiring an encrypted connection for all Shibboleth traffic:

Force SSL on all Paths

Any path you define as requiring Shibboleth authentication should be accessible only over SSL.

On a Windows server, you can accomplish this by adding the redirectToSSL="443" attribute to all Path elements in the RequestMap of your shibboleth2.xml (NetID Login Service - Requiring Shibboleth Authentication). If you're using a port other than 443 for SSL, use that value instead. (Note that to configure Shibboleth to use a non-standard SSL port, the port number and scheme "https" must be specified in the Host element.)

In Apache, you can force SSL in a variety of ways using native functionality.
Use cookieprops

You can use the cookieprops attribute in the Sessions element of your shibboleth2.xml to limit cookie use to requests made over SSL. To do this, you add cookieProps="; path=/; secure; HttpOnly" to your Sessions element and set handlerSSL="true".

Example Sessions element using cookieprops:
```
<Sessions lifetime="28800" timeout="3600" checkAddress="false" handlerURL="/Shibboleth.sso" handlerSSL="true"
cookieProps="; path=/; secure; HttpOnly" exportLocation="localhost/Shibboleth.sso/GetAssertion" exportACL="127.0.0.1"
idpHistory="false" idpHistoryDays="7">
```

Server Variables and Mapped Attributes

Once you've set up Shibboleth authentication for your web application, you can easily check which mapped Shibboleth attributes your application is receiving and the full list of server variables available to your application.

Attributes
Once you've authenticated into your web application and established a Shibboleth session, you can use the Shibboleth handler's Session property to get a summary of the values for the Session. If your application were example.wisc.edu, you would access the Session info like this: https://example.wisc.edu/Shibboleth.sso/Session. By default, this will display the number of values the session has for each attribute, but it will not show the actual value of the attribute. To show the value of each attribute, configure the Session handler in Shibboleth2.xml such that showAttributeValues is true, as follows:
```
<Handler type="Session" Location="/Session" showAttributeValues="true"/>
```
HTTP Header Size Limit

In some cases the size of an HTTP request header sent to a webserver from the service provider may exceed its default size limit. HTTP header size is affected by things such as the amount of SAML attributes sent by your Shibboleth SP or client browsers sending their own headers. This can result in an HTTP 400 error when users try to access your site if the number of request headers exceeds your web server's limit. With the ever-growing size of HTTP headers it is recommended to increase the limits of what is acceptable, some further information can be found below:

Apache: The default HTTP header size is 8kb. To increase the limit, adjust the parameter LimitRequestFieldSize for the virtual host or other location in the Apache configuration. https://httpd.apache.org/docs/2.4/mod/core.html#limitrequestfieldsize

IIS: Set MaxFieldLength and MaxRequestBytes registry entries so that the user's request headers don't exceed these values: https://learn.microsoft.com/en-US/troubleshoot/developer/webapps/iis/www-administration-management/http-bad-request-response-kerberos

Server Variables

To see the full list of server variables available to your application, place a dynamic page inside one of your application's directories that requires Shibboleth authentication and then access the page.

If you have PHP installed on your server you can use the following:

<html>
<head>
<title>Server Variables</title>
</head>
<body>

<?PHP

foreach($_SERVER as $key_name => $key_value) {
print $key_name . " = " . $key_value . "<br>";
}

?>
</body>
</html>

For Windows, you can use an ASP page containing the following:

<html>

<head>
<title>Shibboleth Attributes - <%= Request.ServerVariables("SERVER_NAME") %></title>
  <META HTTP-EQUIV="Pragma" CONTENT="no-cache">
  <META HTTP-EQUIV="Expires" CONTENT="-1">
<script language"JavaScript" type="text/JavaScript">
<!--
  function decodeAttributeResponse() {
 	var textarea = document.getElementById("attributeResponseArea");
  	var base64str = textarea.value;
	var decodedMessage = decode64(base64str);
	textarea.value = tidyXml(decodedMessage);
	textarea.rows = 15;
	document.getElementById("decodeButtonBlock").style.display='none';
  }

  function tidyXml(xmlMessage) {
	//put newline before closing tags of values inside xml blocks
	xmlMessage = xmlMessage.replace(/([^>])</g,"$1\n<");
	//put newline after every tag
	xmlMessage = xmlMessage.replace(/>/g,">\n");
	var xmlMessageArray = xmlMessage.split("\n");
	xmlMessage="";
	var nestedLevel=0;
	for (var n=0; n < xmlMessageArray.length; n++) {
		if ( xmlMessageArray[n].search(/<\//) > -1 ) {
			nestedLevel--;
		}
		for (i=0; i<nestedLevel; i++) {
			xmlMessage+="  ";
		}
		xmlMessage+=xmlMessageArray[n]+"\n";
		if ( xmlMessageArray[n].search(/\/>/) > -1 ) {
			//level status the same
		}
		else if ( ( xmlMessageArray[n].search(/<\//) < 0 ) && (xmlMessageArray[n].search(/</) > -1) ) {
			//only increment if this was a tag, not if it is a value
			nestedLevel++;
		}
	}
  	return xmlMessage;
  }

  var base64Key = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/=";
  function decode64(encodedString) {
    var decodedMessage = "";
    var char1, char2, char3;
    var enc1, enc2, enc3, enc4;
    var i = 0;

    //remove all characters that are not A-Z, a-z, 0-9, +, /, or =
    encodedString = encodedString.replace(/[^A-Za-z0-9\+\/\=]/g, "");
    do {
	enc1 = base64Key.indexOf(encodedString.charAt(i++));
	enc2 = base64Key.indexOf(encodedString.charAt(i++));
	enc3 = base64Key.indexOf(encodedString.charAt(i++));
	enc4 = base64Key.indexOf(encodedString.charAt(i++));

	char1 = (enc1 << 2) | (enc2 >> 4);
	char2 = ((enc2 & 15) << 4) | (enc3 >> 2);
	char3 = ((enc3 & 3) << 6) | enc4;

	decodedMessage = decodedMessage + String.fromCharCode(char1);
	if (enc3 != 64) {
		decodedMessage = decodedMessage + String.fromCharCode(char2);
	}
	if (enc4 != 64) {
		decodedMessage = decodedMessage + String.fromCharCode(char3);
	}
    } while (i < encodedString.length);
    return decodedMessage;
  }
// -->

</script>
</head>


<body>

<b>-all SHIB headers-</b> (<code>HTTP_SHIB_ATTRIBUTES</code> is not shown in this list)

<table>
<% For Each strKey In Request.ServerVariables %>
<% if InStr(1, strKey, "SHIB", 1) and not strKey="HTTP_SHIB_ATTRIBUTES"  then %>
<tr>
<td><%= strKey %></td>
<td><%= Request.ServerVariables(strKey) %></td>
</tr>

<% end if %>
<% Next %>
<tr><td>(REMOTE_USER)</td><td><%= Request.ServerVariables("REMOTE_USER") %></td></tr>
<tr><td>(HTTP_REMOTE_USER)</td><td><%= Request.ServerVariables("HTTP_REMOTE_USER") %></td></tr>

</table>
<br/>

attribute response from the IdP (<code>HTTP_SHIB_ATTRIBUTES</code>):<br/>
<textarea id="attributeResponseArea" onclick="select()" rows="1" cols="130"><%= Request.ServerVariables("HTTP_SHIB_ATTRIBUTES") %></textarea><br/>

<span id="decodeButtonBlock"><input type="button" id="decodeButton" value="decode base64 encoded attribute response using JavaScript" onClick="decodeAttributeResponse();"><br/></span>

<br/>

<small>
notes:<br/>
The AAP throws away invalid values (eg an unscopedAffiliation of value "myBoss@&lt;yourdomain&gt;" or a value with an invalid scope which scope is checked)<br/>

The raw attribute response (<code>HTTP_SHIB_ATTRIBUTES</code>) is NOT filtered by the AAP and should therefore be disabled for most applications (<code>exportAssertion=false</code>).<br/>
</small>


<br/>

<hr/>
<br/>


<table>
<% For Each strKey In Request.ServerVariables %>
<tr>
<td><%= strKey %></td>
<td><%= Request.ServerVariables(strKey) %></td>

</tr>
<% Next %>
</table>

</body>
</html>

For Linux/Apache, you can place the following Shell script in your cgi-bin directory:

#!/bin/sh
echo Content-type: text/html
echo ""
/bin/cat <<EOM
<HTML>
<BODY text="#000000">
<PRE>
EOM

/bin/env
CAT <<EOM
</PRE>
</BODY>
</HTML>
EOM

If you have Perl installed, you can use the following:

#!/usr/bin/perl

print "Content-type: text/html\n\n";
print "<pre>\n";

foreach $key (sort keys(%ENV)) {
    print "$key = $ENV{$key}<p>";
}

print "</pre>\n";

Advanced Configuration Settings

The following are advanced configuration options for Shibboleth SP when integrating with NetID Login or Wisconsin Federation IdPs.

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

<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.

Integrating the Service Provider with Manifest

Note: This service is not available for Wisconsin Federation service providers.

This document outlines the different ways that application administrators can connect with their Manifest groups, through the NetID Login Service. This document is intended for system administrators and assumes that a functional Shibboleth Service Provider has been configured. For details on how to configure a Shibboleth Service Provider, see NETID LOGIN SERVICE - GETTING STARTED.

After a user authenticates with their NetID and password, Manifest can deliver group information through a Shibboleth attribute called "isMemberOf". Only groups that have been configured with your application's SAML2 Entity ID will be delivered. In this way, we ensure that your groups are only available for your applications to consume.

Locate Your Application's SAML2 EntityID

The SAML2 Entity ID is the unique identifier for your service provider which is located in the shibboleth2.xml configiuration file on your application's host. Common locations are found below:

Windows:

C:\opt\shibboleth-sp\etc\shibboleth\shibboleth2.xml

Linux:

/etc/shibboleth/shibboleth2.xml

Once you have located the shibboleth2.xml file, open it in your preferred editor and find the entityID attribute in the <ApplicationDefaults> tag. If you have specified an <ApplicationOverride> tag in your XML file, use the value located there instead.

Examples:

<ApplicationDefaults [...] id="myapp.wisc.edu" entityID="https://myapp.wisc.edu/shibboleth">

<ApplicationOverride [...] id="myapp.wisc.edu" entityID="https://myapp.wisc.edu/shibboleth">

Now that you have located your SAML2 Entity ID, copy it into your Manifest group(s) using the instructions outlined in Manifest - Manage SAML2 EntityIDs. Note that Entity IDs are case sensitive.

Configure Shibboleth for the "isMemberOf" Attribute

In order for your application to use the "isMemberOf" attribute, it must be part of your Shibboleth Service Provider's attribute map. If you have not configured your Service Provider to pull attributes from login.wisc.edu/metadata/attribute-map.xml, you must edit your attribute-map.xml file manually. This file should be located in the same folder as shibboleth2.xml. The following should be added to attribute-map.xml:

<Attribute name="urn:mace:dir:attribute-def:isMemberOf" id="isMemberOf"/>
<Attribute name="urn:oid:1.3.6.1.4.1.5923.1.5.1.1" id="isMemberOf"/>

Authorization Using Manifest Groups (IIS)

Shibboleth2.xml Directives

Once you have configured Manifest and your Shibboleth Service Provider, you will be ready to utilize the "isMemberOf" attribute for authorization decisions. A typical means of doing this is via the <RequestMapper> tag in your shibboleth2.xml file. A basic example is provided below; if you would like additional assistance with authorization decisions, please contact manifest@doit.wisc.edu.

<RequestMapper type="Native">
   <RequestMap applicationId="default">
      <Host name="myapp.wisc.edu" applicationId="myapp.wisc.edu" authType="shibboleth" requireSession="true" redirectToSSL="443">
         <Path name="private" requireSession="true">
            <AccessControl>
               <Rule require="isMemberOf">uw:domain:myapp.wisc.edu:private_users</Rule>
            </AccessControl>
         </Path>
      </Host>
   </RequestMap>
</RequestMapper>

The example above restricts access to myapp.wisc.edu/private to members of the group uw:domain:myapp.wisc.edu:private_users (note that this is the Manifest Group ID Path).

Configuration File Directives

Alternate Apache 2.2 and below Configuration

Apache users can take advantage of the "require" directive to enforce group restrictions. This can be done in the Apache configuration. An example Apache config is provided below.

<Location "/myApp">
	AuthType shibboleth
	ShibRequestSetting requireSession 1
	ShibUseHeaders On
	ShibRequestSetting applicationID "myhost.wisc.edu/myApp"
	Require isMemberOf uw:domain:dept:myapp:mygroup
</Location>

Apache 2.4 Configuration

For Apache 2.4 and above the syntax to restrict access to a Manifest group changes: see below. This can be done in the Apache configuration. An example Apache config is provided below.

<Location "/myApp">
	AuthType shibboleth
	ShibRequestSetting requireSession 1
	ShibUseHeaders On
	ShibRequestSetting applicationID "myhost.wisc.edu/myApp"
	Require shib-attr isMemberOf uw:domain:dept:myapp:mygroup
</Location>

.htaccess Directives

.htaccess files provide a way to make configuration changes on a per-directory basis. A file, containing one or more configuration directives, is placed in a particular directory, and the directives apply to that directory, and all subdirectories thereof. Because of this, the <Location> directive is not used. An example is provided below

Apache 2.2 and below Directives


AuthType shibboleth
ShibRequestSetting requireSession 1
ShibUseHeaders On
ShibRequestSetting applicationID "myhost.wisc.edu/myApp"
require isMemberOf uw:domain:dept:myapp:mygroup

Apache 2.4 Directives


AuthType shibboleth
ShibRequestSetting requireSession 1
ShibUseHeaders On
ShibRequestSetting applicationID "myhost.wisc.edu/myApp"
require shib-attr isMemberOf uw:domain:dept:myapp:mygroup

NetID Integration with OIDC

For users wanting use NetID Login with OIDC:

UW Madison: Point your service to the NetID Login OIDC URL: https://login.wisc.edu/.well-known/openid-configuration

Universities of Wisconsin (Formerly UW System): Point your service to the UWProxy Login OIDC URL: https://idp.iam.wisconsin.edu/.well-known/openid-configuration

Alternatively the client might auto-configure if you tell it the issuer is: https://login.wisc.edu OR https://idp.iam.wisconsin.edu for UW System integrations.

For all OIDC integrations, the IAM team will need you to provide the following details:

A client_id that is descriptive and unique, in most cases the URL is sufficient as long as it won't be used for something else in the future (in which case there may be a conflict).
A redirect_uri or in some cases multiple if there's more than 1 hostname and one each for SSL and non-SSL sites.
token_endpoint_auth_method options, if unsure let us know:
- basic
- post
Once we have this information and it is configured on our end we will reach out with a client_secret

OIDC Scopes and Attributes

There are a number of scopes available to customers each with a set of one or more attributes, let us know if your application will need any of these attributes and we will include the proper scope. Scopes (in bold) with their included attributes are listed below:

Madison OIDC Scopes and Attributes

profile
- displayName
- givenName
- surname
email
- mail
openid
- sub
- uid
- eduPersonPrincipalName
- wiscEduPVI

Universities of Wisconsin (UW Proxy IdP) OIDC Scopes and Attributes

profile
- displayName
- givenName
- surname
email
- mail
openid
- sub
- eduPersonPrincipalName
- eduPersonAssurance
- eduWisconsinSPVI

Keywords	netid login saml shibboleth attributes cookies sso oidc integration Suggest keywords	Doc ID	130404
Owner	Justin V.	Group	Identity and Access Management
Created	2023-08-16 18:31:25	Updated	2024-03-11 14:24:55
Sites	Identity and Access Management
Feedback	0 0 Comment Suggest a new document

NetID Login Integration Overview

NetID Login Integration Overview

NetID Login Service - Getting Started

NetID Login and Wisconsin Federation Attribute Information

What is an SP, IdP and Attribute?

Getting the attribute-map.xml

Default Attribute Release for NetID Login Service

Default Attribute Release for Wisconsin Federation

Requesting Additional SAML Attributes

Shibboleth SP Configuration File (shibboleth2.xml)

Configuring Logout

No Single Logout

Logout of individual applications

Enable Shibboleth Protection for a Specific Path

httpd.conf

.htaccess

Secure Cookies

Force SSL on all Paths

Use cookieprops

Server Variables and Mapped Attributes

If you have PHP installed on your server you can use the following:

For Windows, you can use an ASP page containing the following:

For Linux/Apache, you can place the following Shell script in your cgi-bin directory:

If you have Perl installed, you can use the following:

Advanced Configuration Settings

Clustering Applications

Multiple Applications

Forcing Reauthentication

Domain Name Alias Configuration

Unprotect Location Under a Protected Location

Lazy Sessions

Integrating the Service Provider with Manifest

Locate Your Application's SAML2 EntityID

Configure Shibboleth for the "isMemberOf" Attribute

Authorization Using Manifest Groups (IIS)

Shibboleth2.xml Directives

Configuration File Directives

Alternate Apache 2.2 and below Configuration

Apache 2.4 Configuration

.htaccess Directives

Apache 2.2 and below Directives

Apache 2.4 Directives

NetID Integration with OIDC

Madison OIDC Scopes and Attributes

Universities of Wisconsin (UW Proxy IdP) OIDC Scopes and Attributes