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 instantly propagated. Instead of Avigilon Alta pulling updates every 15 minutes, SCIM immediately pushes new or updated information to the Alta platform.

Okta Advanced app set up and configure

1. Go to http://control.openpath.com/login and sign in. To access the European Alta Access, go to
   http://control.eu.openpath.com/login .

2. Go to App marketplace > Get apps.

   1. Click the Okta Advanced tile.

   2. Click the + Get app Organization button.

3. Go to App marketplace > My apps.

   1. Click the pencil icon to edit Okta Advanced

4. In Sync type, select SCIM.

5. Click the Generate auth token button and copy the token. Click Done.

   1. You will need this token for the setup of SCIM in Okta in step 6.

6. Set up SCIM in your Okta portal.

7. After setting up SCIM in Okta, manually trigger the first sync in the Okta portal and then refresh the Access Groups or Roles page in Alta Access.

8. Enable the following settings, as needed:

   1. Auto-create mobile credential - Creates a mobile credential for every user.

   2. Auto-create cloud key credential - Creates a cloud key credential for every user.

   3. Sync mobile phone numbers - Syncs the mobile phone number for every user. Phone numbers must
      use E.164 format with a maximum of 15 digits: +[country code][subscriber number
      including area code]

   4. Enable single sign-on (SSO) for users with portal access - Allows Okta super admin users to log in to the Avigilon Alta Access with their Okta credentials.

   5. Enable single sign-on (SSO) for mobile app - Allows users to log in to the Openpath app using Okta
      credentials.

9. If you have not created any Avigilon Alta access groups yet, please first create them in Users > Access groups

10. Use the Create access group mapping button to map your Okta groups to your Avigilon Access groups.

11. 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 Applications item.

2. Click Create App Integration, choose SAML 2.0, 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.

5. Enter the following SCIM Connection settings:

   1. SCIM connector base URL: Enter the base URL for your organization (e.g., https://yourcompanyname/scim/v2/okta/).

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

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

6. Test the connection configuration and click Save.

7. Switch back to your Okta Advanced app, continuing at #7 above.

SCIM advanced mapping

(Optional) Enable the Show advanced mapping toggle.

Use the JSON editor to create rules for HTTPS requests that map users from the identity provider to a specific group or all groups 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).