McMaster University hosts a non-cloud (on-premises) authentication service for SSO based on Shibboleth technology. The shibboleth IDP server only supports SAML and it remains a valid option when applications cannot support Azure AD integrations for specific reasons such as the need to obtain additional authorization metadata depending on the requirements of the application. For example, some applications may need to obtain the value of a specific user affiliation or the user’s academic information. During the integration process, applications must indicate as precisely as possible which attributes would be required for authorization purposes.

McMaster University is a member of 2 education federations through the Shibboleth authentication service:

1. InCommon Federation which manages federated authentication services between higher education institutions and their sponsored partners throughout North America. As a member, McMaster faculty, staff, and students are able to access resources using their local MacID account. All participants in this federation use a common set of policies and practices to exchange information about their users and resources in order to share access and enable collaboration between participants. The underlying technology used to support federated authentication between participants in the InCommon Federation is the Shibboleth System.
2. Canadian Access Federation (CAF) is another mayor federation McMaster University belongs to via membership to CANARIE. Participation in CAF enhances the user experience of researchers, students and faculty by allowing a MacID account to seamlessly access trusted content, services, and applications any time, from any place. Membership to CANARIE also includes access to EDUROAM, which allows for seamless Wi-Fi access through eduroam at over 17,000 locations in 100 countries worldwide.

How To Register Your Application With The Shibboleth IDP

To register a SAML based application with the Shibboleth IDP (Test or Prod), owners must provide the Metadata URI (or an XML  file containing the metadata details) and the Redirect URI of the application. The metadata should also contain the signing public key and the logout URI. When the application gets registered, owners will be given the details of the registration and the specific Shibboleth IDP information for the application.

McMaster University hosts two Shibboleth IDP servers as follows:

Production
EntityID: https://sso.mcmaster.ca/
Metadata: https://sso.mcmaster.ca/shibboleth-idp/shibboleth
SSL certificate: idp.crt

Test/Development
EntityID: https://tsso.mcmaster.ca/
Metadata: https://tsso.mcmaster.ca/shibboleth-idp/shibboleth
SSL certificate: idp-t.crt

Identity Provider Information for InCommon Service Providers:
InCommon SPs must use urn:mace:incommon:mcmaster.ca for McMaster University’s IdP entityID.
All other InCommon metadata should be downloaded directly from InCommon.

Deploying The Service Provider (SP)

In order to connect to the Shiboleth IDP server, an application must rely on a Service Provider layer of software that can handle SAML.  The SP software consists of several components:

