SAML - Revision history

Mminor at 11:59, 12 April 2010

2010-04-12T11:59:58Z

← Older revision		Revision as of 11:59, 12 April 2010
Line 6:		Line 6:
	Viele Firmen bieten Single Sign-On Lösungen an. Problematisch ist dabei aber, dass die Sicherheitseigenschaften der auftretenden Interaktionen nicht standardisiert sind und somit jedes Produkt unterschiedlich stark geschützt ist. Des weiteren sind solche Lösungen üblicherweise nicht interoperabel, so dass die Wahl des Produkts eine Einschränkung bei der Wahl von Service und Identity Providern darstellt. Bei SAML sind hingegen Mindestanforderungen bezüglich der Sicherheit für verschiedene Transaktionstypen definiert sowie Interoperabilität durch eine standardisierte Dokumentenstruktur garantiert.		Viele Firmen bieten Single Sign-On Lösungen an. Problematisch ist dabei aber, dass die Sicherheitseigenschaften der auftretenden Interaktionen nicht standardisiert sind und somit jedes Produkt unterschiedlich stark geschützt ist. Des weiteren sind solche Lösungen üblicherweise nicht interoperabel, so dass die Wahl des Produkts eine Einschränkung bei der Wahl von Service und Identity Providern darstellt. Bei SAML sind hingegen Mindestanforderungen bezüglich der Sicherheit für verschiedene Transaktionstypen definiert sowie Interoperabilität durch eine standardisierte Dokumentenstruktur garantiert.

	== ~~Konzepte~~ ==		== Komponenten ==
	SAML besteht aus mehreren aufeinander aufbauenden Komponenten. Diese erlauben, wenn zusammengesetzt, eine Vielzahl von Anwendungsfällen. SAML Assertions beinhalten Aussagen einer Partei über ein Subjekt. Beispielsweise könnte eine Assertion aussagen, dass das Subjekt John Doe heißt und die E-Mail Adresse john.doe@example.com hat. Solche Assertions werden meist nur basierend auf einer Anfrage erstellt, können aber unter bestimmten Umständen auch initial an den Empfänger gesendet werden. Es gibt drei verschiedene Statements: Authentication, Attribute, Authorization Decision Statement. Die SAML Protokolle definieren Anfragen und Antworten einer korrekten Kommunikation mithilfe von SAML-Werkzeugen. Es gibt sechs verschiedene SAML-Protokolle, dazu gehört das Authentication Request Protocol, welches Anwendung im Web Single Sign-On Fall findet. Weitere wichtige Protokolle sind das Artifact Resolution Protocol und das Single Logout Protocol. Durch SAML-Bindings wird der Transport der Nachrichten selbst organisiert, beispielsweise HTTP oder SOAP. Es werden von SAML 6 Bindings definiert. Profile haben bei SAML zwei Bedeutungen. Zum einen versteht man darunter eine Kombination beziehungsweise Einschränkung der zugrunde liegenden Komponenten für einen bestimmten Anwendungsfall. Dazu gehören 5 Single Sign-On und drei einzelne Profile. Zum anderen versteht man unter einem SAML Profil einen definierten Satz von Regeln zur Abbildung von Attributen aus andern Systemen. Beispielsweise wie Attribute aus einem LDAP-System in einer SAML-Assertion als Attribut abgebildet werden können.		SAML besteht aus mehreren aufeinander aufbauenden Komponenten. Diese erlauben, wenn zusammengesetzt, eine Vielzahl von Anwendungsfällen. SAML Assertions beinhalten Aussagen einer Partei über ein Subjekt. Beispielsweise könnte eine Assertion aussagen, dass das Subjekt John Doe heißt und die E-Mail Adresse john.doe@example.com hat. Solche Assertions werden meist nur basierend auf einer Anfrage erstellt, können aber unter bestimmten Umständen auch initial an den Empfänger gesendet werden. Es gibt drei verschiedene Statements: Authentication, Attribute, Authorization Decision Statement. Die SAML Protokolle definieren Anfragen und Antworten einer korrekten Kommunikation mithilfe von SAML-Werkzeugen. Es gibt sechs verschiedene SAML-Protokolle, dazu gehört das Authentication Request Protocol, welches Anwendung im Web Single Sign-On Fall findet. Weitere wichtige Protokolle sind das Artifact Resolution Protocol und das Single Logout Protocol. Durch SAML-Bindings wird der Transport der Nachrichten selbst organisiert, beispielsweise HTTP oder SOAP. Es werden von SAML 6 Bindings definiert. Profile haben bei SAML zwei Bedeutungen. Zum einen versteht man darunter eine Kombination beziehungsweise Einschränkung der zugrunde liegenden Komponenten für einen bestimmten Anwendungsfall. Dazu gehören 5 Single Sign-On und drei einzelne Profile. Zum anderen versteht man unter einem SAML Profil einen definierten Satz von Regeln zur Abbildung von Attributen aus andern Systemen. Beispielsweise wie Attribute aus einem LDAP-System in einer SAML-Assertion als Attribut abgebildet werden können.

