Inhaberbestätigungsmethoden für
SAML-Token-Profile
Mit der Authentifizierung über SAML-Token-Profile können Sie einen SAML-Inhaber mit der Inhaberbestätigungsmethode Sender-vouches bestätigen.
Diese Methode ermöglicht SSO für Web-Services, indem sie eine SAML-Assertion zur Weiterleitung der Authentifizierungsinformationen verwendet, die bei einer ursprünglichen Anmeldung erworben wurden.
Inhaberbestätigungsmethode Sender-vouches
Sie können die Bestätigungsmethode Sender-vouches für SSO-Szenarios verwenden, bei denen das zwischengeschaltete WS-System eine Vertrauensbeziehung zum Backend-System hat. Dieses Szenario definiert vier verschiedene Elemente: (1) einen Client, (2) ein zwischengeschaltetes System, (3) den SAML-Aussteller und (4) ein Backend-System als WS-Anbieter.
Einen Überblick über die Systeminteraktion dieses Szenarios zeigt die folgende Grafik:
Inhaberbestätigung Sender-vouches
Folgende Schritte beschreiben detailliert die Lebensdauer einer Anfrage, die das SAML-Profil Sender-vouches verwendet.
...
1. Der Client sendet eine Anfrage an das zwischengeschaltete System. Diese Anfrage kann beliebiger Art sein, muss aber gültige Authentifizierungsinformationen enthalten, damit sich der Client am zwischengeschalteten System anmelden kann.
2. Das zwischengeschaltete System authentifiziert den Client. Um die Anfrage zu verarbeiten, braucht das zwischengeschaltete System Informationen, die es vom Backend-System mit Web-Services-Mechanismen holt, die die Authentifizierungsdaten des Clients weiterleiten.
3. Um die Authentifizierung des Clients weiterzuleiten, muss das zwischengeschaltete System der Anfrage eine SAML-Assertion hinzufügen. Diese Assertion wird vom Aussteller bereitgestellt. Um sie zu erhalten, muss das zwischengeschaltete System alle notwendigen Anmeldedaten an den Aussteller weiterleiten, der wiederum die SAML-Assertion anlegt.
4. Die Assertion wird zur Web-Service-Anfrage hinzugefügt. Um für die Integrität der SAML-Assertion und der Nutzdaten/Payload der Web-Service-Anfrage zu bürgen, werden beide vom zwischengeschalteten System mit einer digitalen Signatur signiert. Das zwischengeschaltete System kann für die SAML-Assertion bürgen, da es zwischen dem Backend-System und dem zwischengeschalteten System eine explizite Vertrauensbeziehung gibt, die es dem Backend-System ermöglicht, die digitale Signatur zu verifizieren.
5. Die Web-Service-Anfrage, die die SAML-Assertion enthält, wird nun an das Backend-System gesandt.
6. Das Backend-System versucht, die SAML-Assertion zu verifizieren. Das Backend-System prüft neben der Korrektheit der SAML-Assertion auch, dass der Aussteller vertrauenswürdig ist und dass zwischen dem zwischengeschalteten und dem Backend-System eine Vertrauensbeziehung besteht. Nach erfolgreicher Verifizierung wird der Client am System angemeldet und die Anfrage verarbeitet.
7. Das Backend-System sendet eine Antwort an das zwischengeschaltete System. Das zwischengeschaltete System verwendet die erhaltenen Daten, um die Anfrage des Clients zu vervollständigen und eine Antwort an den Client zu senden.
Folgender Ausschnitt zeigt, wie ein Sicherheitsheader, der eine SAML-Assertion enthält, mit der Inhaberbestätigungsmethode Sender-vouches aussieht.
<wsse:Security> <saml:Assertion AssertionID="SAML_ID" Issuer="www.example.org" ...> <saml:Conditions NotBefore="..." NotOnOrAfter="..."/> <saml:AuthenticationStatement AuthenticationMethod="urn:...:password" AuthenticationInstant="2005-03-19T...Z" <saml:Subject> <saml:NameIdentifier>MUELLERTHOM2</saml:NameIdentifier> <saml:SubjectConfirmation> <saml:ConfirmationMethod> urn:oasis:names:tc:SAML:1.0:cm:sender-vouches </saml:ConfirmationMethod> </saml:SubjectConfirmation> </saml:Subject> </saml:AuthenticationStatement> </saml:Assertion> <wsse:SecurityTokenReference wsu:Id="STR1" ...> ... </wsse:SecurityToken..> <wsse:BinarySecurityToken ...> ... </wsse:BinarySecurityToken> <ds:Signature> <ds:SignedInfo> <ds:Reference URI="#STR1"> ... </ds:Reference> <ds:Reference URI="#body"> ... </ds:Reference> ... </ds:SignedInfo> </ds:Signature> </wsse:Security> |