Mapping Extra SAML Attributes to App Metadata

Help
, ,
1

Summary:
How can we check against custom SAML attributes in Actions without the use of a Rule to move data from the root level into app_metadata?

More Detail:

We use Auth0 to cater to our B2B use case, and we have support staff and developers that occasionally need to sign into a customer site to do some debugging or configuration management. Our staff will be logging in using a SAML enterprise connection (Auth0 is serving as the SP). Our IAM policy management would prefer that we can control which staff can sign into which customer sites with security groups in our IdP.

These groups don’t have a great root level field to map to on the Auth0 user profile, so we ideally would want to put these into app_metadata. However, SAML mappings don’t support dot notation, so we have to put them into a custom field and use a Rule to move them into app_metadata, and then perform validation later in an Action. This was the best solution I could find online, and searching for an answer is difficult since Auth0 can serve as both the IdP and SP.

I am worried our use case will be unsupported since:

  • To map SAML attributes to metadata, we need to use a Rule or an Action. Source (scroll down to Rueben’s case 4.)
  • Actions don’t support “Top-level event.user attributes added by an external IdP or custom database script”. Source
  • Rules and Hooks have been slated for EOL next year. Source
1 Like
2

It looks like all user attributes (including custom fields) can be obtained via the Auth0 Management API (GET /v2/users/samlp|some-idp|someUserId). So I think something like this would work:

  1. Your SAML connection maps SAML attributes to custom top-level user attributes.
  2. When a user logs in, your Action fetches the user’s complete profile from the Management API and makes the validation decision based on user attributes. (You can also populate app_metadata but that might be redundant.)

But this is really not ideal as it incurs 1 call against the Management API for every SAML login, and your Action has to deal with client credentials, caching the access token, etc.

It’d be much easier if event.user exposed these fields directly.