Verkada Command has the ability to integrate with Azure AD (amongst other IdPs) in two capacities dependent on the use case:

  • SAML (Security Assertion Markup Language)

  • SCIM (System for Cross-Domain Identity Management)

SAML handles the authentication side of things allowing Azure AD to be used to manage access to Verkada Command, the same as any other SaaS application already integrates into your Azure AD tenant. This means Verkada Command can be incorporated into your existing identity framework and users can be authorized based on your current policies in place.

SCIM on the other hand allows you to leverage your existing users and groups already present in Azure AD and synchronize these with Verkada Command. This allows you to retain the current central identity provider, and configure permissions in Command using your existing users and groups.


SAML Integration

Verkada Command is registered as a gallery application and can be found within the Azure AD marketplace, meaning it can be leveraged with Azure AD Free, Azure AD P1, and Azure AD P2 licenses.

Client ID

To get started you will need your client ID. Follow this guide to generate it, and configure your email domains, then return to this article to complete the rest of this process.

The first step is to add Verkada Command as an enterprise application in your Azure AD tenant. Head to your Azure AD overview page and select Enterprise Applications:

Select New Application at the top of the page, then, search for 'Verkada Command' under the gallery section.

Select Verkada Command from the search results and select Create. It will take a few moments to add the application to your Azure AD tenant.

Once the page refreshes, you should see a menu like below.

Under the Set up single sign-on section, click Get started

Next, choose SAML as the single sign-on method

Now, we'll configure some fields for our SAML connection. Start this by clicking the Edit link

We'll be filling in three fields as follows, substituting the <clientid> for your client ID generated from this article.

1. Identifier (Entity ID)

https://vauth.command.verkada.com/saml/sso/<clientid>

2. Reply URL (Assertion Consumer Service URL)

https://vauth.command.verkada.com/saml/sso/<clientid>

3. Sign on URL

https://vauth.command.verkada.com/saml/login/<clientid>

In our example, our client ID is bug-lab as seen below:

Click the save button at the top, then continue with the rest of the steps.

Box 2 will already be populated with the correct user attributes and claims and should match the screenshot below. If so, no changes are needed for this section.

Box 3 contains the Federation Metadata XML file we will need to import into Verkada Command. Click the Download button to use this a little bit later.

Box 4 and Box 5 contain tools we can use after the integration has been finalized.

Uploading your Federation Metadata in Verkada Command

After completing the steps in Azure and downloading the metadata proceed to upload the XML metadata file. This process will be done in Verkada Command.

Testing the SAML Connection in Azure AD

Once the file is uploaded, you can go ahead and test the integration with the button in Box 5 back inside Azure AD.

If everything is set up correctly, you should be taken straight through to the Command platform if you select Sign in as current user when running the test.

Access to Verkada Command can then be achieved through the following URL - https://vauth.command.verkada.com/saml/login/<clientid> substituting the client ID with the one used during setup. This will redirect you to the IdP (Azure AD) to complete the login process.

Note: Azure does not support nested groups for app access at this time. All users will need to be direct members of groups for assignment.

Login through the Mobile Application when leveraging SAML Integration

Verkada Command on both Android and iOS supports login through SAML. Within the email address field, enter the email of the user in question and hit next. At this point, you will be redirected to your IDP (Azure AD) to complete the login process.



Setting up SCIM

Before you start configuring SCIM in Azure AD, we will need to grab your Secret Token from Verkada Command.

To generate the token inside Verkada Command, go to Admin > Privacy & Security > SCIM Configuration

and add the email domain. This will generate the token which is only viewable once. To generate a new token you will need to refresh it.

Next, choose Add Domain, then type all relevant email domains you will utilize with SCIM, then copy your token for use later. If you did not copy your token and it is not visible, click Refresh to generate a new token.

Next, we'll work from Azure AD.

From the home page, select Enterprise applications > + New application > + Create your own application.

Select the non-gallery application, name the application, then select the Create button.

Under the Provision User Accounts section, click Get started.

Next, click Get Started

On the provisioning page, set the Provisioning Mode to “Automatic

Set the tenant URL as follows: https://api.command.verkada.com/scim

Use your Secret Token generated earlier to fill in the related field.

Next, click the Test Connection button to confirm that the SCIM connection is successful.

Select the Save button to continue.

Provision Azure Active Directory Groups - Attribute Mapping

Please note, the mapping section will not appear until the Save button is clicked from the step above.

In this next section, we will configure the attributes for groups and users.

Start by opening the Mappings drop-down, then select Provision Azure Active Directory Groups

There are some changes we need to make the default mappings suggested by Azure AD. Custom mappings will have to be added to match the below screenshots for the customappsso column.

If you need to add a mapping, select Add New Mapping > select the Source attribute to match the Azure Active Directory Attribute in the column below > set the Target attribute to match the customappsso Attribute in the column below > select Ok.

The data in the image above as provided in a table:

Azure Active Directory Attribute

(source attribute)

customappsso Attribute

(Target attribute)

displayName

displayName

objectId

externalId

members

members

Select the Save button and confirm your changes if any were made.

Then, select Provisioning in the breadcrumb link at the top of the page to return back to the Provisioning page.

Provision Azure Active Directory Users

Next, select on Provision Azure Active Directory Users to make changes to the user mappings.

Configure your mappings to match the screenshot provided or the data table below.

Note: The Switch attribute will be added as an Expression Mapping Type.

The data in the image above as provided in a table:

Azure AD Attribute

customappsso Attribute

Matching precendence

userPrincipalName

userName

1

givenName

name.givenName

surname

name.familyName

Switch([IsSoftDeleted], , "False", "True", "True", "False")

active

jobTitle

title

employeeId

employeeNumber

department

department

companyName

organization

Please note: if any of the customappsso attributes are not available as a Target Attribute, you may need to add them to your Azure AD platform as an option by clicking the Show advanced options checkbox, then Edit attribute list for customappsso

In our situation, we needed to add employeeNumber, department, and organization. Click the Save button to save these new attributes. We do not recommend editing existing attributes.

Select the Save button. Confirm your changes. Then, select Provisioning in the breadcrumb link at the top of the page to return back to the Provisioning page.

Once finished with the mappings, select the Provisioning Status slider to on.

Adjust the scope to the required options, either Sync all users and groups or Sync only assigned users and groups depending on the requirements. If selecting the second option, ensure users and groups are assigned to the enterprise application under the Users and Groups section. Those that are assigned will be the ones provisioned and become present in Verkada Command.

Make sure the provisioning is set to On, and eventually once the initial provisioning cycle has elapsed you should see the total number of users and groups that have been provisioned successfully.

On Verkada Command you should be able to see these users and groups populated with the Externally Managed tag associated.

These synchronized users and groups can now be used in Verkada Command and assigned to permissions to control access to the command platform. 

Further information on permissions in the Verkada Command can be found in the following articles:

https://help.verkada.com/en/articles/4148648-user-permissions-overview
https://help.verkada.com/en/articles/3085073-a-simplified-camera-user-permissions-model
https://help.verkada.com/en/articles/3495051-setting-permissions


Visit Training Center for bite-sized video tutorials on how to accomplish role-based tasks in Command.

Did this answer your question?