Federation-Technologien im Detail

Spezifische Sicherheitsanforderungen

Wie eingangs ausgeführt, resultieren aus der Arbeitsweise von Web Services und damit auch der darauf basierenden Federation einige spezifische Sicherheitsanforderungen. Im Detail sind das die folgenden im Standard spezifizierten Festlegungen:

  • Es wird unbedingt empfohlen, dass die Kommunikation zwischen Diensten über WS-Security gesichert wird. Sowohl der Body als auch die Header der Nachrichten sollten in die Signatur eingeschlossen werden.

  • Alle Nachrichten im Zusammenhang mit de Federation wie das Sign-Out oder der Austausch von Attributen sollten signiert werden. Nicht signierte Nachrichten sollten nicht verarbeitet werden.

  • Alle Sign-Out-Anforderungen müssen signiert sein.

  • Alle Nachrichten sollten vom STS signiert werden. Nicht von diesem signierte Nachrichten sollten nicht verarbeitet werden.

  • Der Attribute Service sollte besonders geschützt sein, da er besonders sensible Informationen verarbeitet.

  • Gleiches gilt für den Pseudonym Service. Die Informationen insbesondere zu Kennwörtern sollten sowohl bei der Übertragung als auch im Speicher verschlüsselt sein.

  • Falls ein Security-Token nicht ohnehin verschlüsselt ist, sollte es nur in Nachrichten übertragen werden, die die Sicherheit und Integrität gewährleisten.

Die Konsequenz aus diesen Anforderungen ist, dass ein Minimum an Zertifikatsdiensten für den Aufbau von Federation-Beziehungen zwingend erforderlich ist. Das wird deutlich, wenn man sich – wie im folgenden Artikel – die genaue Arbeitsweise der ADFS betrachtet. WS-Security muss genutzt werden, um die Federation-Beziehungen abzusichern. In der Konsequenz müssen für den Aufbau einer Federation-Beziehung neben WSFederation auch WS-Security, WS-Trust und WSPolicy konfiguriert werden.

Passive Requestor Profile

Das Passive Requestor Profile ist das Verfahren, das bei der Authentifizierung von Systemen angewendet wird, die nicht direkt Web Services unterstützen und damit auch nicht direkt über die auf SOAP basierenden Federation-Nachrichten arbeiten können. Es handelt sich um Systeme, die HTTP 1.1 verwenden, also insbesondere Webbrowser.

Das Konzept der Zugriffe ist in Bild 4 illustriert. Der Zugriff auf eine Ressource erfolgt über HTTP. Das System, das die Ressource bereitstellt, antwortet mit einer Authentifizierungsanforderung, die nun vom Identity Provider des Requestors bearbeitet werden muss. Das ausgestellte Security-Token mit ergänzenden Informationen wie den Claims wird an die Ressource übergeben, die nach erfolgreicher Authentifizierung die Ergebnisse der Anforderung zurückliefert.

Nicht sichtbar sind in Bild 4 die zusätzlich erforderlichen Schritte, die für den Aufbau des Trusts erforderlich sind. Es wird vorausgesetzt, dass die Vertrauensstellung zu diesem Zeitpunkt bereits besteht und die Ressource damit das Security-Token akzeptiert.

Bild 4: Das Konzept der Authentifizierung an einem Web Service (Quelle: Microsoft).
Bild 4: Das Konzept der Authentifizierung an einem Web Service (Quelle: Microsoft).

In praktisch identischer Weise werden auch Sign-Out-Anforderungen verarbeitet, bei denen allerdings die Ressource das Sign-Out beim Identity Provider anfordert.

In vielen Situationen sind im Rahmen der Federation zusätzliche Attribute erforderlich. Das Verfahren für die Anforderung solcher Attribute ist in Bild 5 illustriert. Hier geht die Anforderung an den Client, der wiederum (implizit) mit dem Identity Provider und dessen Attribute Service zusammenarbeitet. Die Verarbeitung von Pseudonymen erfolgt praktisch identisch.

Bild 5: Die Verarbeitung zusätzlicher Attributanforderungen (Quelle: Microsoft).
Bild 5: Die Verarbeitung zusätzlicher Attributanforderungen (Quelle: Microsoft).

Damit nicht bei jeder Anforderung erneut der Zugriff auf den Identity Provider erforderlich ist, kann mit Artefakten oder Cookies gearbeitet werden. Artefakte beschreiben einen Requestor innerhalb einer Kommunikationsbeziehung und sind innerhalb des Passive Requestor Profiles als Cookies implementiert.