Shibboleth / SAML Subscriber Provisioning – Omnilert

Omnilert provides single sign-on via SAML as a Service Provider (SP) for subscribers accessing the Subscriber Portal.

Your identity management system (ADFS, Azure, Okta, OneLogin, etc.) acts as the Identity Provider (IdP). So, subscribers will log into Omnilert by logging into the IdP.

What happens when a new subscriber username logs in via SAML?

When a subscriber logs into Omnilert via SAML, the following steps occur:

Step 1: A web browser comes to your Omnilert SAML login URL

Omnilert checks if that browser's session has a valid SAML session from your SAML Identity Provider (IdP):

If YES, proceed to Step 2.
If NO, the web browser is directed to your Identity Provider (IdP) to log in via your IdP's login process. After logging in successfully, the IdP then redirects the browser back to Step 1, but with a valid SAML session this time.

Step 2: Omnilert checks the SAML attributes sent by the IdP

The Identity Provider (IdP) sends the browser to Omnilert with a valid SAML session including three critical attributes:

the username, usually in the format of an "eppn" (e.g. user@sample.edu ),
first name,
and last name.

Omnilert then checks the username value against the current subscriber list, looking for a matching subscriber:

If that SAML username exists already in Omnilert: Omnilert will log the subscriber into that matching subscriber's portal. The subscriber passes through because they're logged in and known to Omnilert. (SSO is complete.)
If that SAML username does not exist already in Omnilert: Omnilert will ask that subscriber to create a new Omnilert subscriber profile, then log the subscriber into that new profile to add phones, emails, etc. This is a one-time process since their next login will find a matching username, of course.

Thus, new subscriber provisioning happens "on-demand" only if a new subscriber username logs in for the first time via SAML.

Special Case: Auto-updating for scoped 'eppn' to usernames

In some cases, the Identity Provider may be set up to use a 'scoped' username ('eppn'). A scoped username will look like an email address. (e.g. 'jdoe@domain.com').

In such cases, Omnilert will attempt to find a perfect match for the username by stripping off the domain name (e.g. '@domain.com') and searching for the remaining username (e.g. 'jdoe') for a match.

If such a perfect match is found, the old username (e.g. 'jdoe') will be updated to match the SAML eppn (e.g. 'jdoe@domain.com').

This provides an automatic, on-demand changeover process for accounts that may be moving to Shibboleth/SAML from another login system.

Streamlining the Process for New Subscribers

Many organizations will simply pre-load the system via a CSV upload with their SAML subscribers to help streamline the process at launch. (See Subscriber Import)

As long as the username value matches the username passed via SAML login, the subscriber info will align.

This optional step helps make the process seamless for subscribers as their account will already exist if/when they eventually log into Omnilert via Shibboleth/SAML.

Tips and Notes

Single Sign-On via SAML will not automatically provision new subscribers. Rather, new subscribers will be added upon their first login via SAML.
Likewise, SAML doesn't remove subscribers. Of course, the subscriber must have access to your SSO system to log in to the Subscriber Portal. However, removing their login from SSO won't automatically delete their subscriber account from Omnilert's database.
SAML logins are for subscriber logins only. (Admins do not log in via SAML.)

More information: