GregK.54397 (Customer) asked a question.
We're attempting to implement a solution in which the following occurs:
- External IdP sends a SAMLResponse to an Okta Idp. this SamlResponse contains a custom attribute (let's call it "foo")
- foo is mapped to an attribute on the IdPUser profile also named foo
- IdpUser.foo is mapped to an attribute on the OktaUser profile, also named foo.
- OktaUser.foo is mapped to an attribute on a SAMLApp Userprofile, called foo.
- the SAMLApp includes SAMLApp.foo in the SAML it generates SAMLResponse as a custom attribute name foo.
- The end service provider receives the SAMLResponse from Okta and can access the value of the foo attribute
This allows our external IdPs to send a custom attribute to our end service provider, through Okta.
We've been able to get this to work, but not consistently.
Although the Idp-to-OktaUser mapping seems to complete, the OktaUser-to-SAMLApp mapping does not, so the custom attributes are not included in the app's SAMLResponse.
I believe this is because profile mappings are an asynchronous process in Okta, and sometimes the SAMLApp generates the SAMLResponse before the SAMLApp user profile has been updated.
1 - Can any folks here confirm that profile mapping is indeed an synchronous process and may be a factor in the inconsistency that we're seeing?
2 - Have any folks here successfully accomplished what we're trying to do - pulling a custom attribute our of a SAML payload and passing it on down to the end service provider?
Thanks!
Hi @GregK.54397 (Customer) , Thank you for reaching out to the Okta Community!
Assuming I've understood your use case correctly... If the downstream SAML app is not Provisioning enabled (i.e. canned app from the catalogue with inbuilt Provisioning API or a custom SCIM implementation), the Okta > SAML_App profile mapping does not matter. The attribute flow is done via the app's SAML settings custom Attribute Statements.
If you already have the IDP to Okta part down and the Okta User Profile is populated with the desired values from the IDP, you will need to set up the desired attributes in the apps SAML settings as mentioned in this article.
This should push the values to the downstream app each time the user logs into the app via SAML assertion.
If my answer helped, remember to mark it as best to increase its visibility for other members of the Okta Community who might have the same questions as you.
Hope my answer helps!
--
Help others in the community by liking or hitting Select as Best if this response helped you.
Level up your Identity security superpowers with Okta Learning.
Join the Online Discussion for Ask me Anything on March 25, 2025: Identity Threat Protection with Okta AI
hey thanks for the reply, Mihai!
We do have the attribute mapping set up in the SAML Apps SAML settings.
This end-to-end flow does work. ... just not all the time.
That's where my question lies. It seems like Okta is routing the request to through the SAMLApp before the attribute mapping has had time to percolate to the SamlApp User profile.
So the SAML sent out by the App does not include the latest values.
I'm trying to confirm whether the attribute mapping is done asynchronously in Okta. If it is, then it seems there can never be a guarantee that the the SAML mapping will happen in time for the request to pick up the changes.
@GregK.54397 (Customer) That shouldn't be the case. I recommend checking with the Support team to see you can follow the trail of events via Okta System Logs and maybe some SAML traces. But if this can't be reproduced at will it might prove difficult.
Either way, the Support team be able to access additional tools and resources to help you get to the bottom of it.
Regards.
--
Help others in the community by liking or hitting Select as Best if this response helped you.
Level up your Identity security superpowers with Okta Learning.
Join the Online Discussion for Ask me Anything on March 25, 2025: Identity Threat Protection with Okta AI
Figured it couldn’t hurt to post in the Community as well.
Yup. We'll definitely leave this question open for Community input in case someone else encountered the same problem.
Regards.
--
Help others in the community by liking or hitting Select as Best if this response helped you.
Level up your Identity security superpowers with Okta Learning.
Join the Online Discussion for Ask me Anything on March 25, 2025: Identity Threat Protection with Okta AI
hi @GregK.54397 (Customer)
Are you doing SAML JIT and simultaneously launching the SAML app to your end provider (in the same session)?
Also can you provide some details/info on how you are launching the SAML app (eg add user to group via group rules which is authorized access to app etc)
That will be helpful
Also if you pass on any of the following attributes (username, lastname, firstname in SAMLApp profile mapping) are they always available?
Thank you
-Bala
The IdP is configured for SAML JIT, but the user in question already exists, so should only be receiving updates to profile properties.
The SAML app is being launched by passing the appropriate RelayState query string parameter on the request that the external IdP is posting to the Okta ACS URL. After Idp authentication, Okta redirects to the SAML App, which in turn generates a SAML Response to send to the Service Provider.
Basic attributes (like first/last/login) do seem to always be available.
It's the custom attributes defined on our custom User Type profile that are jittery.
Also attempted mapping attributes directly from user.xxxxx to the custom SAML attributes in the SAMLApp. This works for basic profile attributes, but never works for custom profile attributes.
@GregK.54397 (Customer) . Thanks for the info and since you have opened a support ticket, we will let engineering/support comment. I would suggest that you include this info in the ticket (if its not already done). Thank you