Content Comparison

The System for Cross-domain Identity Management (SCIM) standard enables administrators to manage user and group information across Okta and external applications.

SCIM updates from the IDP are immediately propagated and do not require a full database syncinstantly propagated. Instead of Avigilon Alta pulling updates every 15 minutes, SCIM immediately pushes new or updated information to the Alta platform.

...

Prerequisites

To use this application, your account must meet the following requirements:

• Have these Avigilon Alta licenses:

  • Premium or Enterprise

  • Okta Advanced

• Admin access to your Okta organization is required to configure SCIM.

Supported features

The SCIM service supports the following capabilities:

• Create Users: Users assigned to the Avigilon Alta application in Okta are eligible for synchronization with Avigilon Alta.

• Update User Attributes: Changes made to user attributes in Okta are propagated to the Avigilon Alta application.

• Group Push: Groups and their members in Okta can be pushed directly to the Avigilon Alta application.

Okta Advanced app set up and configure

1. Go to Sign in to your account:

   • Visit http://control.openpath.com/login

   and sign in. To access

   • for the standard Alta Access portal.

   • For the European Alta

   Control Center, go to
   

   • Access portal, visit http://control.eu.openpath.com/login.

2. Go Navigate to App marketplace Marketplace > Get appsApps.

3. Click the Okta Advanced tile.

4. Click the

   Select + Get

   app

   App Organization

   button

   .

5. Go to App marketplace Marketplace > My appsApps.

6. Click the pencil icon to edit the Okta Advanced app.

7. In Under Sync typeType, select SCIM.

8. Click the Generate auth token button and Generate Auth Token, copy the token. Click Done, and click Done.

   • Note: You will use this token during SCIM setup in Okta (Step 9).

9. Set up SCIM in your Okta portal.

10. After setting up SCIM in Okta:

    • Manually trigger the first sync in the Okta portal

    and then refresh

    • .

    • Refresh the Access

    groups

    • Groups or Roles page in Alta

    
    Control Center

    • Access.

11. Enable any of the following settings , as needed:

    • Auto-create mobile credential

    - Creates

    • : Automatically creates a mobile credential for every user.

    • Auto-create cloud key credential

    - Creates

    • : Automatically create a cloud key credential for every user.

    • Sync mobile phone numbers

    -

    • : Syncs

    the mobile phone number for every user. Phone numbers must
    use

    • user phone numbers in E.164 format

    with a

    • (maximum

    of

    • 15 digits

    :

    • , e.g., +[country code][subscriber number

    
    including area code

    • ]).

    • Enable single sign-on (SSO) for

    users with

    • portal access

    -

    • : Allows Okta super

    admin users

    • admins to log in to

    the

    • Avigilon Alta

    Control Center with their

    • Access using Okta credentials.

    • Enable single sign-on (SSO) for mobile app

    - Allows

    • : Enables users to log in to the Openpath app using Okta

    
    credentials.

    • credentials.

12. If you haven’t created any Avigilon Alta access groups yet, go to Users > Access Groups and create them.

13. Use the Create Access Group Mapping button to map Okta groups to Avigilon Alta Access groups.

14. SCIM advanced mapping (optional)

Okta portal SCIM configuration

Follow these steps to set up the SCIM integration:

1. In the left-hand menu, select Applications and then click on Applications item.

2. Click Create App Integration, choose SAML 2.0, and then click Next to complete the SAML setup workflow.

3. Go to the General tab, then select SCIM under Provisioning.

4. Switch to the Provisioning tab and click on Integration.Go to Okta > Applications

5. Browse App Catalog

6. Search for and select Avigilon Alta

7. Add integration

8. Navigate to the Provisioning tab

9. Select Configure API Integration

10. Enable the checkbox labeled Enable API integration

