<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
System Status
Announcements
Announcements
Search
Search
Select Language
Knowledge Base
Knowledge Articles
Support Videos ↗
Documentation
Product Documentation ↗
Developer Documentation ↗
Product Release Notes ↗
Community
Events & Webinars
Okta Ideas ↗
Resources
Product Hub
Customer Success Hub
Product Release Update
Learning
Okta Learning ↗
Get Support
Open a Case
HomeCommunityForum
0D50Z00008G7UwbSAFOkta Classic EngineOkta Integration NetworkAnswered2019-11-22T23:27:33.000Z2016-11-18T14:29:30.000Z2018-03-19T07:53:16.000Z

MatthewW.31326 (Customer) asked a question.

November 18, 2016 at 2:29 PM
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.
  • 4 answers
  • 1.97K views

  • MatthewW.31326 (Customer)

    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.
    Expand Post

  • gabriel.sroka1.4374539321839353E12 (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.
    Expand Post

  • MatthewW.31326 (Customer)

    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).
    Expand Post
This question is closed.
Loading
Common SAML Entry Point