SCIM IDP

The SCIM IDP feature is coming soon. Follow this page to see when it is released.

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.

When an Identity Provider (IDP) creates unique IDs for users, deleting and recreating a user in the IDP results in a new unique ID for that user. If you add the recreated user back into Avigilon Alta, the system will recognize them as a new user due to the new ID, even though the email address is the same. This can confuse, as it becomes unclear which version of the user is correct.

Note: SCIM 2.0 is supported and currently only works with the Okta Advanced app from Avigilon Alta Market Place.

Note:
If a user is manually inactivated in the Alta Access system, they will remain inactive regardless of Identity Provider updates until manually reactivated from within the Alta Access system.

Avigilon Alta currently does not support the following Okta provisioning features but may do so in the future:

Sync Password
Groups > Push Now
Remove Users *

* Note: Users are not removed from the Avigilon Alta application; they are only deactivated.

Prerequisites

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

Have one of these Avigilon Alta licenses:
- Okta Advanced
- Premier User Management
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.
Deactivate Users: When users are deactivated in Okta, this status is reflected in 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

Sign in to your account:
- Visit http://control.openpath.com/login for the standard Alta Access portal.
- For the European Alta Access portal, visit http://control.eu.openpath.com/login.
Navigate to App Marketplace > Get Apps.
Click the Okta Advanced tile.
Select + Get App Organization.
Go to App Marketplace > My Apps.
Click the pencil icon to edit the Okta Advanced app.
Under Sync Type, select SCIM.
Click Generate Auth Token, copy the token, and click Done.
- Note: You will use this token during SCIM setup in Okta (Step 9).
Set up SCIM in your Okta portal.
After setting up SCIM in Okta:
- Manually trigger the first sync in the Okta portal.
- Refresh the Access Groups or Roles page in Alta Access.
Enable any of the following settings as needed:
- Auto-create mobile credential: Automatically creates a mobile credential for every user.
- Auto-create cloud key credential: Automatically create a cloud key credential for every user.
- Sync mobile phone numbers: Syncs user phone numbers in E.164 format (maximum 15 digits, e.g., +[country code][subscriber number]).
- Enable single sign-on (SSO) for portal access: Allows Okta super admins to log in to Avigilon Alta Access using Okta credentials.
- Enable single sign-on (SSO) for mobile app: Enables users to log in to the Openpath app using Okta credentials.
If you haven’t created any Avigilon Alta access groups yet, go to Users > Access Groups and create them.
Use the Create Access Group Mapping button to map Okta groups to Avigilon Alta Access groups.

SCIM advanced mapping (optional)

Okta portal SCIM configuration

Follow these steps to set up the SCIM integration:

Go to Okta > Applications
Browse App Catalog
Search for and select Avigilon Alta
Add integration
Navigate to the General tab and choose SCIM under Provisioning.
Switch to the Provisioning tab and click Integration.
Enter the following SCIM Connection settings:
- SCIM connector base URL: Enter your organization's base URL (e.g., <https://yourcompanyname/scim/v2/okta/).>
- Configure the fields for:
  - Unique identifier for users
  - Import New Users and Profile Updates
  - Push New Users and Profile Updates
  - HTTP Header for Authentication Mode
In the Authorization section, paste the token from Alta Access.
Test the connection configuration and click Save.
Return to your Okta Advanced app and continue from step #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:

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).

Field	Format	Definition

Field	Format	Definition
type	String	specific or template
key	String	The user group in the identity provider system.
value	String	The name of a user group in the identity provider system.
mappings	String	destinations.
destinations	String	roleIds, accessGroupIds, roleTemplates, or accessGroupTemplates predefined for an organization.
roleIDs	String	The ID number of a role.
accessGroupIds	String	The ID number of an access group.
roleTemplates	String	The name of a role and the specified user group (key).
accessGroupTemplates	String	The name of an access group and the specified user group (key).