yrawz (yrawz) asked a question.
Hello,
I have successfully configured a few inbound SSO connections to our Okta account, but I am unable to configure one for a client now, who is sending the email address as an attribute in their saml assertion, but NOT as the Subject NameId.
We only use email addresses as usernames in our Okta Org, so it does not matter what I select for the "Match Against" field. It will always be an email.
The data the client is providing in the assertion's NameId attribute cannot be reliably transformed to an email because they do not enforce strict conventions with their email addresses or domains.
I'd like to be able to just set the IdP Username in the client's IdP Configuration to something like "idpuser.email" which the field allows, but then I get these errors in the logs:
Authenticate user via IDP
failure : Unknown Profile Attribute
Authenticate user via IDP
failure : Unable to transform email to username
I assume I must have errors in my mappings for the IdP profile, but I've tried every configuration I can find online or think of. I have tried the friendly names, the names the organization itself uses, and creating attributes that match the names sent in the assertion (example below).
<saml:Attribute Name={I used this value as the external name value when creating this attribute for the idp}
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml:AttributeValue xsi:type="xs:string">{Okta displays this value as the "unknown profile attribute in that error"}</saml:AttributeValue>
</saml:Attribute>
I can't find any documentation that elaborates on how to take a Saml assertion and map it (in the okta expression language) properly. How do I properly map attributes from a saml assertion so that Okta will recognize them.
I have no information whatsoever about why I'm getting "Unable to transform email to username" error. Is it seriously impossible to tell Okta to look at a different saml assertion attribute besides NameId?
Thanks for contacting Okta, My name is Emmanuel and I'll be assisting you with this case.
In order to properly match the attribute that is being passed via SAML it would be beneficial to see the full unmodified assertion so we can understand how to map the attribute and potentially utilize RegEx to deal with any un-expectancies such as formatting.
Please have a look at the following article, it discusses how to create IDP as well as a link to the Okta Expression language.
https://developer.okta.com/docs/guides/add-an-external-idp/saml2/configure-idp-in-okta/
If you feel that you need further assistance, please open a ticket with support so that we can better track this issue and troubleshooting further.
Thanks,
Emmanuel
Hello Emmanuel,
Thank you for your quick response.
Attached is a full assertion (with redactions for certain values as necessary) sent from one of the test IdP's I have configured in our okta staging environment. I had all of the same described problems/questions with this IdP as I had with the client described in my original post.
Thank you!