Security Assertion Markup Language
Die Security Assertion Markup Language (kurz SAML) ist ein XML-Framework mit dessen Hilfe Geschäftspartner online sicherheitsbezogene Informationen über eine Entität, unter anderem Authentisierungs- und Autorisierungsinformationen, sicher austauschen können. SAML wurde 2001 vom OASIS-Konsortium verabschiedet und liegt mittlerweile in der Version 2.0 vor. Bei der Entwicklung wurde dem Web Single Sign-On besondere Bedeutung geschenkt.
Motivation
Mit Hilfe von Web Single Sign-On kann ein Benutzer, der bei einem Onlinedienst angemeldet ist, seine schon vorhandene Session weiternutzen, wenn er die Seite eines Vertragspartners des Dienstes besucht. Er muss sich also nicht neu authentifizieren, um das Angebot nutzen zu können. Dafür wird bei SAML eine dritte Instanz, eine sogenannte Asserting Party eingeführt, dem die beiden Dienstanbieter, in SAML auch Relying Party genannt, vertrauen. Dieser übernimmt an deren Stelle die Authentifizierung des Benutzers und stellt eine Assertion aus, mit welcher die Relying Partys den Benutzer identifizieren können.
Bestandteile
Der SAML-Standard besteht aus zahlreichen einzelnen Dokumenten, welche sich gegenseitig ergänzen. Hinzu kommt eine Vielzahl an proprietären Erweiterungen verschiedener Identitätssysteme, die einzelne Unzulänglichkeiten des Standards bereinigen zu versuchen. Die wichtigsten Bestandteile von SAML sind:
- Assertions -- Diese bestehen aus Aussagen über ein Subjekt, welches eine Person aber auch ein Rechner sein kann. Sie können Informationen über den Authentifizierungsvorgang, die Zugriffsrechte und Attribute des Subjekts enthalten, aber auch nur aus einer Fehlermeldung bestehen.
- Protokolle -- Protokolle bestimmen die Reihenfolge in der Nachrichten übertragen werden. Für die Authentifizierung eines Benutzers wird das Authentication Request Protokoll genutzt. Desweiteren gibt es unter anderem das Assertion Query and Request Protokoll, mit dem bei einer Asserting Party weitere Informationen über eine schon bestehende Session, zum Beispiel weitere Attribute des Benutzers, abgefragt werden können.
- Bindings -- Diese legen fest wie SAML (request oder response) Nachrichten über ein Transportprotokoll übertragen werden. Gab es in SAML 1.0 nur das SOAP-Binding, so werden im 2.0 Standard zusätzlich unter anderem HTTP-Post, HTTP-Redirect oder PAOS unterstützt.
- Profile -- Profile haben in SAML zwei Bedeutungen. Zum einen sagen sie aus wie Assertions, Protokolle und Bindings für einen bestimmten Anwendungsfall kombiniert werden sollen. Desweiteren legen sogenannte "`Attribute Profile"' fest, wie SAML Attribute in andere Systeme eingebunden werden.
Für das Web SSO Szenario existieren unter anderem das Web Browser SSO und das Enhanced Client or Proxy (ECP) Profil, wobei beim zweiteren ein zusätzliches Programm an Stelle des Browsers für die Authentifizierung genutzt wird.
SAML Identity Federation
Um den Begriff Identity Federation erklären zu können, eignet es sich, die einzelnen Bestandteile des Begriffes zu erklären. In SAML besteht eine Identität aus den Attributen, die benötigt werden, um eine Entität (zum Beispiel einen Benutzer) eindeutig zu identifizieren.
Der Begriff Federation hat in SAML zwei Bedeutungen (vgl. SAML Glossary):
- (1)
- Der Vorgang um zwei Entitäten miteinander zu verknüpfen
- (2)
- Eine Verbindung zwischen verschiedenen Service Providern und Identity Providern.
Bei einem Service Provider handelt es sich um eine Entität, welche einem Benutzer bestimmte Dienste anbietet. Eine spezielle Art Service Provider stellt der Identity Provider dar. Dieser stellt bestimmten Service Providern innerhalb einer Federation Identitätsinformationen eines Benutzers zu Verfügung, wofür er den Benutzer meistens authentifiziert. Wichtig ist hierbei das Vertrauen, das die SP und der IdP zueinaner haben müssen. Zum einen müssen die Service Provider auf die Korrektheit der vom IdP erhaltenen Daten vertrauen. SAML kann hierbei mit XML-Sig nur sicherstellen, dass die Daten bei der Übertragung nicht verändert wurden, das Vertrauen in den Authentifizierungsvorgang des IdP muss jedoch vertraglich hergestellt werden. Zum anderen besteht meistens auch ein Vertrauen des IdP in die SP, dass diese die erhaltenen Daten nicht an Dritte weitergeben. Somit kann es geschehen, dass aus vertraglichen Gründen ein SP nicht als Identity Provider für weitere SP dienen darf, obwohl dies technisch mit SAML möglich wäre. Alles in allem ist Identity Federation als Vorgang, bei dem eine Federated Identity, eine zwischen verschiedenen Providern verknüpfte Identität, entsteht, ein eher schwer zu fassender Begriff, der unter technischen und rechtlichen Aspekten betrachtet werden sollte.
Proxying
Der Proxy Mechanismus wird in SAML Core beschrieben. Ist ein Identity Provider nicht in der Lage einen Nutzer zu authentifizieren, kann er unter bestimmten Umständen selber einen eigenen AuthnRequest an einen weiteren IdP senden. Dessen Antwort kann er wiederum dazu verwenden, eine eigene SAMLResponse zu generieren. Durch setzen bestimmter Optionen kann der Aussteller eines AuthnRequest Einfluss auf den Proxy Mechanismus nehmen. So bestimmt der Wert in ProxyCount die maximale Proxytiefe und das IDPList Element enthält zusätzlich eine Liste an bevorzugten IdPs. Des Weiteren existieren noch einige Vorschriften, die der Proxy bei der Erstellung seiner Antwort beachten muss. So muss unter anderem das Subject Element den Anforderungen der originalen Anfrage genügen, auch muss dem Anfragenden mitgeteilt werden, welcher Server im Endeffekt den Benutzer authentifiziert hat. Wichtig dabei ist, dass es sich hierbei um Verabeitungsvorschriften handelt, bei denen die beteiligten Instanzen darauf vertrauen müssen, dass sich die betroffenen Identity Provider daran halten. Auch wird die Abarbeitung nicht genau im Standard festgeschrieben, weswegen diese vorher vertraglich festgelegt werden muss.