Mminor at 11:58, 12 April 2010

2010-04-12T11:58:16Z

← Older revision		Revision as of 11:58, 12 April 2010
Line 101:		Line 101:
	Die Anfälligkeit während des Transports bezüglich Belauschens, Veränderns oder eines Man-in-the-Middle Angriffs unterscheidet sich hinsichtlich des verwendeten Bindings. Die Definition für SOAP ist besonders schwach und enthält hierzu keinerlei Vorschriften. Die Verwendung von HTTP over TLS/SSL, möglicherweise mit beidseitigen Zertifikaten, schließt diese Schwachpunkte aber in allen Bindings weitestgehend aus.		Die Anfälligkeit während des Transports bezüglich Belauschens, Veränderns oder eines Man-in-the-Middle Angriffs unterscheidet sich hinsichtlich des verwendeten Bindings. Die Definition für SOAP ist besonders schwach und enthält hierzu keinerlei Vorschriften. Die Verwendung von HTTP over TLS/SSL, möglicherweise mit beidseitigen Zertifikaten, schließt diese Schwachpunkte aber in allen Bindings weitestgehend aus.

	== Quellen ~~und weiterführende Links~~ ==		== Quellen ==
	*[http://www.oasis-open.org/committees/download.php/27819/sstc-saml-tech-overview-2.0-cd-02.pdf SAML Technical Overview]		*[http://www.oasis-open.org/committees/download.php/27819/sstc-saml-tech-overview-2.0-cd-02.pdf SAML Technical Overview]
	*[http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf SAML Assertions and Protocols]		*[http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf SAML Assertions and Protocols]

Mminor at 11:55, 12 April 2010

2010-04-12T11:55:38Z

← Older revision		Revision as of 11:55, 12 April 2010
Line 74:		Line 74:

	Attributsinformationen fallen häufig als Beiprodukt eines Single-Sign-On Vorgangs an oder werden auf explizite Nachfrage bestimmter Attribute übermittelt. SAML Attribute Statements haben den dargestellten Aufbau. Sie können ein oder mehrere Attribute enthalten. Im Beispiel enthält das Attribute Statement drei Attribute beginnend auf Zeile 2, 10 und 16. Alle Attributnamen haben ein Format. Im ersten Fall wird das SAML X.500/LDAP Profile genutzt. Das LDAP Attribut, welches durch OID 2.5.4.42 identifiziert wird, heißt givenName und der Attributwert ist John. Beim zweiten Attribut wird das SAML Basic Attribute Profile genutzt. Das Attribut heißt LastName und enthält den Wert Doe. Das dritte Attribut hat ein Format, das nicht von SAML definiert ist, sondern von SmithCo. Das CreditLimit des Benutzers ist 500 USD. Die Werte der Attribute können einfache Datentypen sein, wie in den ersten beiden Fällen, oder weiter strukturiertes XML wie im dritten Fall.		Attributsinformationen fallen häufig als Beiprodukt eines Single-Sign-On Vorgangs an oder werden auf explizite Nachfrage bestimmter Attribute übermittelt. SAML Attribute Statements haben den dargestellten Aufbau. Sie können ein oder mehrere Attribute enthalten. Im Beispiel enthält das Attribute Statement drei Attribute beginnend auf Zeile 2, 10 und 16. Alle Attributnamen haben ein Format. Im ersten Fall wird das SAML X.500/LDAP Profile genutzt. Das LDAP Attribut, welches durch OID 2.5.4.42 identifiziert wird, heißt givenName und der Attributwert ist John. Beim zweiten Attribut wird das SAML Basic Attribute Profile genutzt. Das Attribut heißt LastName und enthält den Wert Doe. Das dritte Attribut hat ein Format, das nicht von SAML definiert ist, sondern von SmithCo. Das CreditLimit des Benutzers ist 500 USD. Die Werte der Attribute können einfache Datentypen sein, wie in den ersten beiden Fällen, oder weiter strukturiertes XML wie im dritten Fall.

			== Ablauf ==
			Im folgenden Beispiel wird das HTTP Redirect Binding zur Übertragung der Authentifikationsanfrage genutzt, sowie das HTTP POST Binding um die SAML Antwort zu verschicken.

			1) Der Benutzer versucht auf die Ressource des Service Providers zuzugreifen. Er besitzt keine gültige Logon Session und der aktuelle Zustand wird gespeichert.

			2) Der Service Provider sendet einen HTTP Redirect (302 oder 303) an den Browser des Benutzers. Der Header enthält als Ziel den Single Sign-On Service des Identity Providers und zwei query Variablen. Eine davon ist RelayState, welche den lokalen Zustand oder eine Referenz darauf enthält. Die andere ist ein SAMLRequest, welcher einen deflate komprimierten Authentication Request enthält.

			3) Vom Identity Provider wird überprüft, ob bereits ein lokaler Sicherheitskontext besteht, welcher die geforderte Authentisierungspolicy erfüllt. Wenn nicht, wird der Benutzer nach Login Daten gefragt.

			4) Der Benutzer führt den Login aus.

			5) Der Identity Provider erstellt eine SAML Assertion, die den aktuellen Sicherheitskontext des Benutzers repräsentiert. Die Assertion wird signiert und in eine SAML Response eingebettet. Diese wird base64 komprimiert und in ein HTML FORM als hidden form control names SAMLResponse eingebettet. Der RelayState wird als zweites control Element eingebettet.

			6) Der Browser führt jetzt eine HTTP POST Anfrage aus mit den entsprechenden in Schritt 5 generierten Daten. Der Service Provider extrahiert den Response Teil und validiert die Signatur der SAML Assertion. Als nächstes wird der Inahlt abgearbeitet und ein lokaler Sicherheitskontext für den Benutzer erstellt. Anschließend wird noch der lokale Zustand, gespeichert in RelayState, wiederhergestellt.

			7) Sollte der Benutzer berechtigt sein die Ressource aufzurufen, wird sie übertragen.

	== Datenschutz und Sicherheit ==		== Datenschutz und Sicherheit ==

