So werden Sie SAML-Dienstleister

Mein Unternehmen entwickelt derzeit eine Java-Webanwendung. Einige unserer Kunden haben interne SAML-Server (Identitätsanbieter?) Und haben darum gebeten, dass wir uns in sie integrieren. Vor kurzem habe ich darüber gelesen und mit OpenAM herumgespielt. Nach ungefähr 3 Tagen habe ich ein allgemeines Verständnis davon, aber es gibt immer noch einige Lücken in meinem Wissen. Ich hoffe, dass jemand dies für mich klären kann.

So stelle ich mir den Workflow eines Benutzers vor, der sich anmeldet.

Definieren wir den SAML-Server unserer Kunden als https://their.samlserver.com . Ein Benutzer kommt also zu unserer Webanwendung, um eine geschützte Ressource zu erhalten. Angenommen, die URL lautet http://my.app.com/something .

Wenn ich richtig liege, definiert my.app.com SAML als Dienstanbieter . Unsere Anwendung erkennt, dass sich dieser Benutzer anmelden muss. Anschließend präsentieren wir dem Benutzer eine Seite wie diese ...

<script>JQuery Script to auto submit this form on ready</script>
<form method="post" action="https://their.samlserver.com/Post/Servlet">
    <input type="hidden" name="SAMLRequest" value="someBase64Data" />
    <input type="submit" value="Submit" />
</form>

Und das someBase64Datasollte eine base64verschlüsselte Version davon sein ...

<samlp:AuthnRequest
  xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
  xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
  ID="identifier_1"
  Version="2.0"
  IssueInstant="2004-12-05T09:21:59Z"
  AssertionConsumerServiceIndex="0">
 <saml:Issuer>http://my.app.com</saml:Issuer>
 <samlp:NameIDPolicy
   AllowCreate="true"
   Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"/>
</samlp:AuthnRequest>

Also meine ersten paar Fragen.

Was soll der ID- Wert sein?

Und warum kann ich mich als Emittent deklarieren ?

Kennt der Identitätsanbieter mich? Vielleicht ist dies der Vertrauenskreis, den ich bei OpenAM gesehen habe . Und wenn es über mich Bescheid weiß, woher weiß es über mich Bescheid und was muss es wissen?

Nachdem der Benutzer diese Seite weitergeleitet hat, wird er zu einer Seite weitergeleitet, die vom IDP https://their.samlserver.com bereitgestellt wird . Sie authentifizieren sich auf dieser Seite und der IDP macht es magisch, die Authentifizierung zu validieren und den Benutzer nachzuschlagen. Nach erfolgreicher Authentifizierung sendet der IDP eine hier<samlp:Response> definierte zurück .

Noch ein paar Fragen.

Wie <samlp:Response>komme ich zunächst zu meiner Webanwendung zurück, damit ich sie überprüfen kann?

Und worauf sollte ich in dieser Antwort achten, um zu bestätigen, dass sie erfolgreich war? Wie sieht ein Fehler aus?

Wir verwenden derzeit die E-Mail-Adresse (LDAP), um Benutzer zu identifizieren. Daher werden wir diese wahrscheinlich aus der Antwort entnehmen und sie auf die gleiche Weise wie jetzt verwenden. Was sollte ich bei dieser Antwort noch beachten?

Nachdem wir diese Antwort auf Gültigkeit überprüft haben, können wir dem Benutzer eine Sitzung gewähren, wie wir es derzeit tun. Aber wenn sie sich abmelden möchten, gibt es dafür einen Workflow? Muss ich den IDP benachrichtigen, dass der Benutzer gegangen ist?

Und schließlich gibt es ein paar Themen, die in meiner Lektüre herumgeworfen wurden, und ich bin mir nicht sicher, wie sie in diesen Workflow passen. Sie sind Vertrauenskreis , Token und Artefakte .

Vielen Dank für jede Hilfe an alle. Ich habe in den letzten Tagen viele Informationen gefunden, und es ist möglich, dass ich sie nach etwas mehr Spielen zusammenfügen kann. Ich habe jedoch noch keinen einfachen Workflow-Artikel zu "Here's the Post" gefunden. Vielleicht liegt das daran, dass ich falsch liege, wie das funktioniert. Vielleicht liegt es daran, dass dies nicht so beliebt ist. Aber ich wollte wirklich sicherstellen, dass ich den Workflow habe, damit ich keinen entscheidenden Schritt in etwas so Wichtigem wie der Benutzerauthentifizierung verpasse.