ISAPI Filter – This is only used for IIS deployments. It intercepts requests to IIS and redirects users to an IdP or WAYF. After the user authenticates it also handles the callback which tells your SP that the user has authenticated. During handling of this callback the ISAPI Filter collects attributes which describe the authenticated user. The filter is configured through the shibboleth2.xml config file.
Apache Module – This is only used for Apache deployments. It is essentially the same as the ISAPI Filter but for the Apache web server. In addition to shibboleth2.xml, some configuration is required via httpd.conf.
Shibd – This is a service or daemon ((Windows and Linux) that handles queries from the SP to the IdP. Shibboleth requests are part of the SAML standard and are made via a back channel SOAP call to the IdP (usually on port 8443). In order for these queries to work, this service must be running.
Attribute Acceptance Policy (AAP) – This policy dictates which attributes the SP wants and which IdPs are authorized to provide them. It may also define specific formats that the values must match. In addition, the AAP determines what HTTP headers will be used for mapping attributes that are supplied by the IdP. There are two files that work together to enable this functionality: the attribute-map.xml and attribute-policy.xml.

For an in-depth explanation of how to deploy and configure your SP refer Understanding and Configuring SAML -> Deploying SAML On The SP Side.

Enabling Shibboleth Logout

If a partner application connected to Shibboleth wants to destroy the login session, a call to the following URL should suffice:

https://sso.mcmaster.ca/idp/profile/SAML2/Redirect/SLO

The above action will ensure that the Shibboleth session in the user’s browser is closed so long as the logout action is successful and the SP is configured correctly. The logout process accomplishes this by removing the Shibboleth session cookie in the browser and then redirects the traffic to the logout URL specified in the above call. Other application sessions might be affected by this but it does not guarantee a global SSO logout.

Shibboleth Attributes/Claims

In some cases SAML based applications do require extra information about the user during the login process. To assist with this, a set of default and extended set of attributes is available for release to qualified Service Providers.

Default Attribute Set

Oasis Claim Name	EduPerson Name	Possible # Records	Notes
urn:oid:0.9.2342.19200300.100.1.1	“uid”	one record only	This is the person’s Mac ID | jdoe
urn:oid:2.5.4.42	“givenName”	one record only	given name as specified in the Mosaic user record | first name, ex: john
urn:oid:2.5.4.4	“sn”	one record only	surname as specified in the Mosaic user record | surname/last name, ex: doe

Extended Attribute Set

These claims can be can be selectively released depending on what is required for the authorization component of the integration.

Oasis Claim Name	EduPerson Name	Possible # Records	Notes
urn:oid:2.16.840.1.113730.3.1.241 Understanding and Configuring Oauth2/OIDC	“displayName”	one record only	The displayName attribute from on-premises AD | Prof. John Doe
urn:oid:0.9.2342.19200300.100.1.3	“mail”	one record only	Contact email address as specified in the Mosaic user record | john_doe@mcmaster.ca
urn:oid:2.5.4.3	“cn”	one record only	Just a concatenation of “GivenName” and “sn”
urn:oid:2.16.840.1.113730.3.1.3	“employeeNumber”	one record only	employee number as specified in the Mosaic user record | 999999999
urn:oid:13.6.1.4.1.5923.1.1.1.6	“eduPersonPrincipalName”	one record only	Authenticated principals receive the value “MacID@mcmaster.ca”. MacID is the value of “cn” (common name) in AD | jdoe@mcmaster.ca
urn:oid:1.3.6.1.4.1.5923.1.1.1.9	“eduPersonScopedAffiliation”	one record only	affiliation@mcmaster.ca
urn:oid:1.3.6.1.4.1.22306.1.1.29	“job”	more than one record could be present	Authenticated principals that are employees receive some details of their employee record (see a sample here)
urn:oid:1.3.6.1.4.1.5923.1.1.1.1	“eduPersonAffiliation”	more than one record could be present	Authenticated principals receive the value “affiliate”. Principals that have the “job” attribute receive also the value “staff”. Principals that have the “course” attribute and whose term is current, receive the value “student” | some principals could have more than one status
urn:oid:1.3.6.1.4.1.22306.1.1.32	“career”	more than one record could be present	Authenticated principals receive details of their academic roll such as enrolment year, full/part time, residence status | multiple academic rolls could be presented
urn:oid:1.3.6.1.4.1.22306.1.1.30	“program”	more than one record could be present	Authenticated principals receive details of their academic term, enrolled program, program description, term, level, academic group | multiple academic rolls could be presented

Notes:

InCommon and CAF SPs are given the default attribute set but not the extended set.
Application owners can request the release of the above attributes to their SPs via a UTS request. If you need any specific attributes, please file a data owner approval request clearly stating your entityID and the desired attributes.
The default attribute set automatically applies to new SPs during the SAML integration, unless they specify a need for extended attributes.

Test Login Accounts

To assist application owners during tests, non-person login accounts are available. Each test account represents a typical campus affiliation (or combination of).

shibtst1 – Alumni and CCE Student and Employee active/permanent – contains degree conferred,program records and job records.

shibtst2 – Alumni and CCE Student – contains program records and degree conferred

shibtst3 – Staff active/permanent – contains multiple job records.

shibtst4 – Student Registered/not enrolled – no program records

shibtst5 – Contracted employee  (contains employeeclassdescription)

shibtst6 – POI Academic/faculty (contains employeeclass/classdescription)

shibtst7 – Retired (faculty) – No job records present

shibtst8 – Alumni – contains degreeConferred

shibtst9 – discontinued student – program/courses records exist

shbtst10 – regular undergrad student (social sciences/psychology)

shbtst11 – medical student (health sciences)