Mminor: /* Datenschutz und Sicherheit */

2010-04-12T11:40:05Z

Datenschutz und Sicherheit

← Older revision		Revision as of 11:40, 12 April 2010
Line 82:		Line 82:
	Gegenmaßnahmen beinhalten eine Authentisierung auf einem niedrigeren Level beispielsweise mit HTTP over TLS/SSL und Klient seitigen Zertifikaten mit einer vertrauenswürdigen Zertifikats-Autorität. Eine Zurückverfolgung wäre bereits jetzt möglich. Fügt man noch eine Zugangskontrolle hinzu sind DOS-Attacken nur noch von Insidern möglich. Wird eine signierte Anfrage verlangt, reduziert sich dadurch die Asymmetrie zwischen der Arbeit die vom Nachfragenden und Antwortenden erledigt werden. Während nämlich die Verifikation der Signatur nur einen geringen Teil der Arbeit, die vom Antwortenden erledigt wird, entspricht, stellt sie einen sehr großen Anteil an der zu erledigenden Arbeit des Anfrage-Stellers.		Gegenmaßnahmen beinhalten eine Authentisierung auf einem niedrigeren Level beispielsweise mit HTTP over TLS/SSL und Klient seitigen Zertifikaten mit einer vertrauenswürdigen Zertifikats-Autorität. Eine Zurückverfolgung wäre bereits jetzt möglich. Fügt man noch eine Zugangskontrolle hinzu sind DOS-Attacken nur noch von Insidern möglich. Wird eine signierte Anfrage verlangt, reduziert sich dadurch die Asymmetrie zwischen der Arbeit die vom Nachfragenden und Antwortenden erledigt werden. Während nämlich die Verifikation der Signatur nur einen geringen Teil der Arbeit, die vom Antwortenden erledigt wird, entspricht, stellt sie einen sehr großen Anteil an der zu erledigenden Arbeit des Anfrage-Stellers.

	Die Anfälligkeit während des Transports bezüglich Belauschens, Veränderns oder eines Man-in-the-Middle Angriffs unterscheidet sich hinsichtlich des verwendeten Bindings. Die Definition für SOAP ist besonders schwach und enthält hierzu keinerlei Vorschriften. ~~Durch~~ Verwendung von HTTP over TLS/SSL, möglicherweise mit beidseitigen Zertifikaten, schließt diese Schwachpunkte aber in allen Bindings weitestgehend aus.		Die Anfälligkeit während des Transports bezüglich Belauschens, Veränderns oder eines Man-in-the-Middle Angriffs unterscheidet sich hinsichtlich des verwendeten Bindings. Die Definition für SOAP ist besonders schwach und enthält hierzu keinerlei Vorschriften. Die Verwendung von HTTP over TLS/SSL, möglicherweise mit beidseitigen Zertifikaten, schließt diese Schwachpunkte aber in allen Bindings weitestgehend aus.

	== Quellen und weiterführende Links ==		== Quellen und weiterführende Links ==

Mminor at 11:37, 12 April 2010

2010-04-12T11:37:11Z

