SSO

Critical Labs currently supports SSO via SAML2.0. Both identity provider (IdP) initiated and service provider (SP) initiated login are supported.

SSO can be setup by going to the Settings page from the top right menu and clicking on the SSO tab.

Our newest SSO features (specifically unique entityIDs and Permissions & Groups) are incompatible with our legacy SSO workflow. If you are interested in taking advantage of our newest features, please contact us to migrate. You will need to update some configurations in your IdP to complete the migration. Existing legacy SSO workflows will continue to work without issue.

The fastest way to setup SSO is to import your IdP's XML metadata into Critical Labs and to export Critical Labs SP XML metadata to your IdP. There are convenient buttons on the SSO settings page for you to do this.

On the Identity Provider tab, click on the "Import Metadata" and copy/paste the XML provided by your IdP into the provided field. Click "Import". This will auto-build the IdP settings and import/configure any certificates found in the XML.

To setup SP-initiated SSO from Critical Labs to your IdP, go to the Service Provider tab and click "Export Metadata". This will open a new browser tab with the XML that you can either download or copy/paste into your IdP's settings.

These settings are required to setup SSO with Critical Labs. This information will be provided to you from your IdP, often in the form of XML metadata which can be imported directly or via manual input.

• SAML 2.0 HTTP Endpoint: The endpoint that Critical Labs should use to authenticate SSO requests. This will be an endpoint provided by your IdP.
• Session Timeout: How much time will pass before a user is automatically logged out of Critical Labs. (It is recommended to choose an option here because not all IdPs provide control over this setting)
• Certificates: A list of certificates (up to 5) from your IdP that Critical Labs will use to authenticate SSO requests. Only one certificate can be active at a time. At least one valid, active certificate is required to enable SSO.

The following settings can be setup within your IdP to allow for service provider initiated login (eg. login from the Critical Labs website or from a Critical Labs-generated alarm email). These settings are optional, but they are recommended for allowing you to take advantage of the full Critical Labs SSO feature set.

• EntityID: The unique entityID that Critical Labs will provide to your IdP when attempting a service provider initiated login.
• Login (Request) URL: The URL that will initiate SSO login from the Critical Labs website.
• Consumer (Response) URL: The URL that your IdP will use to communicate to Critical Labs when it receives a login request. Sometimes also called "Reply URL" or "Assertion Consumer Service URL".
• Single Logout URL: The URL that will initiate a logout from the Critical Labs website. Can be accessed directly from your browser or optionally be provided to your IdP.
• Relay State: This is intentionally left blank, as Critical Labs may use this to facilitate certain login parameters.
• SAML nameID Format: Currently Critical Labs only supports email for a user identifier.

The list of certificates in the SP section are Critical Labs-generated signing certificates that will be used to sign assertions. At least one valid, active certificate is required to support SP-initiated login.

As an additional security feature, Critical Labs provides the ability to encrypt assertions. At least one valid, active certificate is required to support encryption.

Permissions and groups are a way to use groups and/or permissions that are setup in your IdP to translate to Critical Labs permissions. Here you can setup the group type, the group ID, and the permissions you want to assign to this group. Critical Labs supports three different types of SAML claims/attributes:

• Azure Group: use the Object ID of the Azure group (example: 12345678-90ab-cdef-1234-567890abcdef) as the Group ID
• Azure Role: use the Value of the Azure role (example: readonly) as the Role Value. This is the value that is assigned to the role before it is assigned to a group in your Azure application.
• Generic Group: Setup an attribute/claim named 'groups' in your IdP and assign it a value that makes sense to your organization. Whatever value you use, it must match the Group/Role ID that you provide to Critical Labs.

Critical Labs can support multiple claims for Permissions & Groups and will combine permissions to the highest provided level in the assertion. However, each Group ID/Role Value that is assigned in Critical Labs MUST be unique.

Critical Labs requires that each permission/group assignment has a unique (and recommended human-readable) name for easier group management.

With the new (non-legacy) workflow, permissions will be completely managed by Permissions & Groups. You will not be able to update SSO user permissions from the Users page. Permissions displayed in the Users page will be the permissions the user had the last time they signed in via SSO. If there are no group permissions setup for a user then that user will have read-only permission.

Once SAML has been setup, it's a good idea to test login. If you are using IdP initiated login only, then you will need to login to your IdP and access Critical Labs from the link in your IdP.

If you are using SP initiated login, then you can go to the login link provided by Critical Labs (the Login/Request URL) and attempt to login.