Single Sign-On: Shibboleth / SAML Settings

Shibboleth provides a true "Single Sign-On" (SSO) experience for end-users (subscribers). The primary benefit of any single sign-on solution is that users need only log into your systems once and that login information is passed to other resources, such as Omnilert. 

Shibboleth is a form of SSO that is based on SAML.

Omnilert can act as a Service Provider (SP) for Shibboleth/SAML login to the Subscriber portal.*

Your institution (or a third party) must perform the role of the Identity Provider (IdP), who verifies login credentials for subscribers who are logging in.

Note: To configure Shibboleth Single Sign-on with Omnilert, you will need to be a member of the InCommon Federation. Otherwise, you will need to contact Omnilert support to make separate arrangements to exchange metadata with Omnilert.

Shibboleth Settings

The key setting for Shibboleth will be your Identity Provider Entity ID. This is the URN/URL for your IdP. There are two supported formats:

• Identity Providers Entity ID examples:
  • urn:mace:incommon:myschool.edu
  • https://www.myschool.edu/idp/shibboleth

Once saved, Omnilert will display a Shibboleth page link. Simply share that link anywhere you'd like subscribers to log in. When a subscriber clicks that link, they'll be taken into Omnilert's subscriber portal via your Shibboleth/SAML login pages (if they aren't already logged in, of course!)

The Logout redirect URL determines where subscribers are sent if/when they click "logout" to exit the Subscriber portal. This is typically set to your own Single Sign-On portal's logout page to end their SAML session with your site and truly log out the user.

Note: The Check attributes link is a handy utility used to troubleshoot SAML setups. Use that link to test logins and see which SAML attributes are being released to Omnilert.

Shibboleth/SAML access only

This setting restricts all subscriber logins to your Shibboleth Login Link. Only engage this setting if you wish to block all other access for subscribers. If enabled, all subscriber portal visitors will be redirected to the SAML login process.

Tip:  Only engage "Shibboleth/SAML access only" once you've set up and tested your login process as it cuts off subscriber portal access for anyone without a valid SAML login. As such, this should be the very last step in any transition to single sign-on logins.

External Identity Management Systems

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.

Provisioning Subscribers via SAML

When a subscriber logs in via SAML, Omnilert 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. 

So, new subscriber provisioning happens "on-demand" when a new subscriber username logs in for the first time via SAML. (See Shibboleth / SAML Subscriber Provisioning)

*Admin access via Shibboleth is not supported. Admins must log into the admin portal using an Omnilert username/password. This restriction is in place to ensure that your admins can still access the service in the vent of a power/network outage at your location.