← Older revision		Revision as of 11:37, 12 April 2010
Line 2:		Line 2:

	== Motivation ==		== Motivation ==
	Multi-Domain Web Single Sign-On ist einer der wichtigsten Anwendungsfälle von SAML. Dabei hat der Benutzer eine Login Session, das heißt einen Sicherheitskontext, bei seinem Identity Provider. Dazu muss dieser ein lokales Authentifizierungssystem bereitstellen. Um den Dienst eines Service Providers in Anspruch zu nehmen, ist bei diesem ~~ein~~ Authentifizierung notwendig. Ebenso ist bei jedem weiteren Service Provider eine erneute und völlig unabhängige Authentifizierung ~~notwendig~~. ~~SAML~~ erlaubt es nun dem Benutzer sich einmal bei seinem Identity Provider zu authentifizieren und jede folgende Authentifizierung beim Service Provider durch den Identity Provider vornehmen zu lassen.		Multi-Domain Web Single Sign-On ist einer der wichtigsten Anwendungsfälle von SAML. Dabei hat der Benutzer eine Login Session, das heißt einen Sicherheitskontext, bei seinem Identity Provider. Dazu muss dieser ein lokales Authentifizierungssystem bereitstellen. Um den Dienst eines Service Providers in Anspruch zu nehmen, ist bei diesem üblicherweise eine Authentifizierung notwendig. Ebenso ist bei jedem weiteren Service Provider eine erneute und völlig unabhängige Authentifizierung von Nöten. Das Konzept des Single Sign-On erlaubt es nun dem Benutzer sich einmal bei seinem Identity Provider zu authentifizieren und jede folgende Authentifizierung beim Service Provider durch den Identity Provider vornehmen zu lassen.

	Viele Firmen bieten Single Sign-On Lösungen an. Problematisch ist dabei aber, dass die Sicherheitseigenschaften der auftretenden Interaktionen nicht standardisiert sind und somit jedes Produkt unterschiedlich stark geschützt ist. Des weiteren sind solche Lösungen üblicherweise nicht interoperabel, so dass die Wahl des Produkts eine Einschränkung bei der Wahl von Service und Identity Providern darstellt. Bei SAML sind hingegen Mindestanforderungen bezüglich der Sicherheit für verschiedene Transaktionstypen definiert sowie Interoperabilität durch eine standardisierte Dokumentenstruktur garantiert.		Viele Firmen bieten Single Sign-On Lösungen an. Problematisch ist dabei aber, dass die Sicherheitseigenschaften der auftretenden Interaktionen nicht standardisiert sind und somit jedes Produkt unterschiedlich stark geschützt ist. Des weiteren sind solche Lösungen üblicherweise nicht interoperabel, so dass die Wahl des Produkts eine Einschränkung bei der Wahl von Service und Identity Providern darstellt. Bei SAML sind hingegen Mindestanforderungen bezüglich der Sicherheit für verschiedene Transaktionstypen definiert sowie Interoperabilität durch eine standardisierte Dokumentenstruktur garantiert.

Mminor at 11:33, 12 April 2010

2010-04-12T11:33:34Z

← Older revision		Revision as of 11:33, 12 April 2010
Line 1:		Line 1:
	SAML, die Security Assertion Markup Language, ist ein von OASIS standardisiertes XML-Framework zum Austausch von Sicherheitsinformationen. Es wird eine Dokumentenstruktur für Sicherheitsinformationen definiert, die die Interaktionen zwischen verschiedenen unabhängigen Services erlaubt. Dabei werden Sicherheitsbehauptungen, so genannte assertions benutzt. Teil des Standards sind weiterhin eine Anzahl von Request/Response-Protokollen für unterschiedliche Anwendungsfälle.		SAML, die Security Assertion Markup Language, ist ein von OASIS standardisiertes XML-Framework zum Austausch von Sicherheitsinformationen. Es wird eine Dokumentenstruktur für Sicherheitsinformationen definiert, die die Interaktionen zwischen verschiedenen unabhängigen Services erlaubt. Dabei werden Sicherheitsbehauptungen, so genannte assertions benutzt. Teil des Standards sind weiterhin eine Anzahl von Request/Response-Protokollen für unterschiedliche Anwendungsfälle.

	== ~~Warum SAML?~~ ==		== Motivation ==
	Multi-Domain Web Single Sign-On ist einer der wichtigsten Anwendungsfälle von SAML. Dabei hat der Benutzer eine Login Session, das heißt einen Sicherheitskontext, bei seinem Identity Provider. Dazu muss dieser ein lokales Authentifizierungssystem bereitstellen. Um den Dienst eines Service Providers in Anspruch zu nehmen, ist bei diesem ein Authentifizierung notwendig. Ebenso ist bei jedem weiteren Service Provider eine erneute und völlig unabhängige Authentifizierung notwendig. SAML erlaubt es nun dem Benutzer sich einmal bei seinem Identity Provider zu authentifizieren und jede folgende Authentifizierung beim Service Provider durch den Identity Provider vornehmen zu lassen.		Multi-Domain Web Single Sign-On ist einer der wichtigsten Anwendungsfälle von SAML. Dabei hat der Benutzer eine Login Session, das heißt einen Sicherheitskontext, bei seinem Identity Provider. Dazu muss dieser ein lokales Authentifizierungssystem bereitstellen. Um den Dienst eines Service Providers in Anspruch zu nehmen, ist bei diesem ein Authentifizierung notwendig. Ebenso ist bei jedem weiteren Service Provider eine erneute und völlig unabhängige Authentifizierung notwendig. SAML erlaubt es nun dem Benutzer sich einmal bei seinem Identity Provider zu authentifizieren und jede folgende Authentifizierung beim Service Provider durch den Identity Provider vornehmen zu lassen.

