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. email@example.com ),
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.
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. 'firstname.lastname@example.org').
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. 'email@example.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
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.)
- Single Sign-On: Shibboleth / SAML Settings
- Single Sign-On: Configuring subscriber logins using a self-hosted Windows Server with ADFS
- Single Sign-On: Configuring subscriber logins using Microsoft Azure AD
- Single Sign-On: Configuring subscriber login using OneLogin
- Single Sign-On: Configuring Omnilert to work with Okta
Please sign in to leave a comment.