Configure Okta to Mediate between our SP Application and IdP

Question

We are a Service Provider who has SAML enabled our app to allow for IdPs to authenticate users for us. To make sure everyone is on the same page

• Identity Provider (IdP) is an application whose job it is to authenticate users
• Service Provider (SP) is an end application which federates identities and authentication to the IdP
• SAML is a protocol allowing IdPs to make trustworthy identity assertions to SPs. We are using SAML 2.0 (http://en.wikipedia.org/wiki/SAML_2.0)

More information on federated identity here: http://developer.okta.com/docs/guides/saml_guidance.html

We are currently only using Okta as an IdP, but have run into a situation where we need to integrate with a separate IdP. We would like to have our app only communicate with Okta and have Okta deal with talking to this separate IdP and validating their assertions. Due to our particular use case, our app knows what underlying IdP should be used, so no need for IdP Discovery.

We would like to configure Okta so that the authentication flow is as follows:

1. Our app redirects the user to an endpoint in Okta indicating to use the underlying IdP for authentication

2. Okta and the underlying IdP do whatever necessary to authenticate the user and validate the authentication

3. Our app gets a single response (via HTTP-POST) to our ACS endpoint authenticating the user, signed by Okta

From the end user perspective, they navigate to service-provider.com, are redirected through Okta to underlying-idp.com, perform the necessary authentication, and then are redirected back to service-provider.com. The end user is unaware of the middle Okta layer, with the possible exception of an Okta URL briefly appearing in the browser address bar during redirects.

So far, we have been able to set up Inbound SAML in our Okta instance so that users can be authenticated in Okta via the underlying IdP. We have our app redirect to the endpoint given in the Inbound SAML configuration page with the SAMLRequest, but this brings users to an Okta dashboard since the link is just for authenticating users in Okta, not to authenticate users for a SP using Okta. See our relevant configuration:

• Configuration for our app in Okta which allows us to use Okta as a direct IdP
• Configuration results of the Inbound SAML. We redirect our SAMLRequest to the Assertion Consumer Service URL given

How can we configure Okta so that our use case is possible? Ideally, we would like Okta to serve as a middleman or mediator, checking and passing along SAML requests/assertions. Specifically, we don’t need these users to be authenticated Okta users necessarily; we just need Okta to assert the user is who they say they are based on the underlying IdP’s assertion.

Suki

I have the same issue with being able to authenticate only to arrive in the Okta dashboard. Were you able to get an answer with this? Both Okta support and documentation have failed to explain how to do this. This seems like a common use-case (Inbound SAML authenticated and redirect to SP). – Podgy

Answer 1

Kinda sounds like you need the IdP Discovery capability that Okta has on the roadmap later this year combined with their inbound SAML setup with relationships with the other IdP. I believe it's possible to sort of implement this with a custom login page. They've mentioned doing this with professional services, but personally I'd feel a lot better about it when they've built IdP discovery into the platform.

Slimy

is it there yet? – Ezequieleziechiele

Answer 2

RelayState is a parameter of the SAML protocol that is used to identify the specific resource the user will access after they are signed in and directed to. Usually this is a landing page once authentication has been granted and used by the app to redirect the user to the right page.

Okta supports this flow using inbound SAML to link a downstream IDP to you flow. Okta performs user discover in the rule set you will need to configure on Okta. On the Okta IDP, created an SAML IDP Security-->Identity Providers and Add a SAML IDP. Provide the sign On URL of the downstream IDP. Then add a routing rule for the Okta IDP and filter on IP, or device, or application, or directory attribute or group to use the created IDP in Okta. Then on the downstream IDP, you must create a SAML app that will return the assertion to the SP end point. Okta doesn't support SAML deep links so you must pass the RelayState in the initial SAML Request so the downstream IDP can hand it back to the app which called the HTTP 302 redirect using its value.

Cigar