Mminor: /* Warum SAML? */

2010-04-12T11:32:45Z

Warum SAML?

← Older revision		Revision as of 11:32, 12 April 2010
Line 4:		Line 4:
	Multi-Domain Web Single Sign-On ist einer der wichtigsten Anwendungsfälle von SAML. Dabei hat der Benutzer eine Login Session, das heißt einen Sicherheitskontext, bei seinem Identity Provider. Dazu muss dieser ein lokales Authentifizierungssystem bereitstellen. Um den Dienst eines Service Providers in Anspruch zu nehmen, ist bei diesem ein Authentifizierung notwendig. Ebenso ist bei jedem weiteren Service Provider eine erneute und völlig unabhängige Authentifizierung notwendig. SAML erlaubt es nun dem Benutzer sich einmal bei seinem Identity Provider zu authentifizieren und jede folgende Authentifizierung beim Service Provider durch den Identity Provider vornehmen zu lassen.		Multi-Domain Web Single Sign-On ist einer der wichtigsten Anwendungsfälle von SAML. Dabei hat der Benutzer eine Login Session, das heißt einen Sicherheitskontext, bei seinem Identity Provider. Dazu muss dieser ein lokales Authentifizierungssystem bereitstellen. Um den Dienst eines Service Providers in Anspruch zu nehmen, ist bei diesem ein Authentifizierung notwendig. Ebenso ist bei jedem weiteren Service Provider eine erneute und völlig unabhängige Authentifizierung notwendig. SAML erlaubt es nun dem Benutzer sich einmal bei seinem Identity Provider zu authentifizieren und jede folgende Authentifizierung beim Service Provider durch den Identity Provider vornehmen zu lassen.

	Viele Firmen bieten Single Sign-On Lösungen an. Problematisch ist dabei aber, dass die Sicherheitseigenschaften der auftretenden Interaktionen nicht standardisiert sind und somit jedes Produkt unterschiedlich stark geschützt ist. Des weiteren sind solche Lösungen üblicherweise nicht interoperabel, so dass die Wahl des Produkts eine Einschränkung bei Wahl von Service und Identity Providern darstellt. Bei SAML sind hingegen Mindestanforderungen bezüglich der Sicherheit für verschiedene Transaktionstypen definiert sowie Interoperabilität durch eine standardisierte Dokumentenstruktur garantiert.		Viele Firmen bieten Single Sign-On Lösungen an. Problematisch ist dabei aber, dass die Sicherheitseigenschaften der auftretenden Interaktionen nicht standardisiert sind und somit jedes Produkt unterschiedlich stark geschützt ist. Des weiteren sind solche Lösungen üblicherweise nicht interoperabel, so dass die Wahl des Produkts eine Einschränkung bei der Wahl von Service und Identity Providern darstellt. Bei SAML sind hingegen Mindestanforderungen bezüglich der Sicherheit für verschiedene Transaktionstypen definiert sowie Interoperabilität durch eine standardisierte Dokumentenstruktur garantiert.

	== Konzepte ==		== Konzepte ==

Mminor: /* Datenschutz und Sicherheit */

2010-04-12T11:23:25Z

Datenschutz und Sicherheit

