Identity Providers

Satori integrates with identity providers to enrich its identity context and deliver better analytics and more accurate access control policies. Satori interacts with identity providers either via API or by using the SAML protocol.

API-based integrations

In API-based integrations, customers provision an API token for Satori to access the identity provider and fetch additional information about the user, like groups. API-based integrations are supported in both single sign-on and non-single sign-on flows, and are less dependent on the type of data store. The only requirement is that the credentials used to authenticate to the data store can be used to lookup information about the user. For example, if John Smith's user ID in the identity provider is john.smith@example.com and John is using the same ID to connect to the data store, Satori will be able to lookup John in the identity provider.

Okta API Integration

The Okta API token needs either a Group Admin or Read-Only Admin permissions. To create an API token for Satori to access Okta follow these steps:

• Go to your Okta console and access the admin view. Your Okta console should be available in https://<your_okta_hostname>.okta.com
• Select API and then Tokens
• Select Create Token
• Provide a name for the token and select Create Token
• Copy the token value

Follow these steps to set the API token in Satori and enable Okta for your data store:

• Go to the Satori management console
• Select Identity Providers, Add and then Okta
• Enter your Okta hostname, for example: https://acme.okta.com and API token, for example: 12H-VciTZ_1ZBD8TpMWfXBh00WcaXeuqookQRafock.
• Select Test to check if the configuration is correct. If not, a detailed error message would appear
• Select the data stores you want Satori to use Okta on

AzureAD API Integration

Coming soon.

SAML-based integration

In SAML-based integrations, customers configure their identity provider to send additional information about the user as part of the SAML assertions sent when a user logs in. The advantage of this integration is that there's no need to provision an API token for Satori to the identity provider, however it requires that the data store supports SAML-based authentication.

To define policies that use an identity provider group, use the Identity Provider Group tag.

Okta SAML-based integration

To send additional information about the user from Okta, follow these steps:

• Go to your Okta console and access the admin view. Your Okta console should be available in https://<your_okta_hostname>.okta.com
• Select the application you use to enable access to a Satori-protected data store
• Edit the application and go to the Configure SAML step
• In the GROUP ATTRIBUTE STATEMENTS (OPTIONAL) section, add an attribute named groups and Unspecified for the Name format field. In the Filter field, select the desired option to provide filter which group names will be sent. To send all groups, select Matches regex with value .*.

Okta groups are shown in Satori by their unique name, for example: Security Team.

AzureAD SAML-based integration

To send additional information about the user from AzureAD, follow these steps:

• Go to your AzureAD console and access the Enterprise Application view.
• Select the application you use to enable access to a Satori-protected data store.
• Select the Single sign-on view and press Edit in the User Attributes & Claims section.
• Select Add a group claim, and in the Group Claims panel select which groups associated with the user to send in the claim.
• In the Advanced options section, check the Customize the name of the group claim checkbox and in the Name field enter groups.

AzureAD groups are shown in Satori by their unique ID, for example: 1053707e-fdac-4af7-8d98-2347dfd79052.