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

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

• Go to the Satori management console
• Select Identity Providers under Account Setting, Add and then Okta
• Enter your:
  • Okta hostname, for example: https://acme.okta.com
  • 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

The Azure API integration requires the following configurations:

• Tenant ID
• Enterprise application and its Application ID (as a client ID)
  • Enterprise application can be created at Azure Active Directory service -> Enterprise applications.
  • Assign following permissions to this application at Azure Active Directory service -> API permissions
  • https://graph.microsoft.com/User.Read.All
  • https://graph.microsoft.com/GroupMember.Read.All
  • Make sure you "Grant admin consent for Tenant Name" and status is Granted.
• Client secret for above application
  • Client secret can be created at Azure Active Directory service -> App registrations -> Certificates & secrets

Perform the following steps to set the API token in Satori and enable Azure for your data store:

• Go to the Satori management console
• Select Identity Providers under Account Setting, Add and then Azure Active Directory API

• Enter your:

  • Tenant ID, for example: ee718de2-b2b3-43da-9331-b40504c57f49
  • Application (client) ID, for example 293691c5-0b43-4f07-8e5c-771c75ec6c4b
  • Client secret, 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 Azure Active Directory API on.

OneLogin API Integration

OneLogin's integration binds the detected user email to the group that the user is assigned to.

The OneLogin API integration requires the following configurations:

• Client ID
• Client Secret

The Client ID and Secret can be created at the following location Developers -> API Access. The new API credentials should receive at least a Read users access.

Perform the following steps to set the API credentials in Satori and enable the OneLogin for your data store:

• Go to the Satori management console
• Select the Identity Providers under the Account Setting, Add and then choose the OneLogin API.
• Enter your API Credentials
  • Client ID, for example: 410d1909535ef70149ac34f706277082951215b30bdd114608a7499fd4875772
  • Client Secret, for example: ba92c053174590ebeb0332b5c83aa6a4367bca4be816e2ba9c538e4d640b2b8d
• Select Test to check if the configuration is correct. If not, a detailed error message will appear.
• Select the data stores that you want Satori to use on the OneLogin API.

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 to Satori, perform the following steps:

• Go to your Okta console and access the admin view. Your Okta console should be available from the following https://<your_okta_hostname>.okta.com
• Select the application you use to enable access to a Satori-protected data store
• Click the "Edit" button of the application and select the Configure SAML tab.
• In the ATTRIBUTES Section add satori_user to the name input field.
• Select the user.login option from the value drop menu.
• 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 the filter which the group names will be sent to.
• To send all groups that the user is a member of to Satori, select Matches regex from the filter drop menu item and define it with a value of .*.

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 to Satori, perform the following 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 the Edit button in the User Attributes & Claims section.
• Click the "Add New Claim" button and populate the following attributes: "Name" user_login and "Source Attribute" user.primaryauthoritativeemail

• Click the "Add a Group Claim" button and select which groups are 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.

OneLogin SAML-Based Integration

To send additional information about the user from OneLogin to Satori, perform the following steps:

• Go to your OneLogin console and access the SAML application.
• In the Parameters tab, add a new parameter by clicking on the plus.
• Add the parameter user_login and check the "Include in SAML assertion" and SAVE.

• Then select the "Email" drop menu option from the value section and SAVE.
• Set the name of the parameter to groups and check the Include in SAML assertion flag.
• Select the value of the parameter, for example, Member Of and Save.