Entra ID (Azure AD) SAML (QUX)

SAML 2.0-based Single Sign-On to Vectra Detect UI

  • Customers can now setup SSO federation to a SAML 2.0-based identity provider

    • For release 6.2, Vectra has validated Azure AD, others are planned to follow

  • Once federated, already authenticated users will get automatically logged in when they load the Detect URL

  • Unauthenticated users will get redirected to their IdP’s login portal

  • Features like password policies and multi-factor authentication will be enforced by the IdP

  • Once authenticated, users are assigned the application role defined in the IdP

    • This will map to a role (and permissions) defined on the Vectra Brain

  • Local login is still supported via a different Detect URL constructed as follows

    • https://<ip or hostname>/accounts/login/?local=True

SAML SSO Support for Detect - Notes of Interest

  • Please ensure the users are only mapped to one Vectra Cognito Detect Role in the IdP

    • If a user is mapped to more than 1 role, the user may not be assigned the preferred role

    • This can cause HTTP 500 errors on the GUI when these users log in.

  • IdP initiated flows are NOT supported

    • While these flows may work, they are not recommended because they are highly susceptible to Man-in-the-Middle attack using stolen SAML assertions

  • Single Log Out (SLO) and IdP initiated log out are not supported

    • When a user logs out of the Detect UI, they are taken to a screen where they can log in locally or click a link to "Log in via SSO"

  • API keys are not supported for SAML users

    • For API use, Vectra recommends local accounts or other external authentication sources where the role tied to a user is managed inside of Cognito

  • GUIDs assigned to roles in the IdP Manifest need to be unique

  • The SessionNotOnOrAfter SAML parameter will be supported to invalidate user sessions and require a user to re-authenticate

SAML Service Provider (SP) Initiated Flow

SAML SSO Sample Role JSON for IdP

Please see the attachment to this article (at the bottom of this page) for a full block of JSON representing all default roles as of V6.2 that can be pasted into the IdP Manifest.

Release Demo for this Feature

circle-info

Please Note:

At the time this feature became available, Azure AD App Roles needed to be configured in the App Manifest. Microsoft has since added functionality to create and manage App Roles in their GUI. The steps below have been updated but the video remains as originally published. The manifest is still a valid method to use if you desire but the App Roles GUI is simpler for most admins to deal with.

Steps to enable SAML SSO for Detect with Azure AD

Configuring the Azure AD Application and Cognito Detect

  • Select “Enterprise applications” from AzureAD

  • Click the "+ New application" button

  • Click the "+ Create your own application" button (this is not a Gallery application)

  • Give it a name like "Cognito Detect SSO" or any name you desire

  • Use the "Integrate any other application you don't find in the gallery option"

  • Click "Create" at the bottom of the dialog

  • Select “Single sign-on" from left or "Set up single sign on" from the Getting Started section

  • Select “SAML” from the single sign-on method list

  • Next we'll need to create the Cognito Detect SAML Authentication Profile

  • Open a new browser tab and log in to Detect as you normally do and navigate to Manage > External Authentication

  • Click on “Create” in the SAML Profiles section

  • A dialog will open and the SP Entity Identifier, SP and ACS URL will be displayed there for entry into the corresponding fields in the AzureAD SAML SSO setup flow

  • Some customer situations require hostname based entries instead of IP based entries for the SP ACS URL and SP Entity Provider. Vectra supports both. Which type is populated here is controlled by a setting in Data Sources > Network > Brain Setup > Brain in the Cognito Platform (Brain) UI:

    • If you have a configured DNS name for the appliance and check the "DNS Name" radio button for the "For linking in alerts/notifications (except AWS SecurityHub)" section, this will populate the SP entries using hostname instead of IP as shown in below screenshot

    • Please also note that the "DNS Name" should be in lowercase in this area and any place you see it in Azure AD.

Settings.General.Brain
  • Next we will configure the Azure application with these values

  • Go back to your AZure tab in your broswer and edit the Basic SAML configuration in the newly created Azure application

  • Vectra's "SP Entity Provider" URI should be used for the Azure "Identifier (Entity ID)"

  • Vectra's "SP ACS URL" should be used for the Azure "Reply URL (Assertion Consumer Service URL)"

  • The rest of the Basic SAML Configuration can be left blank

  • Click the "Save" button at the top of the Basic SAML Configuration window

  • After this is saved, you can close the window. You will be asked if you want to test now. Select "No, I'll test later"

  • Next we will complete the External Authentication Profile in Detect

  • While still in your Azure tab, scroll down to section 3 "SAML Signing Certificate"

  • Download the "Federation Metatdata XML" file from Azure AD

  • Go back to the Detect tab in your browser

  • Click "Select a file" next to "Upload IDP Metadata XML File" in the "Create SAML Profile" window

  • Fill in the "Profile Name" with "Azure AD" or any name you desire

  • Click "Create"

Configure the Role Claim and Roles in Azure AD

  • We'll begin by creating the the "user.assignedroles" claim

  • In you Azure AD tab, select "Edit" in section 2 "User Attributes & Claims"

  • Select "Add a new claim"

  • Enter "https://schema.vectra.ai/role" in the "Name" section

  • For “Source attribute”, select “user.assignedroles”

  • Save the claim

  • Azure AD defaults to including a "user.userprincipalname" claim (which is required) but if you do not have this or are using a different IDP, please ensure that you also create this claim similarly to how to you created the "user.assignedroles" claim

    • This claim's name should be "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"

  • Next we will "App roles" in your newly created App

  • In the Azure AD Admin Center

  • Select "Azure Active Directory"

  • Select "App Registrations"

  • Select "All Applications"

  • Select your newly created application

  • Select "App roles" from the sidebar

  • Back in your Cognito Detect tab, navigate to the Manage > Roles screen

  • Click on each role that your SAML users will be using and make note of the specific Standardized Name for each role

    • For example, the Security Analyst role has a Standardized name of "security_analyst"

  • Back in the Azure AD App roles tab, add a new entry for each role in Cognito Detect

  • If you see default roles from Microsoft of "User" and "msiam_access" these can be ignored

  • Create new App roles using the "+ Create app role" button for each role that you will have users or groups assigned to in Vectra

  • Be sure to use the Standardized Name for the "value" field that you collected previously

  • The "Display name" and "Description" can be anything that you want to refer to inside the IdP for the Detect roles you will be assigning to your users

Assign Users and Groups to Roles in your Azure AD Application

  • In the Azure Active Directory pane, select Enterprise applications from the Azure Active Directory left-hand navigation menu

  • Select All applications to view a list of all your applications

  • Select your newly create Detect Application

  • Select the "Users and groups" from the sidebar or "Assign users and groups" from the panes

  • Select the "+ Add user" button

  • Add a user

  • Choose a role that you just added to the Manifest

  • The users and groups you have configured will show as below

Test your new SAML Single Sign-On Functionality

  • The Detect URL you have been previously using now works with SAML SSO

  • When a user access the URL and does not already have a valid authentication session open, they will be redirected to the IdP

  • Once through the authentication flow, or if the user was already authenticated previously and still has a valid SAML session, they will land directly on the Detect Security Dashboard

  • If the user logs out, or their session expires due to the inactivity timeout in Detect (defaults to 15 min but can be changed in Settings > General), they will be directed to the local login screen where they can login locally or "Log in via SSO"

Attachments

Last updated

Was this helpful?