Veza has the capability to automatically assign certification rows to a user's manager. There is currently no UI for customers to configure this feature and the API to do so is a private API. When configured properly, a certification created with the setting of auto-assign to the manager should automatically be assigned to a user's manager, and when selecting re-assign on a certification row, you should be able to search for any user in the integrated identity provider, regardless of whether that user has previously logged into Veza or not.
Perquisites:
- As this configuration is done via a private API, we have not documented the configuration steps for customers. To configure the setting you will need to have the customer create an admin account for you in their tenant. This admin account will be leveraged to obtain a bearer token to make the required API calls.
- The customer must have an identity provider integrated with their Veza tenant (Azure AD, Okta, Active Directory (On-Prem), CustomIDP
- For manager lookup functionality, there must be a uniquely identifying field within the Veza IDP profile for users that can be leveraged for lookup and the field value must match the unique ID we will be setting for users. Ensure that this attribute is present before you move forward to configuration.
Configuration Steps
- With developer tools in your browser open, log in to the admin acct the customer created for you. Within the Application tab >> Cookies > Token, you should have a Bearer token. Copy everything after the word bearer to your clipboard for use later.
- If the token doesn't work, you will need to create an API token in Administration -> API Keys -> Add New Personal API key
- Before making the API call to configure the IDP settings, we first need to make an API call to determine the ID for our auth provider. This can be done by making a GET call to the private endpoint
curl --location 'https://lab-cs.vezacloud.com/api/private/auth_providers' \
--header 'Cookie: token='
curl --location 'https://customer-tenant.vezacloud.com/api/private/auth_providers' \
--header 'authorization: Bearer token'
3. For cloud customers, we will need the ID from the "SAML_AUTH_PROVIDER". Copy this value for use later.
4. To set the configuration in the customer tenant we will need to make a PUT call to the endpoint
https://customertenant.cookiecloud.ai/api/private/workflows/access/global_settings/idp_settings
The call should contain the raw JSON in the body as below
{
"value": {
"enabled": true,
"idp": {
"auth_provider_id": "THE VALUE YOU COPIED IN STEP 2",
"user_type": "ENTER CUSTOMERS IDP USER TYPE",
"instance_id": "DATASOURCE ID",
"user_identity_property": "UNIQUE IDENTIFIER FOR USERS. MATCHING MANAGER FORMAT",
"instance_id_property": "datasource_id",
"manager_identity_property": "UNIQUE IDENTIFIER FOR MANAGERS. MATCHING USER FORMAT"
}
}
}
The quickest method to obtain some of the value here is to simply open developer tools and then run a search in Query Builder for the user type in question and open the details for an example user. The example below shows the values that would be required to set up an AzureAD user.
"user_type" will differ depending on the IDP the customer has integrated.
"instance_id" will be the value of the "datasource_id"
"user_identity_property" is "idp_unique_id"
"instance_id_property" will be "datasource_id"
"manager_identity_property" will be the header of the manager field that they would like to use. This is the field's property name and NOT the field's value. Exp: "manager_principle_name" or "manager"
So from the example above, the payload sent in the PUT call to
https://customertenant.cookiecloud.ai/api/private/workflows/access/global_settings/idp_settings
would be:
{
"value": {
"enabled": true,
"idp": {
"auth_provider_id": "64046fd2-5bc4-4348-8e40-a66ddc3e52e8",
"user_type": "AzureADUser",
"instance_id": "a95f93a6-6a75-4e3b-831a-966f1930949e",
"user_identity_property": "idp_unique_id",
"instance_id_property": "datasource_id",
"manager_identity_property": "manager_principal_name"
}
}
}
Comments
0 comments
Article is closed for comments.