Omnilert provides single sign-on via SAML as a Service Provider (SP) for subscribers accessing the Subscriber Portal.
What happens when a new subscriber username logs in via SAML?
When a subscriber logs into Omnilert via SAML, the Identity Provider (IdP) sends their browser to Omnilert with a valid SAML session including attributes:
the username, usually in the format of an "eppn" (e.g. email@example.com ),
and last name.
Omnilert then checks the username against the current subscriber list, looking for a match:
If that SAML username exists already in Omnilert: Omnilert will just log the subscriber into that matching subscriber's portal. The subscriber just passes through because they're logged in and known.
- 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 a one-time thing since their next visit will find a match, of course.
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 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