11. Enter the following SCIM Connection settings:

    • SCIM connector base URL: Enter

    the base URL for your organization (e.g.,

    • your organization's base URL

      • The US region is https://api.openpath.com/scim/v2/okta/{orgId}

      • The EU region is https://

    yourcompanyname

    • • api.eu.openpath.com/scim/v2/okta/{orgId}

12. In the Authorization section, paste the token from Alta Access.

13. Checkbox Import Groups must be unchecked as it is not supported.

14. Test the connection configuration and click Save.

15. Return to your Okta Advanced app and continue from step #7 above.

SCIM advanced mapping

(Optional) Enable the Show advanced mapping toggle.

...

Configure the fields for Unique identifier for users, Import New Users and Profile Updates, Push New Users, Push Profile Updates, and HTTP Header for Authentication Mode.

...

In the Authorization section, paste the token from the Alta Control Center.

...

Test the connection configuration and click Save.

...

Use the JSON editor to create rules for HTTPS requests that map users from the identity provider to a role or a specific group in Alta Access.

Examples:

Imagine you have created the following Access groups: "Engineering Group" (id 1) and "Engineering Manager Group" (id 2). Additionally, you have made the roles "Engineering Role" (id 3) and "Engineering Manager Role" (id 4).

Now, consider the following template rule you have set up.

{
  type: "template",
  "mappings": [
    {
      accessGroupTemplates: ["{{ department }} Group", "{{ department }} {{ role }} Group"],
      roleTemplates: ["{{ department }} Role", "{{ department }} {{ role }} Role"]
    }
  ]
}

The items within {{}} represent the keys from the incoming data source. These keys will be used to parse the data and attempt to match it with the Access group and role names you have already created.

For instance, consider the following SCIM data as it arrives.

{
  "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
  "id": "example-user",
  "externalId": "example-user",
  "userName": "exampleUserName",
  "name": {
    "formatted": "Example User",
    "familyName": "User",
    "givenName": "Example"
  },
  "emails": [
    {
      "value": "example.user@example.com",
      "type": "work",
      "primary": true
    }
  ],
  "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User": {
    "department": "Engineering",
    "role": "Manager"
  },
  "meta": {
    "resourceType": "User",
    "created": "2024-06-10T08:24:12Z",
    "lastModified": "2024-06-10T08:24:12Z",
    "version": "W/\"3694e05e9dff591\""
  }
}

This data includes a department key with the value Engineering. Behind the scenes, we would convert {{ department }} Group to Engineering Group and {{ department }} Role to Engineering Role. The user would be added to both since these group and role names already exist in your organization (as shown in the previous example).

Additionally, the user has the role of "Manager". Given that we have defined templates for "{{ department }} {{ role }} Group" and "{{ department }} {{ role }} Role", we would also generate Engineering Manager Group and Engineering Manager Role, which would map to the existing access groups and roles.

However, if the user's role were "Junior," they would not be added to the Engineering Manager Role/Group.

Here is an equivalent example but using a specific rule.

{
  type: "specific",
  "mappings": [
    {
      "conditions": [
         {
            "key": "department",
            "value": "Engineering"
         },
        {
            "key": "role",
            "value": "Manager"
         }
      ],
      "destinations": [
        {
          "roleIds": [4] // Engineering Manager Role
		  "accessGroupIds": [3] // Engineering Manager Group
        }
	
      ]
    },
    {
      "conditions": [
         {
            "key": "department",
            "value": "Engineering"
         },
      ],
      "destinations": [
        {
          "roleIds": [3] // Engineering Role
		  "accessGroupIds": [1] // Engineering Group
        }
	
      ]
    }
  ]
}

In the example above, we have two mappings, each with its own set of "conditions." The user data must match these conditions, and if it does, the user will be added to all roles and access groups specified in the roleIds and accessGroupIds arrays. It's crucial to emphasize that the user data must include all the key/value pairs defined in the conditions for this to happen.

For example, in our first mapping, the conditions are:

{
            "key": "department",
            "value": "Engineering"
         },
        {
            "key": "role",
            "value": "Manager"
         }

This means that the incoming user data must include both "department": "Engineering" and "role": "Manager" for the user to be added to role ID 4 (Engineering Manager Role) and access group ID 3 (Engineering Manager Group). Additionally, in the second mapping, the user data only needs to include "department": "Engineering" for the user to be added to role ID 3 (Engineering Role) and access group ID 1 (Engineering Group).