SAML response Issuer ID Skip to main content
https://support.okta.com/help/answers?id=9062a000000qukdqac&refurl=http%3a%2f%2fsupport.okta.com%2fhelp%2fanswers
How satisfied are you with the Okta Help Center?
Thank you for your feedback!
How satisfied are you with the Okta Help Center?
1
2
3
4
5
Very Dissatisfied
Very satisfied
Enter content less than 200 characters.
Ask Search:
Benjamin EidelmanBenjamin Eidelman 

SAML response Issuer ID

I notice the SAMLResponses Okta POSTs to our app, always have the same Issuer (<saml2:Issuer ... ), regardless of which was the original IdP where the user authenticated.

Is there a way to figure out the original IdP from a SAMLResponse we receive?

we need to be able to distinguish which was the original IdP as our application supports multiple IdP associated to different users.

Darron HellmannDarron Hellmann (Okta)
Hi Ben

You should be able to determine the origin of an application by its metadata information or SAML response. An example is the entity or external ID...

Example:

Format="urn:oasis:names:tc:SAML:2.0:nameid <saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">http://www.okta.com/exki49o3i0Rih7VIO0x1</saml2:Issuer>

<saml2:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity" xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">http://www.okta.com/exki49o3i0Rih7VIO0x1</saml2:Issuer>
Benjamin EidelmanBenjamin Eidelman

I'm not trying to identify the application though. My Application supports multiple IdPs, because different users use different IdPs, for the same Application.

Okta proxies to all those IdPs, so to our app there's 1 SAML IdP, Okta's. That's very helpful because then we only need to verify signature against Okta's public certificate.
But we need to verify user (NameID) matches the original IdP (otherwise a rogue IdP could be lying about having a user that exists in another IdP).

Our app receives (in a POST) Okta's SAMLResponse that has Okta's Issuer ID (which is the same regardless of the user's used IdP), and nothing else in the SAMLResponse seems to allow identifying which was the original IdP where the user logged in.

For example, If there were a way for Okta to give us the original IdP Issuer (or any other Id we can set) in the RelayState (or any extra attribute in the SAML assertion we receive) it would be enough. Is there any way to ask Okta to forward us data from the original IdP SAMLResponse (like Issuer/IdP ID)?

Joe MocquantJoe Mocquant
Hi Ben,

Did you solve your problem? If so I am interested to know how as I am running exactly through the same issue.

Thanks,
Joe
Benjamin EidelmanBenjamin Eidelman
Hi Joe, we basically gave up on using Okta as a Service Provider proxy, it works fine as an Identity Provider (we kept Okta for this), but as an SP it was much simpler, faster, and flexible to use a library (there are SAML libraries to implement a SAML SP on any common tech stack you use).
Joe MocquantJoe Mocquant
Hi Ben, thanks for your quick reply. Did giving up on SP proxy really solve the issue? 

Let's say someone (one Okta customer) changes its profile attributes (the email for example) related to its identity on Okta IDP. Could he manage to do so in order to be authenticated on the SP as another user from a different organization? 

The Saml response would contain a valid assertion and if the new email value exist in the SP database, the access to the related account would be granted.

Did I miss something? Let me know, thanks!
Joe

 
Benjamin EidelmanBenjamin Eidelman
Yes, you described the problem. For us it was quick to notice that integrating with Okta as a proxy SAML SP, was almost the same (if not more) amount of work as being your own SAML SP. the things Okta was giving us, weren't really useful to us (eg. managing users data, mapping custom attributes), and we weren't very happy either with the okta transition page they put in front of customers on every login ) Being our own SP we gained the capability to receive the original auth response from our customers IdPs, which made this ticket a non issue. Okta was not telling us from which IdP the user came from (Okta will always say "this is coming from Okta"!), so a customer controlling her IdP could easily lie about his username to Okta and login as some other customer's user. Being our own SP, we can easily match the username against the issuer+certificate, verifying that the username belongs to the right customer in our db.
Joe MocquantJoe Mocquant
That's quite a big issue. Thanks for clarifying!