SAML-Assertion mit Benutzername / Passwort - was die Nachrichten wirklich aussehen?

Question

Ich brauche ein paar SAML 2.0 Behauptungen zu schaffen, und ich habe Probleme zu finden, was die XML wirklich aussehen soll. Der größte Teil der Dokumentation scheint über die Verwendung von speziellen Werkzeugen, die nicht über die Nachrichten zu sein. Ich habe die Schemata bekommt, mit einer Fülle von Möglichkeiten, aber ich kann nicht ein Beispiel dafür, was die relevanten Nachrichten tatsächlich aussehen wie in der Praxis finden.

Die Geschäftsregel sagt: um eine gemeinsame Identität zu schaffen, das Benutzersystem A sagt ihr Benutzername und Passwort auf System B System A benötigen diese Informationen zu kommunizieren (zusammen mit einiger Demografie) mit dem System B System B die validiert Informationen und übergibt eine eindeutige Kennung zurück, die dann verwendet werden kann, um diesen Benutzer zu beziehen.

Könnte jemand geben Sie mir ein Beispiel dafür, was SAML 2.0 Behauptungen diese Informationen tragen würde so aussehen?

FWIW, ich bin mit C #, und muß die XML um in einer Weise zu übergeben, die ein 3rd-Party-Tool preclude verwendet wird.

Answer 1

Ich bin mir nicht sicher, dass Ihr Anwendungsfall ist recht, was SAML 2.0 der Fall ist.

Was Sie beschreiben, wie Sie Ihre Geschäftsregeln sieht tatsächlich wie ein Anwendungsfall für Identity Provisioning, nicht-Management zugreifen.

Standard SAML 2.0 Anwendungsfälle konzentrieren sich auf eine Partei behauptet Identität (der Identity-Provider) und der anderen Partei (oder Parteien) unter Berufung auf diese Behauptungen (der Dienstanbieter). Assertions tragen, was einen Namen Kennung genannt wird, deren Benutzung vor der Zeit zwischen dem Identitätsanbieter vereinbart und dem Diensteanbieter.

Diese Namenskennungen können so ziemlich alles sein, aber sie können grob in zwei Kategorien: transient und persistent. Eine vorübergehende Namenskennung ist nur sinnvoll, im Rahmen der aktuellen Sitzung (und im Wesentlichen nur sagt: „Ich weiß, wer diese Person ist“) und neigt dazu verwendet werden, um die Identität des Auftraggebers zu schützen und gleichzeitig ein privilegierten Zugang irgendeine Art erlaubt. Ein Persistent Identifier kann entweder undurchsichtig sein (in ähnlicher Weise wie OpenID verwendete SO zuzugreifen), wo die Behauptung Partei immer wieder ein Prinzips der Identität, ohne ihre Identität offenbart, während eine dynamische, aber stabile gemeinsame Kennung zwischen dem Geltendmachung Aufrechterhaltung und vertrauenden Parteien überprüfen kann, oder wesentlichere, wie ein Active Directory-UPN (die vor der Zeit im voraus vereinbart werden können).

Wenn es um Passwörter geht, wie Sie in Ihrer Frage erwähnt, sieht der Service-Provider (vertrauende) nie die Benutzer-Passwort. Die Service-Provider übergeben den Benutzer über die Identität Anbieter mit einer Authentifizierungsanforderung. Die Identity-Provider senden den Benutzer zurück zum Service-Provider mit einer Antwort, die im Fall einer erfolgreichen Authentifizierung eine Aussage über die Identität des Benutzers im Kontext der Beziehung zwischen dem Identity-Provider und Service-Provider enthält.

Im Rahmen Ihrer Frage, die große Sache ist, dass SAML 2.0 bietet keine Möglichkeit, entweder das lokale „Anwendung“ Benutzerkonto oder einen Link, dass die lokalen Benutzerkonto zu einer föderierten Identität zu erstellen. Das ist einfach nicht das Problem SAML 2.0 versucht zu lösen.

Nun, zurück in Ihre Geschäftsregeln ...

Es scheint mir, wie das, was Sie versuchen, entweder Konto verknüpfen oder Registrierung zu tun - ich es so nähern würde:

• Benutzer Besuche Anwendung, auf eine Schaltfläche klickt Identität vom Identity-Provider zu verwenden,
• Die Anwendung erzeugt eine Authentifizierungsanforderung und leitet den Benutzer an den Identitätsanbieter, dass die Authentifizierungsanfrage trägt
• Die Identity-Provider entweder Protokolle in dem Benutzer oder wieder verwenden eine vorhandene Identität Sitzung, wenn der Benutzer einen hat. Die IdP erzeugt eine Antwortnachricht, eine Aussage über den Benutzer enthält. In Ihrem Fall bei mindestens diese Behauptung eine persistente Namenskennung tragen soll. Der Identitätsanbieter leitet die Anwendung den Benutzer zurück, die Antwortnachricht tragen.
• Die Anwendung verarbeitet die Antwortnachricht. Wenn ein Mapping-Eintrag für den Persistent Identifier existiert übergeben die Benutzer von dieser Zuordnung und angemeldet wie die lokale Anwendung Benutzer erkannt wird. Wenn kein Mapping-Eintrag vorhanden ist, kann der Benutzer lokal anmelden in gefragt werden, und auf erfolgreiche lokale Login kann der Mapping-Eintrag erzeugt werden, oder ein Benutzerkonto automatisch erstellt werden kann und der Benutzer aufgefordert werden könnte, um zusätzliche Informationen (Name eingeben, E-Mail-Adressen Verwendung, etc.) der „Corporate“ Fall wäre, dass kein automatisches Konto verknüpfen oder Schöpfung ist erlaubt und dass die Zuordnung muss vor der Zeit existieren.

Wie für den Inhalt der Nachrichten ...

Die OASIS Security Services Technical Committee eine Zip-Datei hat Download mit umfangreicher Dokumentation der Teile des XML-Schemas, einschließlich Beispiele. Es ist auch gut lohnt sich, das Protokoll und Profil Dokumentation zu lesen, da diese den Fluss der Nachrichten beschreiben zwischendie Parteien in der Identität Gespräch beteiligt.

Es gibt eine große Anzahl von Präsentationen im Umlauf, dass ich sehr nützlich erwiesen. Insbesondere SAML v2.0 Basics von Eve Maler half mir beginnen zu realisieren, was SAML Probleme v2.0 zu lösen versuchte. Diese Präsentation enthält Beispiele für die Behauptungen aussehen. Es ist eine aktualisierte Präsentation und Links zu weiteren Ressourcen auf saml.xml.org .

Ich bin mir nicht sicher, ob irgendetwas davon wird allerdings helfen, wie die Nutzung Fall zu sein scheint nicht, was SAML 2.0 zu tun versucht. Sie können Attribute und Erweiterungen hinzufügen, um auf Anfragen und Antworten benötigt, aber ich kann nicht viele Identity-Provider etwas zu tun mit diesen Attributen und Antworten sehen.