← Older revision		Revision as of 11:23, 12 April 2010
Line 82:		Line 82:
	Gegenmaßnahmen beinhalten eine Authentisierung auf einem niedrigeren Level beispielsweise mit HTTP over TLS/SSL und Klient seitigen Zertifikaten mit einer vertrauenswürdigen Zertifikats-Autorität. Eine Zurückverfolgung wäre bereits jetzt möglich. Fügt man noch eine Zugangskontrolle hinzu sind DOS-Attacken nur noch von Insidern möglich. Wird eine signierte Anfrage verlangt, reduziert sich dadurch die Asymmetrie zwischen der Arbeit die vom Nachfragenden und Antwortenden erledigt werden. Während nämlich die Verifikation der Signatur nur einen geringen Teil der Arbeit, die vom Antwortenden erledigt wird, entspricht, stellt sie einen sehr großen Anteil an der zu erledigenden Arbeit des Anfrage-Stellers.		Gegenmaßnahmen beinhalten eine Authentisierung auf einem niedrigeren Level beispielsweise mit HTTP over TLS/SSL und Klient seitigen Zertifikaten mit einer vertrauenswürdigen Zertifikats-Autorität. Eine Zurückverfolgung wäre bereits jetzt möglich. Fügt man noch eine Zugangskontrolle hinzu sind DOS-Attacken nur noch von Insidern möglich. Wird eine signierte Anfrage verlangt, reduziert sich dadurch die Asymmetrie zwischen der Arbeit die vom Nachfragenden und Antwortenden erledigt werden. Während nämlich die Verifikation der Signatur nur einen geringen Teil der Arbeit, die vom Antwortenden erledigt wird, entspricht, stellt sie einen sehr großen Anteil an der zu erledigenden Arbeit des Anfrage-Stellers.

	Die Anfälligkeit während des Transports bezüglich Belauschens, Veränderns oder ~~einen~~ Man-in-the-Middle Angriffs unterscheidet sich hinsichtlich des verwendeten Bindings. Die Definition für SOAP ist besonders schwach und enthält hierzu keinerlei Vorschriften. Durch Verwendung von HTTP over TLS/SSL, möglicherweise mit beidseitigen Zertifikaten, schließt diese Schwachpunkte aber in allen Bindings weitestgehend aus.		Die Anfälligkeit während des Transports bezüglich Belauschens, Veränderns oder eines Man-in-the-Middle Angriffs unterscheidet sich hinsichtlich des verwendeten Bindings. Die Definition für SOAP ist besonders schwach und enthält hierzu keinerlei Vorschriften. Durch Verwendung von HTTP over TLS/SSL, möglicherweise mit beidseitigen Zertifikaten, schließt diese Schwachpunkte aber in allen Bindings weitestgehend aus.

	== Quellen und weiterführende Links ==		== Quellen und weiterführende Links ==

Mminor at 11:20, 12 April 2010

2010-04-12T11:20:20Z

@@ Line 1: / Line 1: @@
 == Konzepte ==
-SAML besteht aus mehreren aufeinander aufbauenden Komponenten. Diese erlauben, wenn zusammengesetzt, eine Vielzahl von Anwendungsfällen. SAML Assertions beinhalten Aussagen einer Partei über ein Subjekt. Beispielsweise könnte eine Assertion aussagen, dass das Subjekt John Doe heißt und die E-Mail Adresse john.doe@example.com hat. Solche Assertions werden meist nur basierend auf einer Anfrage erstellt, können aber unter bestimmten Umständen auch initial an den Empfänger gesendet werden. Es gibt drei verschiedene Statements: Authentication, Attribute, Authorization Decision Statement. Die SAML Protokolle definieren Anfragen und Antworten einer korrekten Kommunikation mithilfe von SAML-Werkzeugen. Es gibt sechs verschiedene SAML-Protokolle, dazu gehört das Authentication Request Protocol, welches Anwendung im Web Single Sign-On Fall findet. Weiter wichtige Protokolle sind das Artifact Resolution Protocol und das Single Logout Protocol. Durch SAML-Bindings wird der Transport der Nachrichten selbst organisiert, beispielsweise HTTP oder SOAP. Es werden von SAML 6 Bindings definiert. Profile haben bei SAML zwei Bedeutungen. Zum einen versteht man darunter eine Kombination beziehungsweise Einschränkung der zugrunde liegenden Komponenten für einen bestimmten Anwendungsfall. Dazu gehören 5 Single Sign-On und drei einzelne Profile. Zum anderen versteht man unter einem SAML Profil einen definierten Satz von Regeln zur Abbildung von Attributen aus andern Systemen. Beispielsweise wie Attribute aus einem LDAP-System in einer SAML-Assertion als Attribut abgebildet werden können.
+SAML besteht aus mehreren aufeinander aufbauenden Komponenten. Diese erlauben, wenn zusammengesetzt, eine Vielzahl von Anwendungsfällen. SAML Assertions beinhalten Aussagen einer Partei über ein Subjekt. Beispielsweise könnte eine Assertion aussagen, dass das Subjekt John Doe heißt und die E-Mail Adresse john.doe@example.com hat. Solche Assertions werden meist nur basierend auf einer Anfrage erstellt, können aber unter bestimmten Umständen auch initial an den Empfänger gesendet werden. Es gibt drei verschiedene Statements: Authentication, Attribute, Authorization Decision Statement. Die SAML Protokolle definieren Anfragen und Antworten einer korrekten Kommunikation mithilfe von SAML-Werkzeugen. Es gibt sechs verschiedene SAML-Protokolle, dazu gehört das Authentication Request Protocol, welches Anwendung im Web Single Sign-On Fall findet. Weitere wichtige Protokolle sind das Artifact Resolution Protocol und das Single Logout Protocol. Durch SAML-Bindings wird der Transport der Nachrichten selbst organisiert, beispielsweise HTTP oder SOAP. Es werden von SAML 6 Bindings definiert. Profile haben bei SAML zwei Bedeutungen. Zum einen versteht man darunter eine Kombination beziehungsweise Einschränkung der zugrunde liegenden Komponenten für einen bestimmten Anwendungsfall. Dazu gehören 5 Single Sign-On und drei einzelne Profile. Zum anderen versteht man unter einem SAML Profil einen definierten Satz von Regeln zur Abbildung von Attributen aus andern Systemen. Beispielsweise wie Attribute aus einem LDAP-System in einer SAML-Assertion als Attribut abgebildet werden können.
 == SAML-Assertion ==
