Cannot Access Mapped SAML Properties inside Custom Action

Hello,

I have a SAML connection where Auth0 is the Service Provider for my application. I am trying out the new login flows but am running into a small problem that I’m not sure how to solve.

What I am trying to do
On a successful login from the SAML IdP, I want to update a user’s app_metadata with the returned roles and account.

What is Happening
I cannot seem to get the roles field off the user object from the SAML login

My configuration
In my Enterprise SAML connection I have this mapping:

{
  "role": [
    "http://schemas.auth0.com/app:role",
    "http://schemas.auth0.com/role"
  ]
}

This mapping works because I see role show up on my user when I view their raw JSON data in the dashboard. The property is a top level prop like so:

{
    "role": "manager",
    "user_id": "samlp|{connection}|auth0|{id}",
    "app_metadata": {
        "account": "sso-incorporated"
    },
   // lots more fields
}

I then created this flow action to run after a successful login:

exports.onExecutePostLogin = async (event, api) => {
  if (event.user.email) {
   // custom function to determine the account name from email address
    const accountName = getAccountNameFromEmail(event.user.email);

    if (accountName) {
      // this works
      api.user.setAppMetadata("account", accountName);
      // this does not. Never saves anything (assuming `event.user['role']` is undefined)
      // I cannot figure out how to access the `role` on my user object from SAML reponse
      api.user.setAppMetadata("role", event.user['role']);
    }
  }
};

Is there any way I can access that property? I don’t mind putting my logic in the mapping rules either, but I don’t think it lets me map into app_metadata fields. I need the roles in the app_metadata because I search users based on that information.

Thanks!

1 Like

Hi @davidhouseknechtdev ,

Unfortunately I am not aware of a good way to do this within Actions alone currently.

App_metadata is supposed to only be modified via Rules, Actions, Dashboard or the Management API and not tied to a particular connection, and so it can cause issues if set directly by an external IdP. (Understand How Metadata Works in User Profiles)

What I would recommend is mapping the claims from your upstream IdP to a custom root profile entry that doesn’t overlap with an Auth0 profile attribute (User Profile Structure).

Currently, Actions can only access the attributes that are listed for the relevant trigger’s Event object, e.g the Post Login triggers event object is detailed here:

Because of this, you would then need a Rule to copy this custom attribute into the user’s app_metadata so it could be accessed by your Actions:

Sorry for the wait, I hope this is still useful

2 Likes

Hello @sgo ,
Thank you for your answer to David’s problem, I am having the same issue and am currently able to circumvent it using rules instead of actions.
The problem is, we are receiving notifications from Auth0 advising us to migrate to Actions as Rules are becoming Legacy.
Do you know if Auth0 is planning to make mapped SAML properties available in actions in the near future? Do we have to keep using rules for this problem only?

Thank you

Hi @anouk, I have mentioned this internally in the past to our Engineering team and after a bit of digging I can see this has been added to the backlog. Unfortunately, I can’t provide any guarantees or ETAs at this time, but this should be possible in Actions without needing Rules in the future.

But until then, or an alternative is provided, you would need to continue using Rules to read extra claims an upstream IdP may provide to your Auth0 tenant.

2 Likes

As a workaround, I found that if I load the User object from the Management API, rather than rely on the User object I receive within the Event parameter, I am able to see claims, such as groups, that were added from the SAML token. I hope this helps!

1 Like

Thanks for pointing this out @bschreiber - yes you can fetch the full user object via the Management API too - however, a downside of this is the rate limits on the Management API are more restrictive, so wouldn’t scale well if it were to be called on every login for example.
You could mitigate this by using conditional logic to only make the call for a first time login though.

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.