SSOCircle

Artifact

Ein eindeutiger Schlüssel, der vom Service- und Identity-Provider genutzt wird, um auf eine User-Session bzw. Transaktion zu referenzieren. Wenn ein Nutzer die Website eines Service Provider besucht und der SP den Nutzer nicht identifizieren kann, dann wird er den Nutzer zu einem Identity Provider weiterleiten. Der IDP wird nach erfolgreicher Authentisierung den Nutzer wieder zurück zum SP verweisen. In der URL zum SP ist als Parameter eine kleine Nachricht ( das Artifakt ) enthalten. Diesen Schlüssel wiederum verwendet der SP in nachfolgenden Anfragen an den IDP, um die Transaktion zu referenzieren. Diese Beschreibung ist bereits eine Einweisung in SAML 2.0 Profile – in diesem Falle das “Browser Artifakt” Profil.

Assertion

SAML ist eine Abkürzung für Security Assertion Markup Language. Im Grossen und Ganzen dreht sich also bei SAML alles um “Assertions”. Assertions sind eine Aussage über einen Nutzer, Authentifizierung, Autorisierung oder Attribute. Der Identity Provider versichert diese Aussagen, die wiederum vom Service Provider zur lokalen Identifikation oder Autorisierung verwendet werden.

Obwohl diese Beschreibung einfach und selbstverständlich erscheint, ist eine ganze Menge Spezifikationsarbeit von Nöten, um sicher zu stellen, dass die beteiligten Parteien die Aussagen richtig interpretieren und auf Korrektheit prüfen können. Erneut ein Beweis wie diffizil Kommunikation sein kann …

Bindings

Assertions sind Aussagen über Identitäten. Ihre Spezifikation macht jedoch keine Aussage, wie diese Aussagen von A nach B transportiert werden. Hierzu gibt es verschiedene Möglichkeiten. Beispielsweise kann eine Nachricht in einem HTTP-POST-Body verpackt vom Identity Provider an den Service Provider geschickt werden. Wenn dieser HTTP-Post über den Browser des Nutzers übermittelt wird, spricht SAML 2.0 von einem HTTP-POST Binding.

Eine andere Variante ist das “Artifact Binding”. Hierbei wird die Assertion nicht direkt übermittelt. Stattdessen wird der Nutzer mit einem Schlüssel (das Artifakt) zurück zum Service Provider geleitet. Der SP hat dann die Möglichkeit, direkt mit dem Identity Provider zu kommunizieren. In dem er das Artifakt als Referenz zum IDP schickt, kann er die Assertions über den Nutzer erfragen. Die Übermittelung des Artifakts an den SP erfolgt i.A. als Parameter per HTTP GET. Die Rückfrage an den IDP wird dagegen per SOAP durchgeführt.

COT oder Circle of Trust

Ein Circle of Trust ist ein Zusammenschluß von Identity Provider und Service Provider zu einem Kreis des gegenseitigen Vertrauens. In so einem Zusammenschluß können die SPs bei den IDPs nach Nutzerinformation fragen. Die SPs vertrauen den Aussagen der IDPs.

In der Praxis muss ein solches Vertrauen erst verdient werden und erfordert den Abschluß von Verträgen zwischen den Rechtsabteilungen der beteiligten Organisationen. Bei SSOCircle den öffentlichen Identity Provider wird dieser Prozess sehr vereinfacht.

Hub and Spoke Model

Der Begriff von Hub and Spoke wird traditionell in der Logistik und Transportbranche verwendet. Beispielsweise in der Luftfahrt: Um von Stuttgart nach Los Angeles zu reisen, muss man erst nach Frankfurt, dem Hub, fliegen und dort einen Verbindungsflug zum Zielflughafen besteigen.

Übertragen auf das Gebiet der Identity Föderation bedeutet das: Besucht ein Nutzer Service Provider A und anschliessend Service Provider B, so muss der Nutzer zuerst über den IDP “fliegen”, um von Service Provider B identifiziert und autorisiert zu werden. “Fliegen über” heisst hier, daß der Nutzer über den IDP per Browser Redirect geführt wird.

IDP oder Identity Provider

Der Identity Provider ist eine Institution die Aussagen über eine Identität machen kann und dessen Aussagen von einem Service Provider “vertraut” wird. Hierzu muss der IDP eine sichere Authentifizierung durchführen. SSOCircle verwendet hierzu einen Registrierungsprozess bei dem die eingegebene Emailadresse überprüft wird. Zur anschliessenden Authentisierung kommen verschiedene Methoden zum Einsatz, die bis zu starken 2-Faktor Methoden ( Zertifikate, Einmal-Passwörter … ) reichen.

Metadata

Klassisch werden Metadaten als Information über andere Daten definiert. Bei SAML beinhalten die Metadaten Details über einen Service Provider oder einen Identity Provider. Beispielsweise werden hier die Endpunkte beschrieben an denen ein Provider bestimmte Nachrichten entgegennimmt. Praktisch sind das Adress-Daten wie Servernamen, Ports, URI und Bedingungen wie “der Provider erwartet, daß die gesendeten Daten signiert sind”

Profiles

SSO Profile beschreiben wie ein Single Sign On erreicht werden kann. Es exisitieren verschiedene Profile für unterschiedliche Clients: Browser (Web Browser SSO Profile ) und andere Geräte ( Enhanced Client Profile). Single Logout Profile und Name Identifier Management ergänzen die Beschreibung des Lebenszyklus einer Nutzersession oder einer Nutzerkonten-Kopplung.

Die Web Browser SSO Profile legen die Nachrichten fest, die zwischen Service und Identity Provider ausgetauscht werden. Diese Nachrichten sind die Grundlage für Provider, um einem bestimmten Nutzer Zugriff auf Systeme oder Daten zu gewähren. Diese Entscheidung wird auf Basis von Assertions getroffen. In der Assertion bestätigt der IDP beispielsweise, daß ein Nutzer bereits authentifiziert ist. Ein Naming Identifier wird benutzt, um eine anonyme Koppelung zwischen Accounts oder Gruppen zu erhalten. Ein SP kann somit nicht auf die Account ID des Nutzers bei anderen SPs oder beim IDP rückschliessen. Zur Implementierung eines Profils wird ein spezielles Binding verwendet.

SAML oder Security Assertion Markup Language

SAML ist ein Standard, der von der Organisation OASIS Security Services Technical Committee (SSTC) festgelegt wurde. SAML spezifiziert den Austausch und das Format von Aussagen zwischen Service Provider und Identity Provider. Details sind in SAML 2.0 bei SSOCircle beschrieben.

SP oder Service Provider

Eine Website, die seinen Nutzern einen Dienst bereitstellt. Tritt dieser Service Provider einem Circle of Trust bei, so vertraut er den Aussagen eines IDPs über einen Nutzer.

Ein Service Provider kann somit seinen Nutzern einen höheren Komfort anbieten, da der Nutzer nun nicht wiederholt seine Benutzerdaten eingeben muss.
Helpdesk-Arbeiten können an den IDP delegiert werden und bietet der IDP, so wie SSOCircle, starke Authentifizierung an, so profitiert ein SP von dieser höheren Sicherheit ohne daß hierfür eine eigene Infrastruktur wie PKI betrieben werden muss.

*deu*