[IdP] IdP Auth0 using 'Name' attribute mapping

[IdP] IdP Auth0 using 'Name' attribute mapping

  
Forge Component
(26)
Published on 4 Jul by Telmo Martins
26 votes
Published on 4 Jul by Telmo Martins

Hi,

We've had Auth0 working with IdP for a fair while now but I've noticed that after the last update the 'Name' attribute on the Outsystems User account isn't populated at all - any idea what the correct way to map an Auth0 claim attribute to the User 'Name' field is?

Hi Dan,

Perhaps the claim name changed or the claim configuration is empty. In the saml messages screen, check the xml of a LoginResponse message. You can find the claim name like in this sample: ...<saml2:Attribute Name="<ClaimName>" NameForm..... After you identify the one that hold the User "Name" attribute, just set that <ClaimName> in the Configuration screen under "Given Name Attribute" or "Surname Attribute". User name will be the concatenation of those two claims (if configured).

Regards

Telmo Martins wrote:

Hi Dan,

Perhaps the claim name changed or the claim configuration is empty. In the saml messages screen, check the xml of a LoginResponse message. You can find the claim name like in this sample: ...<saml2:Attribute Name="<ClaimName>" NameForm..... After you identify the one that hold the User "Name" attribute, just set that <ClaimName> in the Configuration screen under "Given Name Attribute" or "Surname Attribute". User name will be the concatenation of those two claims (if configured).

Regards

Thanks - tried this but with no luck (configuration attached)

There is a /name attribute that's populated but the generated Outsystems User still has a blank Name (username and email are populated okay)


Hi,

Can you kindly attach the whole Claims configuration to the bottom, as well to the right to include the Split Char and Index values.

Also did you already confirmed in the saml xml message that the claim name is the expected one?

Regards

Telmo Martins wrote:

Hi,

Can you kindly attach the whole Claims configuration to the bottom, as well to the right to include the Split Char and Index values.

Also did you already confirmed in the saml xml message that the claim name is the expected one?

Regards

Hi Telmo,

Attached. I've also confirmed the claim contains the claim name in the saml xml responses, as below

<saml:Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml:AttributeValue xsi:type="xs:string">person.name@example.com</saml:AttributeValue></saml:Attribute>      

Hi Dan,

All seems fine. Can you check if the entity Config_UserMappings has only one row (or at least only one row per tenant) in the database. If it has only one, would say to debug the server action DataToUserData and check if the name is being returned by the xif extension.

Regards

There's two lines for the one tenant - should we remove one?

Solution

Hi Dan,

Yes, you must remove one. That's a bug in the earliest versions of the component that were duplicating those rows in some scenarios. It's no longer happens anymore, but the 'old' rows from previous versions needs to be removed manually. Would say to leave to one that has the right mappings and remove the other (before the delete just also update the FK on SPConfig entity to the right one that will be kept).

Regards

Solution

Telmo Martins wrote:

Hi Dan,

Yes, you must remove one. That's a bug in the earliest versions of the component that were duplicating those rows in some scenarios. It's no longer happens anymore, but the 'old' rows from previous versions needs to be removed manually. Would say to leave to one that has the right mappings and remove the other (before the delete just also update the FK on SPConfig entity to the right one that will be kept).

Regards

Cool thanks, there are two rows in SPConfig too... do I need to remove one of those or is that okay to leave as it is?


Hi Dan,

For the same tenant you must have only one row on that one as well, otherwise you can have problems at runtime while processing the messages. The same applies for the InternalConfiguration and IdPConfig entities.

Regards

Hi Telmo,

All finally sorted with your support, thank you!