There's often a knowledge gap in IT organizations when it comes to understanding how exactly SAML works. Many administrators and engineers are familiar with traditional network-based authentication protocols like RADIUS, LDAP, and SSH, but reliance on SAML will increase as organizations continue to transition to cloud-based vendors and services.

This post is intended to remove the mystery from SAML, explain the mechanics behind some of the most common SAML use cases.

• Simply put, Security Assertion Markup Language (better known as its acronym, SAML) is a protocol for authenticating to web applications. Federating identities is a common practice that amounts to having user identities stored across discrete applications and organizations. SAML allows these federated apps and organizations to communicate and trust one another's users.
• SAML provides a way to authenticate users to Third-party Web Apps (like ServiceNow, Office 365, MLearning, etc.) or internal web apps by redirecting the user's browser to a organization login page, then, after successful authentication on that login page, redirecting the user's browser back to that third-party web app (or internal web app) where they are granted access. The key to SAML is browser redirects!
• To combine analogies, if you think of single sign-on (SSO) as "one password to rule them all," think of SAML as the glue that binds them all together.
• SAML is most frequently the underlying protocol that makes web-based SSO possible. The organization maintains a single login page - behind it an identity store and various authentication rules - and can easily configure any web app that supports SAML, allowing users to log in to all web apps from the same login screen with a single password. It also has the security benefit of neither forcing users to maintain (and potentially reuse) passwords for every web app they need access to, nor exposing passwords to those web apps.

Behind the Scenes With SAML

Let's start by defining some terms:

Identity Provider (IdP) - An identity provider (IdP) is a service that stores and manages digital identities. Organizations use these services to allow their employees or users to connect with the resources they need. They provide a way to manage access, adding or removing privileges, while security remains tight. This part of authentication Infrastructure is supported and & maintained by the Michigan Medicine Identity and Access Management Team.

Service Provider (SP) - The web application where user is trying to gain access. This part of Infrastructure is maintained by Web Administrator.

SAML Assertion - A message asserting a user's identity and often other attributes, sent over HTTP via browser redirects.

IdP-Initiated vs SP-Initiated - IdP-initiated versus SP-initiated refers to where the authentication workflow starts. It's often asked about because some service providers support SP-initiated logins while others don't. What's unique about the SP-initiated login is a SAML request.

• An IdP-initiated login starts with the user first navigating to the IdP (typically a login page or dashboard), and then going to the SP with a SAML Assertion.
• An SP-initiated login starts with the user first navigating to the SP, getting redirected to the IdP with a SAML request, then redirected back to the SP with a SAML assertion.

Configuring SAML:

We've covered the basics of what SAML is, how log-in in with SAML works, and a few of the most common SAML scenarios. Now, let's talk configuration specifics:

• Configuration for SAML must be done in two places: at the IDP and at the SP.
• The IDP needs to be configured so it knows where and how to send users when they want to log in to a specific SP. The configuration in IDP is done by Michigan Medicine IAM Team.
• The SP needs to be configured so it knows it can trust SAML assertions signed by the IDP. The configuration in SP is done by respective Web Administrator. Web Service is NOT SAML Ready unless is configured for SAML by suitable SAML libraries.
• The IdP & SP needs to exchange metadata (XML Document) between each other.

Single-Sign On can be created with Michigan Medicine (Level-2) authentication by following the steps below. This configuration can be made for any Michigan Medicine department or unit that needs SAML/SSO for legitimate business needs. This type of connection will facilitate more efficient and centralized user authentication, improving security and making it easier for users to access your tools and data.

Troubleshooting SAML Based Applications

Advanced Resources:

Michigan Medicine Shibboleth 3.x SP Configuration Primer - SUSE Linux Enterprise Server 12.X and Apache
Michigan Medicine Shibboleth 3.x SP Configuration Primer - Windows Server 2016/2019 and IIS

Useful Links:

Beginner's Guide to SAML

A Developer's Guide to SAML