@@ Line 69: / Line 74: @@
 Attributsinformationen fallen häufig als Beiprodukt eines Single-Sign-On Vorgangs an oder werden auf explizite Nachfrage bestimmter Attribute übermittelt. SAML Attribute Statements haben den dargestellten Aufbau. Sie können ein oder mehrere Attribute enthalten. Im Beispiel enthält das Attribute Statement drei Attribute beginnend auf Zeile 2, 10 und 16. Alle Attributnamen haben ein Format. Im ersten Fall wird das SAML X.500/LDAP Profile genutzt. Das LDAP Attribut, welches durch OID 2.5.4.42 identifiziert wird, heißt givenName und der Attributwert ist John. Beim zweiten Attribut wird das SAML Basic Attribute Profile genutzt. Das Attribut heißt LastName und enthält den Wert Doe. Das dritte Attribut hat ein Format, das nicht von SAML definiert ist, sondern von SmithCo. Das CreditLimit des Benutzers ist 500 USD. Die Werte der Attribute können einfache Datentypen sein, wie in den ersten beiden Fällen, oder weiter strukturiertes XML wie im dritten Fall.
 == Quellen und weiterführende Links ==

Mminor at 20:55, 25 January 2010

2010-01-25T20:55:06Z

New page

SAML, die Security Assertion Markup Language, ist ein XML-basiertes Framework zum Austausch von Authentizierungs- und Authorisierungsdaten zwischen verschiedenen Sicherheitsdomänen. Der Austausch findet zwischen einem Service Provider und einem Identity Provider statt. Es wird angenommen, dass der Prinzipal bei mindestens einem Identity Provider bekannt ist. Vom Identity Provider wird erwartet, dass er ein lokales Authentizierungssystem bereitstellt. Der Service Provider verlässt sich auf den Identity Provider zur Identifizierung des Prinzipals. Auf eine Anfrage des Prinzipals erstellt der Identity Provider eine SAML assertion für den Service Provider. Anhand dieser Assertion kann der Service Provider eine Zugangsentscheidung treffen.

== Konzepte ==
SAML besteht aus mehreren aufeinander aufbauenden Komponenten. Diese erlauben, wenn zusammengesetzt, eine Vielzahl von Anwendungsfällen. SAML Assertions beinhalten Aussagen einer Partei über ein Subjekt. Beispielsweise könnte eine Assertion aussagen, dass das Subjekt John Doe heißt und die E-Mail Adresse john.doe@example.com hat. Solche Assertions werden meist nur basierend auf einer Anfrage erstellt, können aber unter bestimmten Umständen auch initial an den Empfänger gesendet werden. Es gibt drei verschiedene Statements: Authentication, Attribute, Authorization Decision Statement. Die SAML Protokolle definieren Anfragen und Antworten einer korrekten Kommunikation mithilfe von SAML-Werkzeugen. Es gibt sechs verschiedene SAML-Protokolle, dazu gehört das Authentication Request Protocol, welches Anwendung im Web Single Sign-On Fall findet. Weiter wichtige Protokolle sind das Artifact Resolution Protocol und das Single Logout Protocol. Durch SAML-Bindings wird der Transport der Nachrichten selbst organisiert, beispielsweise HTTP oder SOAP. Es werden von SAML 6 Bindings definiert. Profile haben bei SAML zwei Bedeutungen. Zum einen versteht man darunter eine Kombination beziehungsweise Einschränkung der zugrunde liegenden Komponenten für einen bestimmten Anwendungsfall. Dazu gehören 5 Single Sign-On und drei einzelne Profile. Zum anderen versteht man unter einem SAML Profil einen definierten Satz von Regeln zur Abbildung von Attributen aus andern Systemen. Beispielsweise wie Attribute aus einem LDAP-System in einer SAML-Assertion als Attribut abgebildet werden können.