Als Antwort auf Ihre spezifischen Fragen:

1.) Was soll der "ID" -Wert sein?

• Dies sollte eine eindeutige Kennung für die SAML-Anforderung sein. Die SAML 2.0-Spezifikation besagt, dass dies wirklich implementierungsspezifisch ist, gibt jedoch die folgenden Empfehlungen ab:

Der Mechanismus, mit dem eine SAML-Systementität sicherstellt, dass die Kennung eindeutig ist, bleibt der Implementierung überlassen. In dem Fall, dass eine zufällige oder pseudozufällige Technik verwendet wird, MUSS die Wahrscheinlichkeit, dass zwei zufällig ausgewählte Identifikatoren identisch sind, kleiner oder gleich 2 ^ -128 sein und sollte kleiner oder gleich 2 ^ -160 sein. Diese Anforderung kann erfüllt werden, indem ein zufällig ausgewählter Wert zwischen 128 und 160 Bit Länge codiert wird.

2.) Woher weiß der IdP von Ihnen?

• Ihr SP muss beim IdP registriert sein. Um dies zu erreichen, definiert die SAML-Spezifikation ein Format für "SAML-Metadaten", das dem IdP mitteilt, wo sich Ihre SAML-Empfänger befinden, welche Zertifikate Sie haben, welche Attribute Sie austauschen usw. OpenAM schreibt wahrscheinlich einige Mindestanforderungen für die Konfiguration eines vertrauenswürdigen SP vor. Dies variiert in jedem Produkt.

3.) Wohin geht die Antwort und was ist zu überprüfen?

• Die Antwort wird an Ihre ACS-URL (Assertion Consumer Service) gesendet, die normalerweise in den SAML-Metadaten definiert ist, die Sie von Ihrem SP mit dem IdP für die Ersteinrichtung austauschen. Wenn Sie eine SAML-Antwort erhalten, müssen Sie viele Dinge überprüfen. Am wichtigsten ist jedoch, dass der SAML-Statuscode "Erfolg" lautet, die inResponseTo-IDs mit den gesendeten der Anforderung übereinstimmen und Sie die digitale Signatur in der Zusicherung validieren müssen. Dazu müssen Sie dem öffentlichen Verifizierungszertifikat des IdP vertrauen, und Sie möchten wahrscheinlich auch eine Sperrprüfung durchführen.

4.) Was ist mit Abmelden?

• SAML 2.0 definiert auch ein Profil für Single LogOut (SLO). Dadurch werden Sie nicht nur vom SP abgemeldet, sondern auch vom IdP und möglicherweise von allen anderen SPs, mit denen Sie eine Sitzung eingerichtet haben. Es hat einen ähnlichen Anforderungs- / Antwortfluss wie Single Sign-On (SSO) und daher ähnliche Dinge, die eingerichtet und überprüft werden müssen (Statuscodes, Signaturen usw.).

Kurz gesagt - die Implementierung von Grund auf kann recht komplex sein. Verwenden Sie am besten bewährte Bibliotheken und / oder Produkte, wie Ian vorschlägt. Unternehmen wie er haben Hunderte von Stunden Entwicklerzeit investiert, um gemäß den Spezifikationen zu implementieren und die Interoperabilität mit anderen Anbietern zu testen.

Wenn Sie nur versuchen, eine einzelne Java-Anwendung als Dienstanbieter einzurichten, sollten Sie ein Fedlet von Oracle (als Standalone) oder ForgeRock (im Lieferumfang von OpenAM enthalten) verwenden. Das ForgeRock Fedlet hat einige Probleme bei der Interaktion mit Shibboleth 2.2.1 als Identitätsanbieter, aber ich finde es etwas einfacher zu konfigurieren und informativer.

Jedes enthält explizite Anweisungen in der README-Datei, die Sie bei der Bereitstellung unterstützen. Sobald das Fedlet konfiguriert ist und mit dem IDP kommuniziert, wird auf der Erfolgsseite der gesamte Code angezeigt, den Sie zur Integration von Verbund-SSO in Ihre Anwendung benötigen. Es erledigt die Hintergrundarbeit des Sendens und Empfangens von AuthnRequests und Antworten.

Scotts Antwort reagiert recht gut auf die Fragen, die Sie hatten, aber ich denke, dass der Versuch, selbst Code zu schreiben, der die SAML generiert, das Rad neu erfindet. Das Fedlet wurde genau für diesen Anwendungsfall entwickelt.