2016-02-05 9 views
5

Wir sind ein Service Provider, der SAML aktiviert hat, damit unsere IdPs Benutzer für uns authentifizieren können. Zu machen, ist sicher, dass jeder auf der gleichen SeiteKonfigurieren von Okta zum Vermitteln zwischen unserer SP-Anwendung und IdP

  • Identity Provider (IdP) ist eine Anwendung, deren Aufgabe es ist, um Benutzer zu authentifizieren
  • Service Provider (SP) ist eine End-Anwendung, die Identitäten und die Authentifizierung der IdP Föderaten
  • SAML ist ein Protokoll, mit dem IdPs vertrauenswürdige Identitätsbestätigungen für SPs erstellen können. Wir verwenden SAML 2,0 (http://en.wikipedia.org/wiki/SAML_2.0)

Mehr Informationen über föderierte Identität hier: http://developer.okta.com/docs/guides/saml_guidance.html

Wir sind derzeit nur Okta als IdP verwenden, sondern in eine Situation kommen, wo wir mit einem separaten integrieren müssen IdP. Wir möchten, dass unsere App nur mit Okta kommuniziert und Okta sich damit beschäftigt, mit diesem separaten IdP zu sprechen und ihre Behauptungen zu bestätigen. Aufgrund unseres speziellen Anwendungsfalls weiß unsere App, welcher zugrunde liegende IdP verwendet werden sollte, sodass keine IdP-Erkennung erforderlich ist.

Wir möchten Okta so konfigurieren, dass der Authentifizierungsablauf wie folgt:

  1. Unsere App leitet den Benutzer an einen Endpunkt in Okta, die den zugrunde liegenden IdP für die Authentifizierung verwenden

  2. Okta und die zugrunde liegende IdP tun alles, was notwendig ist, um den Benutzer zu authentifizieren und die Authentifizierung zu validieren

  3. Unsere App erhält eine einzige Antwort (via HTTP-POST) zu unserem ACS Endpunkt Authentifizierung des Benutzers, unterzeichnet von Okta

Aus der Sicht des Endbenutzers, wechseln sie service-provider.com, werden durch Okta zu underlying-idp.com umgeleitet, führen die notwendige Authentifizierung und werden zurück zum Service-Provider weitergeleitet dann .com. Der Endbenutzer ist sich der mittleren Okta-Ebene nicht bewusst, mit der möglichen Ausnahme einer Okta-URL, die während Umleitungen kurz in der Adressleiste des Browsers angezeigt wird.

Bisher konnten wir Inbound SAML in unserer Okta-Instanz einrichten, sodass Benutzer in Okta über das zugrunde liegende IdP authentifiziert werden können. Wir leiten unsere App zu dem Endpunkt weiter, der auf der SAMLRequest-Seite für die eingehende SAML-Konfiguration angegeben ist. Dies führt jedoch zu einem Okta-Dashboard, da der Link nur zur Authentifizierung von Benutzern in Okta dient und Benutzer nicht für einen SP mit Okta authentifiziert werden. Siehe unsere relevante Konfiguration:

Wie können wir Okta so konfigurieren, dass unser Anwendungsfall möglich ist? Idealerweise möchten wir, dass Okta als Vermittler oder Vermittler fungiert und SAML Anfragen/Behauptungen prüft und weitergibt. Insbesondere brauchen wir diese Benutzer nicht, um Okta-Benutzer authentifiziert zu werden; Wir brauchen nur Okta, um zu bestätigen, dass der Benutzer derjenige ist, von dem sie sagen, dass er auf der Behauptung des zugrundeliegenden IdP basiert.

+0

Ich habe das gleiche Problem mit der Authentifizierung nur im Okta Dashboard ankommen. Konntest du damit eine Antwort bekommen? Sowohl die Okta-Unterstützung als auch die Dokumentation konnten nicht erklären, wie dies zu tun ist. Dies scheint ein häufiger Anwendungsfall zu sein (eingehende SAML-Authentifizierung und Weiterleitung an SP). – Theo

Antwort

1

Irgendwie hört sich an, als ob Sie die IdP Discovery-Funktion benötigen, die Okta in diesem Jahr zusammen mit dem SAML-Setup für eingehende Verbindungen mit den anderen IdPs auf der Roadmap hat. Ich glaube, dass es möglich ist, dies mit einer benutzerdefinierten Anmeldeseite zu implementieren. Sie haben erwähnt, dies mit professionellen Diensten zu tun, aber persönlich würde ich mich viel besser fühlen, wenn sie IdP-Erkennung in die Plattform eingebaut haben.

+0

ist es schon da? – pinkpanther

Verwandte Themen