SAML Provisioning Rule Dynamic User Group Membership

[system]

How to determine if the SAML Provisioning Rules for dynamic user group memberships is working?

Issue Description

This article explains how SAML2 dynamic provisioning works and how to debug issues related to it.

How To Debug SAML2 Provisioning

1. Review the section "How SAML2 Provisioning Works" as needed. This section is located after the current content and serves as a reference.
2. Generate a trace as outlined in the SAML2 Data Collection instructions.
3. Capture a screenshot of the provisioning rules, which will be needed for evaluating the SAML2 request.
4. Raise a support case with UiPath Support, including the gathered information.
5. If desired, UiPath can help test group allocation rules.

How SAML Provisioning Works

This section is optional and not required for collecting information about the issue:

For an overview of SAML2, refer to the article SAML2 Data Collection, which provides a basic introduction. For specific UiPath documentation, see SAML2 Provisioning.

When a request is made to log in via SAML2, a SAML2 response is generated and passed to the login portal. This response is a signed document containing information about the user, which may include the user's email address, first name, last name, and group memberships. These elements are referred to as attribute statements or claims, and their configuration on the IDP endpoint is typically managed by an administrator. Most SAML2 administrators should be familiar with adding groups or additional claims as part of standard operations.

An attribute statement comprises an Attribute Name, a Value, and a Name Format. The focus is primarily on the Attribute Name and the Value. When dynamic provisioning is enabled, the SAML2 attribute statements are evaluated according to the provisioning rules, which determine how a user is mapped to a group. These rules include:

• A test: A condition that a claim must satisfy.
• A group assignment: The group to which the user is assigned when the test is passed.

For example, consider a scenario using OKTA with a configured group. Note that while any SAML2 provider will have settings for groups, the presentation may vary based on implementation. Consult the specific SAML2 vendor documentation for details.

The previous explanation specified that the SAML2 attribute statements will contain an attribute named "group" with the value "ProvDynamGroup." The "Contains" part relates to OKTA-specific features and can be ignored. In most setups, the attribute Name is configurable, although it may be predefined in some cases. The value should always be configurable.

The end result of the settings described is that the SAML2 response will include an attribute named "group" with the value "ProvDynamGroup." Additional information, such as email and username, will also be present.

In the following example, the platform portal has the following rule set up:



This rule states that if there is an attribute statement with the name "group" and the value of that statement contains "ProvDynamGroup", the user will be assigned to the group "Administrator." In the provided example, the condition is met, resulting in the user being assigned to the group "Administrator" upon login. Please note that the "contains" relationship is case-sensitive.

A common misunderstanding occurs when users expect to see the groups configured in their identity provider directly represented on the User Management Page. This is not the case. Groups are not imported from the identity provider into the platform. Instead, rules are created to map users to pre-existing groups within the platform. Directly importing groups would be complicated and unnecessary, as permissions must still be delegated. This process is similar to creating the corresponding group along with the roles and provisioning rule.

For example, a user might incorrectly expect to see membership in the "ProvDynamGroup" within the platform; however, this will not occur.

Continuing with this example, the following information will be displayed:

A common practice is to create a group with the same name in our platform as is in the utilized IdP (OKTA, Pingone, etc).

Another important point is that group assignment occurs only at the time of login, utilizing a "Just-In-Time" provisioning approach.