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 perform the following:
- 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
Configuring the API Token in Satori
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 the following:
- Okta hostname, for example:
https://acme.okta.com
- API token, for example:
12H-VciTZ_1ZBD8TpMWfXBh00WcaXeuqookQRafock
.
- Okta hostname, for example:
- 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
Setting Up the API Token and Enabling Azure Active Directory
To set the API token in Satori and enable Azure for your data store, perform the follwing steps:
- Go to the Satori management console
- Select Identity Providers under Account Setting, Add and then Azure Active Directory API
-
Enter you the following attributes:
- 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
- Tenant ID, for example:
-
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.
Setting UP the API Credentials in Satori and Enabling OneLogin on your Dat Store
Perform the following steps to set the API credentials in Satori and enable the OneLogin for your data store:
1. Go to the Satori management console
2. Select the Identity Providers under the Account Setting, Add and then choose the OneLogin API.
3. Enter your API Credentials
- Client ID, for example: 410d1909535ef70149ac34f706277082951215b30bdd114608a7499fd4875772
- Client Secret, for example: ba92c053174590ebeb0332b5c83aa6a4367bca4be816e2ba9c538e4d640b2b8d
4. Select Test to check if the configuration is correct. If not, a detailed error message will appear.
5. 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.
Defining Policies that use an Identity Provider Group
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 Claimbutton 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 then click Save.