OKTA User Provisioning with SAML

Planning

As described here, DataSet allows you to define access groups within your DatSet account, which have a permission level associated with them (full, user, readLog or limited). The DatSet SAML Provisioning functionality allows you to associate one or more Okta groups with a DatSet access group.

A sample use case would be an Admins group that has full access and an Engineer group that has user access. If you have an Okta group called Engineering, you can associate it with the Engineer group so that everyone in the Okta group has user level access. If you have another Okta group called Observability, you can associate it with the Admins group so its members get full access. Users in both groups will get the higher level of access (full).

Think about which access levels you’d like to provide to your users, and which Okta groups you already have (or will need to create) in order to support this model.

As noted above, it’s possible to associate multiple Okta groups with a single DataSet access group -- so if you happen to have a number of small Okta groups (rather than a big umbrella group like Engineering in the above example), you can still use those to grant access to a broad group of people.

Restricted vs Global user provisioning

Discuss this with your DataSet rep. In /scalyr/logs, there is a source attribute for each user, which tracks whether that user was provisioned via the WEB, API, or SAML. In restricted mode, SAML provisioning will only affect users that were provisioned via SAML. In global (open) mode, all users are in scope. The restricted mode can be helpful if you have a set of users whose access will be managed outside of the IdP, like admin(s) who should have access to all accounts. Regardless, we recommend configuring Restricted mode during testing, since Global mode can result in users being removed from teams if group membership is not being received from the IdP as expected.

Default Permission

Discuss this with your DataSet rep. If a user logs in and does not match any Scalyr access groups, we will either link the user to your account, with a defined permission level (limited, meaning effectively no access; readLog, user or full), or the user can be left unlinked to any account. In this situation, they will be on their own Scalyr team, which will be a trial Scalyr account.

Okta configuration

In Okta, go to the Scalyr app. Select General -> SAML Settings -> Edit, then hit Next.

Under the “Group Attribute Statements” section, add an attribute named memberOf, Name format: Basic. If desired, enter a filter that will specify the groups that are relevant to Scalyr. It is a best practice to limit this list so that only relevant groups are sent, but it is OK to include other groups.

It is possible to use a name for the group attribute other than memberOf. Please notify the DataSet support team of the field name if you are using something different.

The Okta group name starts with "scalyr" in this example

Within each DataSet team, define one or more access groups in the /scalyr/logs file. The name is a unique arbitrary string that can include spaces. permissions is one of full, user, readLog or limited. With limited, you will also define allowedDashboards and/or allowedSearch. externalAliases is a list of one or more groups from your IdP. More information on groups is available here. Here is an example:

{
 defaultSearchTimeSpan: "",
 groups: [
   {
     name: "Engineering",
     permissions: "user",
     externalAliases: ["scalyr-engineering-users","scalyr-infrastructure-users"]
   }
 ],
 users: [
		...
  ]
}

Testing & Deployment

1. This assumes SSO has already been set up and is working for your accounts.
2. Complete the Okta configuration and validate that the memberOf attribute is being sent successfully. There are browser plugins for this, or it can be done using the Developer Tools in your browser, using the Network tab to look for a page called acs as part of the SSO login process, taking the value of SAMLResponse and decoding via base64. Your Scalyr rep can collaborate with you on this.
3. The DataSet support team will configure SAML Provisioning in your DataSet account.
4. Begin with one or two users who are members of a specific IdP group for testing. Have the users log out (if needed) and then log in via the Okta SSO console page. Confirm that the test users see the appropriate groups in their teams list on the Manage Teams page.
5. Validate that the group assignments are working for other teams as well.

Appendix: SAML Groups attribute

Once your IdP is configured appropriately, it should send an attribute memberOf containing the list of groups to which the user belongs. Scalyr can be configured to look for a different attribute name as needed. Here is a sample group attribute:

<saml2:AttributeStatement xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
 <saml2:Attribute Name="memberOf" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
   <saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">scalyr-engineering-users</saml2:AttributeValue>
   <saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">scalyr-infrastructure-users</saml2:AttributeValue>
</saml2:AttributeStatement>