Skip to main content
can be used to assign roles to your Members implicitly, based on either the SSO Connection or the Member’s SSO Connection IdP Group. You can create or update SSO connection or IdP group implicit role assignment by making calls to the following API endpoints: or manually updating the SSO Connection for the in the Stytch Dashboard.

​
SSO Connection-based Role Assignments

Assign roles to your Members implicitly based on their specific SSO Connection by passing role_ids to connection_implicit_role_assignments. For example, if you want to assign the admin role to anyone who authenticates via the SSO connection, you can pass the following connection_implicit_role_assignments argument: 
{
  "connection_implicit_role_assignments": [
    { "role_id": "admin" }
  ]
}

​
SSO Connection IdP Group-based Role Assignments

Assign roles to your Members implicitly based on their SSO Connection IdP Groups by passing role_id and group pairs to group_implicit_role_assignments. For example, if you want to assign the admin role to anyone in the engineering group, you can pass the following group_implicit_role_assignments argument: 
{
  "group_implicit_role_assignments": [
    { "role_id": "admin", "group": "Engineering" }
  ]
}
Then, add a groups key to the SAML connection’s attribute_mapping. The IdP should be configured to send a list of strings under that key. For example, if your Stytch SAML connection has the following attribute mapping: 
{
  "attribute_mapping": {
    "email": "email",
    "full_name": "name",
    "groups": "groups"
  }
}
And Stytch receives the following SAML assertion for a Member: 
<saml2:Attribute Name="groups" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
    <saml2:AttributeValue>EPD</saml2:AttributeValue>
    <saml2:AttributeValue>Engineering</saml2:AttributeValue>
</saml2:Attribute>
Based on the group_implicit_role_assignments and their membership in the Engineering group, the Member will be assigned the admin role.

​
Interactions between Implicit and Explicit Role Assignments

Because implicit role assignments are based on the Member’s login method, RBAC authorization checks are based on the roles for a Member’s Session, rather than the Member definition. This means that a Member’s roles may vary, depending on the login method for that Session. If an explicitly assigned Role is removed from a Member, and the Member is also implicitly assigned that Role from an SSO connection or an SSO group, we will by default revoke any existing Sessions for the Member that contain any SSO authentication factors with the affected connection ID. For example, consider a Member with the following Roles: 
{
  "member_id": "member-test-32fc5024-9c09-4da3-bd2e-c9ce4da9375f",
  "roles": [
    {
      "role_id": "editor",
      "sources": [
        {
          "type": "direct_assignment",
          "details": {}
        },
        {
          "type": "sso_connection",
          "details": {
            "connection_id": "saml-connection-test-51861cbc-d3b9-428b-9761-227f5fb12be9"
          }
        }
      ]
    },
    {
      "role_id": "stytch_member",
      "sources": [
        {
          "type": "direct_assignment",
          "details": {}
        }
      ]
    }
  ]
}
This Member’s editor role comes from two sources: an explicit role assignment and an SSO connection implicit role assignment. Now consider the following Member Session, which contains a SAML SSO authentication factor: 
{
  "member_session": {
    "member_session_id": "session-test-fe6c042b-6286-479f-8a4f-b046a6c46509",
    "member_id": "member-test-32fc5024-9c09-4da3-bd2e-c9ce4da9375f",
    "authentication_factors": [
      {
        "delivery_method": "sso_saml",
        "saml_sso_factor": {
          "id": "saml-member-registration-test-9a6d293d-d8b3-42e8-abb4-220cc2060e93",
          "provider_id": "saml-connection-test-51861cbc-d3b9-428b-9761-227f5fb12be9"
        },
        "type": "sso"
      }
    ],
    "organization_id": "organization-test-07971b06-ac8b-4cdb-9c15-63b17e653931",
    "roles": ["stytch_member", "editor"]
  }
}
If the Member is then updated (for example, from a call to Update Member) to remove the editor explicit role assignment, we will revoke the Member Session with the SAML SSO factor. If you do not want any Sessions to be revoked when updating a Member’s explicit role assignments, you can pass the preserve_existing_sessions argument with a value of true to the following endpoints: