Single Sign-On: Shibboleth / SAML Settings

Shibboleth/SAML 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 SAML.)

Omnilert can act as a Service Provider (SP) for Shibboleth/SAML login to the Subscriber Portal and Admin 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 test/troubleshoot SAML setups. Use this special link to test logins and see which SAML attributes are being released to Omnilert properly from your IdP.

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" after you've configured and tested your SSO login process as this setting disables subscriber portal access for anyone without a valid SAML login. This  should be the very last step in any transition to single sign-on logins.

Hide SSO button

By default, Omnilert will display a "Log in via Single Sign-On" button on the Omnilert "Subscriber Portal" login page.

Hiding this SSO login button can be helpful during the testing phase of SSO implementation. 

If this box is checked, your SSO logins will still function, but the button will be hidden. End-users must use the "Shibboleth Page Link" URL to log into Omnilert via SSO.

Admin SSO (Optional)

Typically, the single sign-on logins are used by subscribers only, with admins logging in directly to Omnilert. However, Omnilert can allow admins to log in via SAML SSO.

Enabling this feature requires the release of an additional SAML attribute ('mail').  

Please see the following article for details:

Single Sign-On: Admin logins via Shibboleth/SAML

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 (Entra) 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 is a one-time task as their next SSO login will find a matching username in Omnilert, of course. 

See Shibboleth / SAML Subscriber Provisioning for more details on the provisioning process for new subscribers via SAML.

*Admin access via Shibboleth is now available. See this article for more information about admin logins via SAML.