== SAML-Assertion ==
<pre>
1: <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
2: Version="2.0"
3: IssueInstant="2005-01-31T12:00:00Z">
4: <saml:Issuer Format=urn:oasis:names:SAML:2.0:nameid-format:entity>
5: http://idp.example.org
6: </saml:Issuer>
7: <saml:Subject>
8: <saml:NameID
9: Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
10: j.doe@example.com
11: </saml:NameID>
12: </saml:Subject>
13: <saml:Conditions
14: NotBefore="2005-01-31T12:00:00Z"
15: NotOnOrAfter="2005-01-31T12:10:00Z">
16: </saml:Conditions>
17: <saml:AuthnStatement
18: AuthnInstant="2005-01-31T12:00:00Z" SessionIndex="67775277772">
19: <saml:AuthnContext>
20: <saml:AuthnContextClassRef>
21: urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
22: </saml:AuthnContextClassRef>
23: </saml:AuthnContext>
24: </saml:AuthnStatement>
25: </saml:Assertion>
</pre>

Die dargestellte Assertion enthält ein einzelnes Authentication Statement:
*Zeile 1 beginnt die Assertion und enthält die Deklaration des SAML-Assertion Namespace.
*Die Zeilen 2 bis 6 enthalten Metadaten der Assertion: welche Version von SAML benutzt wird, wann die Assertion erstellt wurde und wer sie erstellt hat.
*Die Zeilen 7 bis 12 enthalten Informationen über das Subjekt der Assertion. Es hat einen Name Identifier, dessen Wert j.doe@example.com ist und ein bestimmtes Format besitzt.
*Die Zeilen 13 bis 16 geben die Gültigkeit der Assertion an. Diese Assertion war gültig von 31.01.2005 12:00 mittags UTC bis 10 Minuten später.
*Zeilen 17 bis 24 enthalten das Authentication Statement. Das Subjekt wurde zur angegebenen Zeit durch einen Passwort gesicherten Transport Mechanismus, zum Beispiel Eingabe von Benutzername und Passwort Eingabe in einer SSL- gesicherten Browser-Session, authentifiziert. Außerdem angegeben ist die Zeit zu der die Authentisierung stattgefunden hat.

== Attribute Statement ==
<pre>
1: <saml:AttributeStatement>
2: <saml:Attribute
3: xmlns:x500="urn:oasis:names:tc:SAML:2.0:profiles:attribute:X500"
4: NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
5: Name="urn:oid:2.5.4.42"
6: FriendlyName="givenName">
7: <saml:AttributeValue xsi:type="xs:string"
8: x500:Encoding="LDAP">John</saml:AttributeValue>
9: </saml:Attribute>
10: <saml:Attribute
11: NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"
12: Name="LastName">
13: <saml:AttributeValue
14: xsi:type="xs:string">Doe</saml:AttributeValue>
15: </saml:Attribute>
16: <saml:Attribute
17: NameFormat="http://smithco.com/attr-formats"
18: Name="CreditLimit">
19: xmlns:smithco="http://www.smithco.com/smithco-schema.xsd"
20: <saml:AttributeValue xsi:type="smithco:type"">
21: <smithco:amount currency="USD">500.00</smithco:amount>
22: </saml:AttributeValue>
23: </saml:Attribute>
24: </saml:AttributeStatement>
</pre>

Attributsinformationen fallen häufig als Beiprodukt eines Single-Sign-On Vorgangs an oder werden auf explizite Nachfrage bestimmter Attribute übermittelt. SAML Attribute Statements haben den dargestellten Aufbau. Sie können ein oder mehrere Attribute enthalten. Im Beispiel enthält das Attribute Statement drei Attribute beginnend auf Zeile 2, 10 und 16. Alle Attributnamen haben ein Format. Im ersten Fall wird das SAML X.500/LDAP Profile genutzt. Das LDAP Attribut, welches durch OID 2.5.4.42 identifiziert wird, heißt givenName und der Attributwert ist John. Beim zweiten Attribut wird das SAML Basic Attribute Profile genutzt. Das Attribut heißt LastName und enthält den Wert Doe. Das dritte Attribut hat ein Format, das nicht von SAML definiert ist, sondern von SmithCo. Das CreditLimit des Benutzers ist 500 USD. Die Werte der Attribute können einfache Datentypen sein, wie in den ersten beiden Fällen, oder weiter strukturiertes XML wie im dritten Fall.

== Quellen und weiterführende Links ==
*[http://www.oasis-open.org/committees/download.php/27819/sstc-saml-tech-overview-2.0-cd-02.pdf SAML Technical Overview]
*[http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf SAML Assertions and Protocols]
*[http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf SAML Bindings]
*[http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf SAML Profiles]
*[http://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf SAML Security and Privacy Considerations]