Omnilert supports several options for subscribers to use Single Sign-On (SSO) to log into their accounts. This allows your local systems to control access for subscribers using the same usernames and passwords used for your local email/network logins.
The two most common Single Sign-On options supported are:
- Shibboleth / SAML: Omnilert can act as an Service Provider (SP), allowing your organization to be the Identity Proder (IdP) for Shibbolth logins. We can support inCommon Federation logins as well as non-federated logins (with metadata exchange).
In addition to inCommon Federated Shibboleth, Omnilert's Shibboleth/SAML connector can also be used to allow login through most standard SAML identity management systems, including Onelogin or Okta. Omnilert can also support SAML logins using Microsoft ADFS or Microsoft Azure AD as an identity provider.
- LDAP Login: Omnilert can also query your local LDAP server to "bind" and pass a username and password for authentication. If the LDAP username/password is accepted, the user may log into Omnilert. LDAP is typically used to integrate Omnilert with Active Directory.
Some notes about Single Sign-On:
- Single Sign-On is typically used for "opt-in" configurations, where subscribers must log in to create their accounts and add contact info.
- The key benefit of SSO solutions is that the subscriber does not need to remember a separate login for Omnilert. They use the same username/password they'd use for other resources provided through your network.
- Single Sign-On does not remove users. If a user is removed from your SSO system, they will no longer be able to access their Omnilert account, but the account is not removed. You will still need to purge "old" subscribers from the system periodically, as you see fit. (Your account manager can assist you with planning that removal process.)
- LDAP connections will require your local firewall to allow connections from Omnilert's servers. (Contact support for IP address information needed.)
- Single Sign-On is used for subscriber logins only. Administrators must log in directly with Omnilert. This is so that access to Omnilert is no prevented when/if local servers are offline. (If SSO were used for admin logins, a local server outage or power disruption could render your account inaccessible when it's needed most)