Identity Providers (IdPs) like Okta and Azure Active Directory specialize in providing a robust identity framework for organisations, an increasingly important function as identity forms one of the core pillars of security.

Verkada Command is like any other SaaS application that is added to these IdPs, so any existing identity configurations can be leveraged.

There are certain items available as part of these providers to provide more robust control over the access to the Verkada Command application.

Foreword

Azure AD

Azure AD leverages a feature known as conditional access in order to configure various characteristics that dictate the users login behaviour. This allows items like location, sign-on risk, and device compliance to be leveraged to determine whether individuals can access configured SaaS applications or prompt for additional checks, for example, MFA. 

Further information on conditional access - https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/overview

Okta

Okta leverages sign-on policies in order to control access to applications. This allows items like location, device type, and device compliance to be leveraged to determine whether individuals can access configured SaaS applications or prompt for additional checks, for example, MFA.

Further information on sign-on policies - https://help.okta.com/en/prod/Content/Topics/Security/App_Based_Signon.htm

Restricting Access Based on IP Address

Example Use Case - Restricting access to Verkada Command from certain office locations.

Azure AD

Location-based conditions within Azure AD can be used in order to restrict the physical location that individuals can access Verkada Command, for example, preventing access from particular countries, or only allowing access when within the office.

This is done based on IP addressing and the locations associated with the IP address, whether they appear in a configured list of named location and whether those locations are trusted.

Further information on location conditions can be found here - https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/location-condition

Okta

Location-based conditions can be used in order to restrict the physical location that individuals can access Verkada Command, for example, preventing access from particular countries, or only allowing access when within the office.

Okta makes use of the concept of network zones in order to allow access to be allowed or denied dependent on which of these zones a user falls into when they access Verkada Command.

Further information on network zones can be found here - https://help.okta.com/en/prod/Content/Topics/Security/Security_Network.htm

Restricting Access Based on Device

Example Use Case - Restricting access to Verkada Command to corporate laptops/desktops only.

Azure AD

Azure AD alongside Intune can be leveraged for corporate device management and compliance. The conditions can be utilised to determine whether access to Verkada Command is allowed dependent on device information, for example, a device needs to be marked as compliant which is dependent on it being a corporate device, has up-to-date antivirus, and other device-specific characteristics, or simply blocking access from iOS devices.

Further information on device conditions can be found here - 

https://docs.microsoft.com/en-us/mem/intune/protect/create-conditional-access-intune

Okta

Okta can leverage device characteristics in order to control access, either through the devices operating system, or alternatively through “Device Trust” which leverages various device management and MDM (mobile device management) solutions.

Further information on device conditions can be found here -

https://help.okta.com/en/prod/Content/Topics/device-trust/device-trust-landing.htm

 

Enforcing Robust Password Requirements

Example Use Case - Requiring passwords to be changed every 3-months.

Azure AD

Further information on Azure AD’s password policies can be found here - https://docs.microsoft.com/en-us/azure/active-directory/authentication/

Okta

Further information on Okta’s password policies can be found here - https://help.okta.com/en/prod/Content/Topics/Security/healthinsight/strong-passwords.htm

Enforcing Session Timeouts

Example Use Case - Being able to control the amount of time that can elapse before reauthentication is required in Verkada Command

Azure AD

Azure AD provides the ability to control the session lifetime, along with session persistency (whether you need to login every time the browser is opened).

This is achieved through conditional access policies, specifically session policies.

Further information these policies can be found here - https://docs.microsoft.com/en-gb/azure/active-directory/conditional-access/howto-conditional-access-session-lifetime

Okta

Okta provides the ability to control the time that elapses before a reauthentication prompt occurs. This is configured through a sign-on policy, and the “Prompt for Reauthentication” setting.

Further information can be found here -

https://help.okta.com/en/prod/Content/Topics/Security/App_Based_Signon.htm

User Messaging

When a user fails to meet the criteria to allow them access to Verkada Command, they will be presented with an error message dependent on the IdP being used.

Azure AD

Okta

Did this answer your question?