How to View a SAML Response in Your Browser for Troubleshooting

The Beer Drinker's Guide to SAML

Configure SAML/SSO Authentication for Your Service

Michigan Medicine staff can follow the steps below to make a web resource available as a Service Provider using SAML/SSO authentication. These steps are applicable for web based applications which are compliant with SAML 2.0.

1. Register your SP:

• Submit a ServiceNow Catalog Item request to the Information Assurance Identity and Access Management team with the following information:
  
  • State if this is a a web based (on-prem or off-prem) or thick client application.
    
    • If web based, does it support SAML 2.0?
    • Was application developed within U-M/MM or by a vendor (ServiceNow, Cornerstone Learning, Outlook Web Access, etc.)?
  • Describe if there will be a Pre-Production environment available.
    
    • If Pre-Production environment is not available, IAM team will work with you on a proof of concept (POC) within our SAML/SSO IDP Pre-Production environment.
  • Provide:
    
    • Metadata in XML file format or provide URL for us to access the metadata.
    • List of attributes needed from LDAP in SAML assertions.
    • Primary technical contact information (phone, email, etc.), including availability of that contact.
    • Authentication requirements:
      
      • MFA
      • MFA based on location (Inside vs Outside of Michigan Medicine Network)
      • Ability to Login in with both UMICH (Level-1) or Michigan Medicine (Level-2) accounts
      • Michigan Medicine (Level-2) only
  • After we receive the request, the IAM team will contact the Service Provider administrator making the request and provide IDP metadata and an IDP certificate. We will work with the Service Provider administrator to complete testing in Pre-Production, if available.
  • Depending on the complexity of your request, it may take 1-2 weeks (or more) to complete. Please submit your request as early as possible.

2. Configure your SP:

• The "SAML/SSO Service Provider Configuration Resources" section below provides the Metadata, web certificate, and Entity ID information for the Michigan Medicine IDP test and production environments.

SAML/SSO Service Provider Configuration Resources

The following are resources necessary for setting up HITS Service Provider for SAML/SSO login.

Entity ID for Identity Provider or IDP Metadata URL:

Production:

https://weblogin.med.umich.edu/nidp/saml2/metadata

Pre-Production:

https://p-weblogin.med.umich.edu/nidp/saml2/metadata

Audience URI, or Audience Restriction:

Production:

https://weblogin.med.umich.edu/nidp/saml2/metadata

Pre-Production:

https://p-weblogin.med.umich.edu/nidp/saml2/metadata

URL for SAML SSO (Single Sign-On):

Production:

https://weblogin.med.umich.edu/nidp/saml2/sso

Pre-Production:

https://p-weblogin.med.umich.edu/nidp/saml2/sso

URL for SAML SLO (Single Logout):

Production:

https://weblogin.med.umich.edu/nidp/saml2/slo

Pre-Production:

https://p-weblogin.med.umich.edu/nidp/saml2/slo

Michigan Medicine Pre-Approved Attributes for Release

The following attributes are pre-approved by Michigan Medicine for release. Michigan Medicine staff members do not need to submit a request for attribute release or perform any set-up work if required attributes are in the list below. These attributes are released by default to Service Providers, unless the Service Provider requests otherwise during configuration.

Pre-Approved Attributes for Release:

• First Name (GivenName)
• Last Name (SurName)
• Display Name
• Email (mail)
• Uniqname (cn)

Requesting Michigan Medicine Release of Additional Attributes

If your Service Provider requires release of attributes that are not on the pre-approved list (see above), submit a ServiceNow request to the Information Assurance Identity and Access Management team for review. 

Submit your request as soon as you know you will need release of additional attributes beyond those pre-approved. This will leave the Identity and Access Management team enough time to review and implement your request.

In general, an attribute will not be released unless there is a business reason for its release. If you request release of an attribute, please be sure that there is a real need for its release. Please note, requests must be made by Michigan Medicine HITS staff representing a Michigan Medicine department or unit.