Single Sign-On: Admin logins via Shibboleth/SAML

Omnilert can support admin logins via Shibboleth/SAML. This will allow your administrators to access Omnilert using the username/password managed by your local identity provider (inCommon, ADFS/Azure, OneLogin, Okta, etc.)

This feature is an extension of the standard Shibboleth/SAML connection used for subscriber logins. (See Single Sign-On: Shibboleth / SAML Settings)

Special SAML attribute release: 'mail'

In order for an admin to log in via Shibboleth/SAML, your identity provider must include an extra attribute ('mail') which must match the admin's email address in Omnilert. 

If the SAML user logging in has a match on the username (eppn or omnilertUserame) and email address (mail or omnilertMail), that session will log into the corresponding admin account rather than the Subscriber Portal.

Different IdP systems may have their own way of releasing this special attribute. We've outlined the three most common IdP setups below.

Shibboleth SAML federation standard ‘mail’ attribute: 'mail'

This is for inCommon Federated Shibboleth using either mace or oid formatted attributes. 

<Attribute name="urn:mace:dir:attribute-def:mail" id="mail"/>
<Attribute name="urn:oid:0.9.2342.19200300.100.1.3" id="mail"/>

Microsoft Azure (ADFS) as Self-hosted AD services ‘mail’ attribute: ‘AD-omnilertMail’

This is the common attribute used in Azure and ADFS. You can set the "claim" to release whichever field will match the email address.  Release the "email address" field as a claim with the name set as "AD-omnilertMail"  and id set as "omnilertMail" as shown below.

<Attribute name="AD-omnilertMail" id="omnilertMail" />

Please note that the names are case-sensitive for SAML setups. 

Other SAML/ shibboleth systems' ‘mail’ attribute: 'omnilertMail'

Other systems, such as OneLogin, Okta, or Ping Federate may not include "mail" as a standard attribute. In such cases, you'll need to release a special attribute to Omnilert for admin logins.

For these systems, you can release the email address as "omnilertMail" and use the "basic" SAML format. 

In this case, you'd set up a basic attribute as follows:

<Attribute name="omnilertMail" 
nameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" id="omnilertMail" />

Please note that the names are case-sensitive for SAML setups. 

Enabling Admin Single Sign-On in Omnilert settings

To enable admins to log in via Single Sign-On (SSO), go to Settings > Single Sign-On > Shibboleth/SAML and check the box marked "Enable admin SSO access".

If this box is unchecked, all SAML logins will be processed as subscribers, regardless of which attributes are sent by the IdP. 

Once enabled, an admin can log into Omnilert via SSO if the following conditions are true:

• An Omnilert admin exists with an exact matching username to the 'eppn' (or 'omnilertUsername') attribute
• The Omnilert admin has an exact matching email address to the 'mail' attribute
• The admin is not locked or "inactive" in Omnilert

If a SAML session does not match an existing admin, then that browser is sent to the Subscriber Portal (as you would expect for subscribers logging in via SSO.)

Allow Admin SSO Only

If checked, this box will force any/all admins assigned to roles other than Super Admin (or Account Admin) to use SSO.

Note: Admins assigned to Custom Admin Roles will also be forced to use SAML Single Sign-On to log in if this option is enabled.

Using Admin SSO

Once configured, there are two key pieces that must match: 

• The admin username in Omnilert must match the username sent by your SSO IdP
• The admin email address in Omnilert must match the email address sent by your SSO IdP 

If these do not match or the email address is missing, then Omnilert will not permit the admin to log in. So, you may need to edit your Omnilert admins to set the correct username and email address to match your local systems. 

Once that's set, you're ready to use admin Single Sign-On!

Logging in:

To log in via SSO, your admins can click the Log in via Single Sign-On button at the admin login prompt to log in using your single sign-on system.

Then they will be taken to your SSO login portal for authentication before proceeding into Omnilert. If the browser has already been logged in, they will be redirected straight into the Omnilert admin portal.

Notes/Tips

• Enabling admin SSO does not remove the standard admin login form on Omnilert. This form will remain available with a separate button to log in via Single Sign-On as shown above. 
  
  
• Admin SSO cannot create new admin logins. All admins must exist in Omnilert with a matching username and email address to log in via SSO.  (See "Adding an admin")
  
  
• If Omnilert finds a matching admin username AND admin email address in the SAML assertion, it will log that browser into the Omnilert admin portal as the corresponding admin.  
  
  
• If an Omnilert admin's username and email do NOT match what is sent by the SAML IdP, they will not be able to log in as an admin via SSO.  (You may need to edit existing admin usernames to match the SAML username for SSO to function properly.)
   
• The standard (non-SAML) admin login form will still be available for emergency use when/if the SAML login system is unavailable. 
  
  
• We strongly recommend keeping at least 1 full-access Omnilert "Super Admin" (and/or your "Account Admin") admin login username/password secured for situations where your local SSO system may be offline or unreachable. 
  
  
• Mobile web access to your admin portal will work with SSO on most mobile devices. However, Admin SSO is not supported on the Scenarios App for iOS/Android. (Admins must use their Omnilert username/password to log into the Scenarios App.)