SAML Assertion mit Benutzername/Passwort - wie sehen die Nachrichten wirklich aus?

Question

Ich muss einige SAML 2.0 Assertions erstellen, und ich habe Probleme zu finden, wie das XML wirklich aussehen sollte. Die meiste Dokumentation scheint über die Verwendung bestimmter Tools zu handeln, nicht über die Nachrichten. Ich habe die Schemata mit einer Fülle von Möglichkeiten, aber ich kann kein Beispiel dafür finden, wie die relevanten Botschaften tatsächlich in der Praxis aussehen. Die Geschäftsregel besagt: Um eine gemeinsame Identität zu erzeugen, teilt der Benutzer dem System A seinen Benutzernamen und sein Passwort auf System B mit. System A muss diese Informationen (zusammen mit einigen demografischen Daten) an System B übermitteln. System B validiert die Information und gibt eine eindeutige Kennung zurück, die dann verwendet werden kann, um sich auf diesen Benutzer zu beziehen.

Könnte mir jemand ein Beispiel dafür geben, wie SAML 2.0-Behauptungen aussehen würden, um diese Informationen zu tragen?

FWIW, ich benutze C# und muss das XML auf eine Weise weitergeben, die die Verwendung eines Drittanbieter-Tools ausschließt.

Answer 1

Ich bin mir nicht sicher, ob Ihr Anwendungsfall ist was SAML 2.0 tut.

Was Sie als Geschäftsregeln beschreiben, sieht tatsächlich wie ein Anwendungsfall für die Identitätsbereitstellung aus, nicht für die Zugriffsverwaltung.

Standard SAML 2.0 Use Cases konzentrieren sich auf eine Partei, die Identität (den Identitätsprovider) behauptet, und die andere Partei (oder Parteien), die sich auf diese Behauptungen stützt (der Dienstanbieter). Behauptungen tragen eine so genannte Namenskennung, deren Verwendung im Voraus zwischen dem Identitätsanbieter und dem Dienstanbieter vereinbart wird.

Diese Namen Bezeichner können so ziemlich alles sein, aber sie fallen weitgehend in zwei Kategorien: transient und persistent. Ein flüchtiger Namensbezeichner ist nur im Zusammenhang mit der aktuellen Sitzung nützlich (und sagt im Wesentlichen nur "Ich weiß, wer diese Person ist") und wird dazu verwendet, die Identität des Prinzipals zu schützen, während er einen privilegierten Zugriff von irgendeinem Typ erlaubt. Ein persistenter Identifikator kann entweder opak sein (ähnlich wie OpenID für den Zugriff auf SO verwendet wird), wo der durchführende Teilnehmer die Identität eines Prinzips wiederholt verifizieren kann, ohne seine Identität offen zu legen, während er einen dynamischen, aber stabilen geteilten Identifizierer zwischen den geltend machenden und vertrauenden Parteien aufrechterhält B. ein Active Directory-UPN (das vorab vereinbart werden kann).

Wenn es um Passwörter geht, wie Sie in Ihrer Frage angeben, sieht der Dienstanbieter (vertrauende Seite) niemals das Kennwort des Benutzers. Der Dienstanbieter übergibt den Benutzer mit einer Authentifizierungsanforderung an den Identitätsanbieter. Der Identity-Provider sendet den Benutzer mit einer Antwort an den Service-Provider zurück, die im Falle einer erfolgreichen Authentifizierung eine Aussage über die Identität des Benutzers im Kontext der Beziehung zwischen dem Identity-Provider und dem Service-Provider enthält.

Im Zusammenhang mit Ihrer Frage ist die große Sache, dass SAML 2.0 keine Möglichkeit bietet, entweder das lokale Benutzerkonto "Anwendung" zu erstellen oder dieses lokale Benutzerkonto mit einer föderierten Identität zu verknüpfen. Dies ist einfach nicht das Problem, das SAML 2.0 zu lösen versucht.

Jetzt zurück zu Ihren Geschäftsregeln ...

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

• Nutzer besucht Anwendung, auf eine Schaltfläche klickt Identität von den Identity-Provider zu verwenden,
• Die Anwendung erzeugt eine Authentifizierungsanforderung und leitet den Benutzer an den Identitätsanbieter, der diese Authentifizierungsanforderung trägt.
• Der Identitätsanbieter meldet sich entweder an oder verwendet eine vorhandene Identitätssitzung erneut, wenn der Benutzer über eine solche verfügt. Der IdP erzeugt eine Antwortnachricht, die eine Assertion über den Benutzer enthält. In Ihrem Fall sollte diese Behauptung mindestens eine persistente Namenskennung tragen. Der Identity-Provider leitet den Benutzer mit der Antwortnachricht zurück zur Anwendung.
• Die Anwendung verarbeitet die Antwortnachricht. Wenn ein Mapping-Eintrag für den übergebenen persistenten Bezeichner existiert, wird der Benutzer von diesem Mapping erkannt und als lokaler Benutzer der Anwendung angemeldet. Wenn kein Zuordnungseintrag vorhanden ist, kann der Benutzer aufgefordert werden, sich lokal anzumelden, und bei erfolgreicher lokaler Anmeldung kann der Zuordnungseintrag erstellt werden oder ein Benutzerkonto kann automatisch erstellt werden und der Benutzer könnte aufgefordert werden, zusätzliche Informationen (Namen, E-Mail-Adressen) einzugeben usw.) Der Anwendungsfall "Unternehmen" wäre, dass keine automatische Kontenverknüpfung oder -erstellung erlaubt ist und dass die Zuordnung im Voraus bestehen muss.

Was den Inhalt der Nachrichten ...

Die OASIS Security Services Technical Committee hat eine Download-ZIP-Datei zur Verfügung mit umfangreicher Dokumentation der Teile des XML-Schemas, einschließlich Beispiele. Es lohnt sich auch, die Protokoll- und Profildokumentation zu lesen, da diese den Nachrichtenfluss zwischen den an der Identitätskonversation beteiligten Parteien beschreiben.

Es gibt eine große Anzahl von Präsentationen, die sich als sehr nützlich erweisen. Genauer gesagt, SAML v2.0 Basics von Eve Maler half mir zu erkennen, welche Probleme SAML v2.0 zu lösen versuchte. Diese Präsentation enthält Beispiele für diese Behauptungen. Es gibt eine aktualisierte Präsentation und Links zu zusätzlichen Ressourcen unter saml.xml.org.

Ich bin nicht sicher, ob etwas davon helfen wird, da Ihr Anwendungsfall nicht das zu sein scheint, was SAML 2.0 versucht. Sie können nach Bedarf Attribute und Erweiterungen zu Anforderungen und Antworten hinzufügen, aber ich kann nicht viele Identitätsanbieter sehen, die irgendetwas mit diesen Attributen und Antworten tun.