<iframe src="https://www.googletagmanager.com/ns.html?id=GTM-M74D8PB" height="0" width="0" style="display:none;visibility:hidden">
Loading
Skip to NavigationSkip to Main Content
0D50Z00008G7V7iSAFOkta Classic EngineOkta Integration NetworkAnswered2024-04-16T12:39:19.000Z2017-12-27T20:29:52.000Z2018-08-02T14:57:10.000Z
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.


  • 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>
    Expand Post
  • 8steb (8steb)

    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)?

    Expand Post
  • j6ncy (j6ncy)

    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
    Expand Post
  • 8steb (8steb)

    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).
  • j6ncy (j6ncy)

    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

     

    Expand Post
  • 8steb (8steb)

    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.
    Expand Post
  • j6ncy (j6ncy)

    That's quite a big issue. Thanks for clarifying!
This question is closed.
Loading
SAML response Issuer ID