Common SAML Entry Point Skip to main content
https://support.okta.com/help/answers?id=9062a000000bmbwqay&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:
Matthew WhiteMatthew White 

Common SAML Entry Point

I'm developing an identity and access management middleware for my company. All of the identity providers we support will funnel through this middleman, which all the backend applications can talk to. On our home page, we want to provide buttons that quickly allow our customers to log in using their own identity provider. With Azure AD, we had to use the "common" OAuth endpoint to allow Azure AD to negotiate which instance the user belongs to. Now that I'm trying to implement Okta, I see no mention anywhere of a "common" entry point for the SAML request. Instead, the entry point I'm using is tied to my developer instance of Okta, which is unaccesible to anyone but me. Is there such an entry point available? I can't find any mention of it on my application's configuration nor in the documentation and samples provided.
Gabriel SrokaGabriel Sroka (Okta, Inc.)
Hi Matthew
If I'm understanding correctly, you want Okta to use Inbound SAML (to act as an SP and receive an assertion), If so, please see:
https://support.okta.com/help/articles/Knowledge_Article/40561903-Configuring-Inbound-SAML
If that's not it, can you please explain the flow a little more?

Thanks.
Matthew WhiteMatthew White
Actually, just the opposite. The flow looks something like this:
  1. A user (unknown identity, unknown tenant) comes to our home page and clicks the button to sign in with Okta
  2. The application triggers a SAML request and redirects the user to Okta
  3. Okta determines the tenant the user belongs to (which is the Okta instance) and authenticates the user
  4. Okta returns a SAML assertion to the application with the identity of the user and Okta instance
I'm having trouble with parts 2/3. Currently, I'm redirecting the user to my Okta instance directly for them to sign in. Instead, what I need is a "common" Okta entry point that can direct the user to the appropriate instance for authentication. We want our customers to be able to use their own Okta instance directly.
Gabriel SrokaGabriel Sroka (Okta, Inc.)
Hi Matthew
I think I get it now. in #3 there are multiple Okta instances? In this case, you need "IdP discovery". One way to do this:
1. a user goes to your home page and you ask them which Okta instance is going to authenticate them. You could show a drop-down, or ask for an email address and look at the suffix
2. you then send the user to the correct IdP
I don't think this something Okta can do directly, your code would have to decide.
Matthew WhiteMatthew White
Yes, Gabriel, that's exactly it. Are you sure this is something that Okta can't support directly? The SAML response includes a field for the instance ID, which would allow for this easily. As I mentioned before, we've already implemented Azure AD with our product, and although there's a bit more configuration required on our side (we have to enable the application as "multi-tenant"), we can use a common endpoint that handles instance negotiation for us (so that a user, if already logged in, for example, wouldn't have to additionally select their Azure instance--which we would have to do with Okta if we follow your steps).