Mit Google oder Facebook einloggen, dürften die meisten hier kennen. Die meisten dieser Web-Anmeldungen für andere Anwendungen basieren auf OAuth oder OpenID Connect, was auf OAuth aufbaut. Zusätzlich gibts noch eine andere Variante, die im Wissenschaftsumfeld und bei Behörden vor allem eingesetzt wird.
Allgemein gehts im Identitätsmanagement um das Verwaltung von Identitäten, d.h. das Identifizieren, Authentifizieren und Autorisieren von Nutzern.
Eine Identität ist ein Identifikator für eine Person (oder Organisation, Ressource, Dienst), meist mit weiteren Informationen, wie Benutzerinformationen (z.B. E-Mail-Adresse, Abteilung, Telefonnummer) und Berechtigungen. Diese Benutzerinformationen werden auch Attribute genannt.
Es gibt verschiedene Gründe für Identitätsmanagement allgemein:
Ebenso gibt es Gründe für organisationsübergreifendes Identitätsmanagement. Ich möchte nach und nach mal ein paar Informationen über die Protokolle, Verwendung, Implementierungen sowie Vor- und Nachteile beschreiben. Wer mag, kann gerne auch mehr praktisches erklären Ich fange mal mit ein paar Basisinfos zu SAML an.
SAML
Hintergrund
SAML wird vom Security Service Technical Committee (SSTC) von OASIS entwickelt und ist ein XML-basiertes Framework für FIM. SAML V1.0 wurde im November 2002 ein OASIS Standard. Die aktuelle Version ist V2.0.
SAML ist ein allgemeines Framework, um Informationen über Identitäten, Attribute und Berechtigungen zu kommunizieren, wodurch SAML auf verschiedenen Arten eingesetzt werden kann.
Einschub: digitale Identitäten hat jeder meist mehrere, wie ich hier "LadyRavenous". Attribute sind Benutzerinformationen, wie die Infos über mich, die ihr in meinem Profil seht oder die ihr angegeben habt. Das kann z.B. Geschlecht, Hobbies oder auch ICQ-Kontaktinfos sein. Berechtigungen sollte hier klar sein
Verwendung
SAML nimmt man im sogenannten föderierten Identitätsmanagement (FIM) her. Identitätsmanagement in Firmen ist Firmenintern, basiert auf LDAP oder AD (Manchmal auch mit DB) und verwendet wenigstens stellenweise SSO. Will man jetzt Firmenübergreifend (oder teils auch nur Standortübergreifend) gemeinsame Dienste verwenden, gibts mehrere Möglichkeiten: Benutzerkonten duplizieren (bei wenigen Nutzern durchaus sinnvoll) oder eben föderiertes Identitätsmanagement aufbauen. Dafür brauchts Software, gemeinsame Regelungen usw.
Konkreter eingesetzt wird es im Wissenschaftsumfeld, auch wenn einzelne Gruppierungen, Hochschulen und Einrichtungen parallel inzwischen OAuth mit OpenID Connect einsetzen. Die Föderation (eigentlich Inter-Föderation) heißt hier übrigens eduGAIN. In Deutschland haben wir hier die DFN-AAI.
eID - schaut einfach unter STORK. In Österreich gibts auch eine staatliche Föderation zwischen mehreren Behörden.
Teils wird SAML auch noch in der Industrie eingesetzt, jedenfalls dort, wo viel auf PKI und Zertifikate basiert.
Beispiel-Workflow
Nutzer von einer Hochschule/Firma/was auch immer (Identity Provider, kurz IdP oder IDP) will einen Dienst einer Hochschule/Firma/was auch immer (Service Provider, kurz SP) nutzen. Anstatt sich neu zu registrieren, haben IDP und SP SAML am laufen, heißt beide haben Implementierungen on top ihres lokalen Identitätsmanagements. Zusätzlich sind IDP und SP teil einer Föderation und "kenne und vertrauen sich". Beim SP kann der Nutzer seine Heimatorganisation (IDP) auswählen. Wenn er sich dort noch nicht eingeloggt hat, wird er zum IDP weitergeleitet, wo er sich anmeldet. Der SP hat in seinen Metadaten die gewünschten Informationen (Attribute) vermerkt. Alternativ sendet er die gewünschten Attribute per Request. Diese Informationen werden, nachdem der Nutzer das ok gegeben hat, an den SP gesendet. Mit Hilfe dieser Informationen kann der Nutzer nun den Dienst verwenden und ist dort eingeloggt.
Rollen
Ich habe gerade ja schon Identity Provider und Service Provider eingeführt.
Benötigte Software
Der IDP und der SP benötigen jeweils eine Software, damit die Kommunikation funktioniert. Beide Seiten müssen Metadaten erstellen, was halbautomatisch geht. Metadaten wie auch viele Teile der Kommunikation sind XML.
Früher gab es vor allem zentrale Lokalisierungsdienste. Viele SPs betreiben mittlerweile ihre eigenen lokalen Lokalisierungsdienste. Aufgelistet sind dort alle IDPs, denen der SP vertraut (= deren Metadaten gespeichert sind).
Implementierungen
Im Wissenschaftsumfeld sind die Implementierungen Shibboleth und SimpleSAMLphp weit verbreitet. PySAML2 ist seit einiger Zeit in der Distribution Ubuntu nativ vorhanden sein, für andere Distributionen gibt es ebenfalls Pakete. ADFS ist die Ergänzung zu AD, zudem gibt es weitere Open Source und kommerzielle Produkte, wie Ping Identity, ForgeRock usw.
Das Projekt Shibboleth wurde ursprünglich von einer Initiative der Internet2 Middleware in den USA im Jahr 2000 gestartet. Anschließend wurde zusammen mit der OASIS SAML Working Group an der Software entwickelt. Shibboleth ist eine Open Source Implementierung von SAML, die unter der Apache Software License herausgegeben wird.
IDP: Java (inzwischen ziemlich schön, kann man mittlerweile auch gut erweitern, alles andere als schlank)
SP: C, C++ (Katastrophe - Finger weg!)
PySAML2 wird federführend von Roland Hedberg in Python geschrieben. PySAML2 basiert auf Web Service Gateway Interface (WSGI), einem standardisierten Interface zwischen Webserver und Webanwendung. Für den Lebenszyklus einer Anfrage wird das WSGI Framework repoze.who verwendet. repoze.who teilt Anfrage auf Ingress und Egress auf:
Die Implementierung unterstützt nativ virtuelle Organisationen (Zusammenschlüsse wie Föderationen, die aber keine eigenen Föderationen im klassischen Sinn sind - organisatorisches Problem, kein technisches) und Attribut Aggregation (Benutzerinformationen von mehreren IDPs werden aggregiert). Hingegen existieren Lokalisierungsdienst und Consent (Zustimmung, ob die Benutzerinformationen an den SP gesendet werden dürfen) nur rudimentär.
IDP/SP: Python (einiges rudimentär, kann man aber gut erweitern, leichtgewichtig)
ADFS baut auf AD auf und existiert seit einigen Jahren und unterstützt inzwischen sowohl SAML als auch OAuth. Die Sprache von ADFS ist an OpenID Connect und OAuth angelehnt. Eine Assertion wird hier Security Token genannt, ein Identity Provider ist ein Claims Provider, der Service Provider wird Relying Party genannt und die Attribute sind Claims.
Vorteil: AD ist meist schon vorhanden
Nachteil: ADFS akzeptiert nur einen SP. Wenn man mehrere SPs hat, muss man einen Proxy davor schalten. Auch sonst in meinen Augen ziemlich gewöhnungsbedürftig.
ForgeRock habe ich mir nur kurz angeschaut. Ingesamt fand ich die Software am vielversprechensten, da mit OAuth/OIDC und UMA sowie SAML. Leider habe ich sie nie getestet.
Ach ja, natürlich muss man jede Implementierung nach dem Installieren noch Konfigurieren. Wichtig ist dabei, dass die Attribute gefiltert werden, d.h. nur die Attribute an SPs geschickt werden, die sie anfragen. Hier kann man noch Ausnahmen machen bzw. lieber mit einer Whitelist arbeiten. Normalerweise müssen Attribute auch umgewandelt werden, da das interne Schema unterschiedlich ist zu dem des SPs usw.
Aufbau
SAML ist ein Gerüst aus Protocols, Bindings, Profiles, Metadaten und Assertions. Über diese Spezifikationen kann SAML für verschiedene Einsatzzwecke kombiniert werden, was Vor- und Nachteile hat.
Metadaten
Mal ein Beispiel eines SPs (leicht gekürzt), damit ihr mehr darunter vorstellen könnt.
[src=xml]<EntityDescriptor entityID="http://shibboleth.ebscohost.com">
<Extensions>
<mdrpi:RegistrationInfo registrationAuthority="https://www.aai.dfn.de" registrationInstant="2009-05-26T08:35:28Z">
<mdrpi:RegistrationPolicy xml:lang="en">https://www.aai.dfn.de/en/join/</mdrpi:RegistrationPolicy>
<mdrpi:RegistrationPolicy xml:lang="de">https://www.aai.dfn.de/teilnahme/</mdrpi:RegistrationPolicy>
</mdrpi:RegistrationInfo>
</Extensions>
<SPSSODescriptor protocolSupportEnumeration="urnasis:names:tc:SAML:1.1rotocol urnasis:names:tc:SAML:2.0rotocol">
<Extensions>
<idpdisciscoveryResponse Binding="urnasis:names:tc:SAMLrofiles:SSO:idp-discovery-protocol" Location="https://shibboleth.ebscohost.com/Shibboleth.sso/Login" index="1"/>
<mdui:UIInfo><mduiisplayName xml:lang="de">EBSCO Information Services/EBSCO Publishing</mduiisplayName>
<mduiisplayName xml:lang="en">EBSCO Information Services/EBSCO Publishing</mduiisplayName>
<mduiescription xml:lang="de">EBSCO Publishing, a premier database aggregator, offers more than 200 research databases powered by EBSCOhost®, one of the most-used subscription services available. Through a library of tens of thousands of full-text journals, magazines, books, monographs, reports and various other publication types from renowned publishers, EBSCO serves the content needs of researchers at institutions around the world.</mduiescription>
<mduiescription xml:lang="en">EBSCO Publishing, a premier database aggregator, offers more than 200 research databases powered by EBSCOhost®, one of the most-used subscription services available. Through a library of tens of thousands of full-text journals, magazines, books, monographs, reports and various other publication types from renowned publishers, EBSCO serves the content needs of researchers at institutions around the world.</mduiescription>
<mdui:InformationURL xml:lang="de">http://www.ebscohost.com</mdui:InformationURL>
<mdui:InformationURL xml:lang="en">http://www.ebscohost.com</mdui:InformationURL>
</mdui:UIInfo>
</Extensions>
<KeyDescriptor use="signing">
<ds:KeyInfo>
<ds:KeyName>shibboleth.ebscohost.com</ds:KeyName>
<ds:X509Data><ds:X509SubjectName>CN=shibboleth.ebscohost.com,O=EBSCO Industries Inc.,L=Birmingham,ST=Alabama,C=US</ds:X509SubjectName>
<ds:X509Certificate>MIIFjzCCBHegAwIBAgIJALgyIfD0A59WMA0GCSqGSIb3DQEBCwUAMIG0MQswCQYD....
<AssertionConsumerService>
<Binding="urnasis:names:tc:SAML:1.0rofiles:browser-post" Location="https://shibboleth.ebscohost.com/Shibboleth.sso/SAML/POST" index="0"/>
<AssertionConsumerService Binding="urnasis:names:tc:SAML:1.0rofiles:artifact-01" Location="https://shibboleth.ebscohost.com/Shibboleth.sso/SAML/Artifact" index="1"/>
<AssertionConsumerService Binding="urnasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://shibboleth.ebscohost.com/Shibboleth.sso/SAML2/POST" index="2"/>
<AssertionConsumerService Binding="urnasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign" Location="https://shibboleth.ebscohost.com/Shibboleth.sso/SAML2/POST-SimpleSign" index="3"/>
<AssertionConsumerService Binding="urnasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location="https://shibboleth.ebscohost.com/Shibboleth.sso/SAML2/Artifact" index="4"/>
<AssertionConsumerService Binding="urnasis:names:tc:SAML:2.0:bindings:PAOS" Location="https://shibboleth.ebscohost.com/Shibboleth.sso/SAML2/ECP" index="5"/></SPSSODescriptor>
<Organization>
<OrganizationName xml:lang="de">e55</OrganizationName>
<OrganizationName xml:lang="en">e55</OrganizationName>
<OrganizationDisplayName xml:lang="de">EBSCO Publishing</OrganizationDisplayName>
<OrganizationDisplayName xml:lang="en">EBSCO Publishing</OrganizationDisplayName>
<OrganizationURL xml:lang="de">http://www.ebsco.com</OrganizationURL>
<OrganizationURL xml:lang="en">http://www.ebsco.com</OrganizationURL>
</Organization>
...
</EntityDescriptor>[/src]
Die angefragten Attribute können so ausschauen:
[src=xml]<RequestedAttribute FriendlyName="eduPersonScopedAffiliation" Name="urnace:dir:attribute-def:eduPersonScopedAffiliation" NameFormat="urnace:shibboleth:1.0:attributeNamespace:uri" isRequired="true"/>
<RequestedAttribute FriendlyName="eduPersonScopedAffiliation" Name="urnid:1.3.6.1.4.1.5923.1.1.1.9" NameFormat="urnasis:names:tc:SAML:2.0:attrname-format:uri" isRequired="true"/>
<RequestedAttribute FriendlyName="eduPersonPrincipalName" Name="urnace:dir:attribute-def:eduPersonPrincipalName" NameFormat="urnace:shibboleth:1.0:attributeNamespace:uri" isRequired="true"/>
<RequestedAttribute FriendlyName="eduPersonPrincipalName" Name="urnid:1.3.6.1.4.1.5923.1.1.1.6" NameFormat="urnasis:names:tc:SAML:2.0:attrname-format:uri" isRequired="true"/>
<RequestedAttribute FriendlyName="givenName" Name="urnace:dir:attribute-def:givenName" NameFormat="urnace:shibboleth:1.0:attributeNamespace:uri" isRequired="true"/>
<RequestedAttribute FriendlyName="givenName" Name="urnid:2.5.4.42" NameFormat="urnasis:names:tc:SAML:2.0:attrname-format:uri" isRequired="true"/><RequestedAttribute FriendlyName="sn" Name="urnace:dir:attribute-def:sn" NameFormat="urnace:shibboleth:1.0:attributeNamespace:uri" isRequired="true"/><RequestedAttribute FriendlyName="sn" Name="urnid:2.5.4.4" NameFormat="urnasis:names:tc:SAML:2.0:attrname-format:uri" isRequired="true"/>
<RequestedAttribute FriendlyName="mail" Name="urnace:dir:attribute-defail" NameFormat="urnace:shibboleth:1.0:attributeNamespace:uri" isRequired="true"/><RequestedAttribute FriendlyName="mail" Name="urnid:0.9.2342.19200300.100.1.3" NameFormat="urnasis:names:tc:SAML:2.0:attrname-format:uri" isRequired="true"/><RequestedAttribute FriendlyName="dfnEduPersonBranchAndDegree" Name="urnid:1.3.6.1.4.1.22177.400.1.1.3.9" NameFormat="urnasis:names:tc:SAML:2.0:attrname-format:uri" isRequired="false"/>[/src]
Es gibt einen sprechenden Namen (FriendlyName), dann noch eine genaue Beschreibung, was damit gemeint ist (Name) und das Format (NameFOrmat). MACE-Dir hat z.B. ein Schema erstellt (also wie Attribute heißen, wie sie ausschauen sollen) und genau dieses Schema wird stellenweise referenziert. isRequired ist so eine Sache. In anderen Ländern wird diese Info immer angegeben bzw. angefragt, hierzulande dürften eigentlich nur Attribute angefragt werden, die unbedingt zum Funktionieren eines Dienstes benötigt werden.
Und noch ein Beispiel eines IDPs (genauer gesagt AA, aber sieht wie IDP aus, ebenfalls gekürzt).
[src=xml]<EntityDescriptor entityID="https://aai-integration.dfn.de/idp/shibboleth">
<Extensions>
<mdrpi:RegistrationInfo registrationAuthority="https://www.aai.dfn.de" registrationInstant="2014-02-09T13:52:03Z">
<mdrpi:RegistrationPolicy xml:lang="en">https://www.aai.dfn.de/en/join/</mdrpi:RegistrationPolicy>
<mdrpi:RegistrationPolicy xml:lang="de">https://www.aai.dfn.de/teilnahme/</mdrpi:RegistrationPolicy>
</mdrpi:RegistrationInfo>
<mdattr:EntityAttributes>
<saml:Attribute Name="http://aai.dfn.de/loa/degree-of-reliance" NameFormat="urnasis:names:tc:SAML:2.0:attrname-format:uri"> <saml:AttributeValue>advanced</saml:AttributeValue>
</saml:Attribute>
</mdattr:EntityAttributes>
</Extensions>
<IDPSSODescriptor protocolSupportEnumeration="urnasis:names:tc:SAML:2.0rotocol">
<Extensions>
<saml1md:Scope regexp="false">testscope.dfn.de</saml1md:Scope>
<mdui:UIInfo>
....<mdui:Logo height="130" width="236">https://www.aai.dfn.de/fileadmin/pics/dfn_big.png</mdui:Logo></mdui:UIInfo>
</Extensions>
<KeyDescriptor>....
<AttributeService Binding="urnasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://aai-integration.dfn.de:8443/idp/profile/SAML2/SOAP/AttributeQuery"/><NameIDFormat>urnasis:names:tc:SAML:2.0:nameid-format:transient</NameIDFormat><NameIDFormat>urnasis:names:tc:SAML:2.0:nameid-formatersistent</NameIDFormat></AttributeAuthorityDescriptor>....[/src]
Statements
Die Benutzerinformationen werden über Statements ausgetauscht:
Vor- und Nachteile, sowie Tendenz
Vorteile: durch die festen Föderationen hat man strenge Regeln, wer mitmachen darf und wer nicht. Meist gibts vorher Verträge, Bedingungen, die man erfüllen muss usw.
Nachdem es jahrelang im Einsatz hat, ist es in gewissem Grad erprobt.
Es gibt einige Open Source Implementierungen und läuft mittlerweile auch bei großen Föderationen.
Durch den Aufbau kann man SAML auf viele Anwendungsfälle anpassen oder die passenden Bindings und Profiles aussuchen.
Nachteile: Durch die unterschiedlichen Bindings und Profiles kann es sein, dass SAML untereinander inkompatibel ist (eduGAIN-STORK geht nur über Proxys).
Mobil ist eine Katastrophe mit SAML.
Dynamisch geht auch eher wenig, auch wenn es einzelne Konzepte und Proof of Concept Implementierungen gibt.
Manche Implementierungen will man einfach nicht anfassen.
Tendenz: Weg von SAML zu OpenID Connect, wobei SAML sicherlich noch jahrelang existieren wird.
Ein paar Unterschiede:
Tipps
Wer mal SAML ein wenig sehen will, dem empfehle ich das Plugin SAML Tracer für Firefox. Damit kann man den Nachrichtenablauf und den Inhalt (wenn nicht verschlüsselt) sehen. Für Chrome gibts SAML DevTools.
Wer nicht schlafen kann, dem kann ich die SAML-Spezifikationen empfehlen
Allgemein gehts im Identitätsmanagement um das Verwaltung von Identitäten, d.h. das Identifizieren, Authentifizieren und Autorisieren von Nutzern.
- Identifizieren: Erkennen einer Identität
- Authentifizieren: Bestätigung der Behauptung einer Identität
- Autorisieren: Einräumen oder Verweigern von Berechtigungen, die zum Benutzen eines Dienstes benötigt werden
Eine Identität ist ein Identifikator für eine Person (oder Organisation, Ressource, Dienst), meist mit weiteren Informationen, wie Benutzerinformationen (z.B. E-Mail-Adresse, Abteilung, Telefonnummer) und Berechtigungen. Diese Benutzerinformationen werden auch Attribute genannt.
Es gibt verschiedene Gründe für Identitätsmanagement allgemein:
- Konsistenz von Daten
- höhere Datenqualität
- Verfügbarkeit und Verlässlichkeit des Dienstes
- Effizienzsteigerung
- Benutzerfreundlichkeit, z. B. durch SSO und Verbindung zu anderen Systemen
Ebenso gibt es Gründe für organisationsübergreifendes Identitätsmanagement. Ich möchte nach und nach mal ein paar Informationen über die Protokolle, Verwendung, Implementierungen sowie Vor- und Nachteile beschreiben. Wer mag, kann gerne auch mehr praktisches erklären Ich fange mal mit ein paar Basisinfos zu SAML an.
SAML
Hintergrund
SAML wird vom Security Service Technical Committee (SSTC) von OASIS entwickelt und ist ein XML-basiertes Framework für FIM. SAML V1.0 wurde im November 2002 ein OASIS Standard. Die aktuelle Version ist V2.0.
SAML ist ein allgemeines Framework, um Informationen über Identitäten, Attribute und Berechtigungen zu kommunizieren, wodurch SAML auf verschiedenen Arten eingesetzt werden kann.
Einschub: digitale Identitäten hat jeder meist mehrere, wie ich hier "LadyRavenous". Attribute sind Benutzerinformationen, wie die Infos über mich, die ihr in meinem Profil seht oder die ihr angegeben habt. Das kann z.B. Geschlecht, Hobbies oder auch ICQ-Kontaktinfos sein. Berechtigungen sollte hier klar sein
Verwendung
SAML nimmt man im sogenannten föderierten Identitätsmanagement (FIM) her. Identitätsmanagement in Firmen ist Firmenintern, basiert auf LDAP oder AD (Manchmal auch mit DB) und verwendet wenigstens stellenweise SSO. Will man jetzt Firmenübergreifend (oder teils auch nur Standortübergreifend) gemeinsame Dienste verwenden, gibts mehrere Möglichkeiten: Benutzerkonten duplizieren (bei wenigen Nutzern durchaus sinnvoll) oder eben föderiertes Identitätsmanagement aufbauen. Dafür brauchts Software, gemeinsame Regelungen usw.
Konkreter eingesetzt wird es im Wissenschaftsumfeld, auch wenn einzelne Gruppierungen, Hochschulen und Einrichtungen parallel inzwischen OAuth mit OpenID Connect einsetzen. Die Föderation (eigentlich Inter-Föderation) heißt hier übrigens eduGAIN. In Deutschland haben wir hier die DFN-AAI.
eID - schaut einfach unter STORK. In Österreich gibts auch eine staatliche Föderation zwischen mehreren Behörden.
Teils wird SAML auch noch in der Industrie eingesetzt, jedenfalls dort, wo viel auf PKI und Zertifikate basiert.
Beispiel-Workflow
Nutzer von einer Hochschule/Firma/was auch immer (Identity Provider, kurz IdP oder IDP) will einen Dienst einer Hochschule/Firma/was auch immer (Service Provider, kurz SP) nutzen. Anstatt sich neu zu registrieren, haben IDP und SP SAML am laufen, heißt beide haben Implementierungen on top ihres lokalen Identitätsmanagements. Zusätzlich sind IDP und SP teil einer Föderation und "kenne und vertrauen sich". Beim SP kann der Nutzer seine Heimatorganisation (IDP) auswählen. Wenn er sich dort noch nicht eingeloggt hat, wird er zum IDP weitergeleitet, wo er sich anmeldet. Der SP hat in seinen Metadaten die gewünschten Informationen (Attribute) vermerkt. Alternativ sendet er die gewünschten Attribute per Request. Diese Informationen werden, nachdem der Nutzer das ok gegeben hat, an den SP gesendet. Mit Hilfe dieser Informationen kann der Nutzer nun den Dienst verwenden und ist dort eingeloggt.
Rollen
Ich habe gerade ja schon Identity Provider und Service Provider eingeführt.
- Identity Provider (IDP/IdP) ist die Heimatorganisation, die Informationen über einen Benutzer führt. Meist sind diese entweder in einem AD oder LDAP hinterlegt, kann aber auch eine DB sein.
- Der Service Provider (SP) bietet einen oder mehrere Dienste an und möchte dafür Informationen über die Nutzer haben. Im einfachsten Fall ist das ein Mitglied, es können aber auch weitere Informationen, wie User-ID, E-Mail, Studiengang oder ähnliches übertragen werden.
- Föderation ist ein Zusammenschluss von mehreren IDPs und SPs (im Normalfall, gibt auch Föderaitonen mit nur einem IDP). Die Föderation bzw. ein Dienst von ihr aggregiert die Metadaten der IDPs und SPs und stellt diese zur Verfügung.
- Weitere Dienste, wie ein zentraler Lokalisierungsdienst oder eine PKI, werden als Trusted Third Partys (TTPs) bezeichnet.
- Natürlich gibts in dem Konstrukt auch noch einen Nutzer (User).
- Ein witziges Konstrukt ist die Attribute Authority (AA). Sie bietet Informationen über Benutzer, kann aber nicht authentifizieren. Warum es die AAs trotzdem gibt? Nun, manchmal senden IDPs nicht alle Informationen oder Benutzer sind parallel zu den Föderationen unterwegs. Eigentlich vor allem organisatorische Gründe...
Benötigte Software
Der IDP und der SP benötigen jeweils eine Software, damit die Kommunikation funktioniert. Beide Seiten müssen Metadaten erstellen, was halbautomatisch geht. Metadaten wie auch viele Teile der Kommunikation sind XML.
Früher gab es vor allem zentrale Lokalisierungsdienste. Viele SPs betreiben mittlerweile ihre eigenen lokalen Lokalisierungsdienste. Aufgelistet sind dort alle IDPs, denen der SP vertraut (= deren Metadaten gespeichert sind).
Implementierungen
Im Wissenschaftsumfeld sind die Implementierungen Shibboleth und SimpleSAMLphp weit verbreitet. PySAML2 ist seit einiger Zeit in der Distribution Ubuntu nativ vorhanden sein, für andere Distributionen gibt es ebenfalls Pakete. ADFS ist die Ergänzung zu AD, zudem gibt es weitere Open Source und kommerzielle Produkte, wie Ping Identity, ForgeRock usw.
Das Projekt Shibboleth wurde ursprünglich von einer Initiative der Internet2 Middleware in den USA im Jahr 2000 gestartet. Anschließend wurde zusammen mit der OASIS SAML Working Group an der Software entwickelt. Shibboleth ist eine Open Source Implementierung von SAML, die unter der Apache Software License herausgegeben wird.
IDP: Java (inzwischen ziemlich schön, kann man mittlerweile auch gut erweitern, alles andere als schlank)
SP: C, C++ (Katastrophe - Finger weg!)
PySAML2 wird federführend von Roland Hedberg in Python geschrieben. PySAML2 basiert auf Web Service Gateway Interface (WSGI), einem standardisierten Interface zwischen Webserver und Webanwendung. Für den Lebenszyklus einer Anfrage wird das WSGI Framework repoze.who verwendet. repoze.who teilt Anfrage auf Ingress und Egress auf:
- Ingress: request classification, identification, authentication, metadata provision
- Egress: challenge decision, challenge, remember
Die Implementierung unterstützt nativ virtuelle Organisationen (Zusammenschlüsse wie Föderationen, die aber keine eigenen Föderationen im klassischen Sinn sind - organisatorisches Problem, kein technisches) und Attribut Aggregation (Benutzerinformationen von mehreren IDPs werden aggregiert). Hingegen existieren Lokalisierungsdienst und Consent (Zustimmung, ob die Benutzerinformationen an den SP gesendet werden dürfen) nur rudimentär.
IDP/SP: Python (einiges rudimentär, kann man aber gut erweitern, leichtgewichtig)
ADFS baut auf AD auf und existiert seit einigen Jahren und unterstützt inzwischen sowohl SAML als auch OAuth. Die Sprache von ADFS ist an OpenID Connect und OAuth angelehnt. Eine Assertion wird hier Security Token genannt, ein Identity Provider ist ein Claims Provider, der Service Provider wird Relying Party genannt und die Attribute sind Claims.
Vorteil: AD ist meist schon vorhanden
Nachteil: ADFS akzeptiert nur einen SP. Wenn man mehrere SPs hat, muss man einen Proxy davor schalten. Auch sonst in meinen Augen ziemlich gewöhnungsbedürftig.
ForgeRock habe ich mir nur kurz angeschaut. Ingesamt fand ich die Software am vielversprechensten, da mit OAuth/OIDC und UMA sowie SAML. Leider habe ich sie nie getestet.
Ach ja, natürlich muss man jede Implementierung nach dem Installieren noch Konfigurieren. Wichtig ist dabei, dass die Attribute gefiltert werden, d.h. nur die Attribute an SPs geschickt werden, die sie anfragen. Hier kann man noch Ausnahmen machen bzw. lieber mit einer Whitelist arbeiten. Normalerweise müssen Attribute auch umgewandelt werden, da das interne Schema unterschiedlich ist zu dem des SPs usw.
Aufbau
SAML ist ein Gerüst aus Protocols, Bindings, Profiles, Metadaten und Assertions. Über diese Spezifikationen kann SAML für verschiedene Einsatzzwecke kombiniert werden, was Vor- und Nachteile hat.
- Assertions: Gebündelte Informationen, Statements, welche von einer Entität gesendet werden. Diese dienen entweder der Authentifizierung (Authentication), enthalten Attributsinformationen oder überliefern die Autorisierungsentscheidung (Authorization Decision). Die Struktur einer Assertion ist generisch mit allgemeinen Informationen über die sendende Entität und der Assertion an sich.
- Protocols: Ablauf von Nachrichten, d. h. Requests und Responses, zwischen Entitäten, beispielsweise für die Authentifizierung oder zum Single Logout.
- Bindings: Verknüpfung von SAML Nachrichten zu anderen Übertragungsprotokollen. So beschreibt das SAML SOAP Binding wie SAML Nachrichten über Simple Object Access
- Protocol (SOAP) Nachrichten kommuniziert werden können. Bindings werden in [SAML2Bind] näher beschrieben.
- Profiles: Spezifikation von SAML für bestimmte Anwendungsfälle durch Bedingungen oder bzw. und Erweiterungen, z. B. das Web Browser SSO Profile für Nutzung von SSO durch Webbrowser. Zusätzlich gibt es Attribute Profiles, welche Regeln zur Interpretation von Attributen in SAML Attribute Assertions definieren. Profiles sind in [SAML2Prof] näher spezifiziert.
- Metadata: Informationen über eine Entität, welche gleichzeitig ein Kommunikationsendpunkt ist [SAML2Meta].
- Authentication Context: Kontext der Authentifizierung [SAMLAC]. (In meinen Augen leider zu selten verwendet)
Metadaten
Mal ein Beispiel eines SPs (leicht gekürzt), damit ihr mehr darunter vorstellen könnt.
[src=xml]<EntityDescriptor entityID="http://shibboleth.ebscohost.com">
<Extensions>
<mdrpi:RegistrationInfo registrationAuthority="https://www.aai.dfn.de" registrationInstant="2009-05-26T08:35:28Z">
<mdrpi:RegistrationPolicy xml:lang="en">https://www.aai.dfn.de/en/join/</mdrpi:RegistrationPolicy>
<mdrpi:RegistrationPolicy xml:lang="de">https://www.aai.dfn.de/teilnahme/</mdrpi:RegistrationPolicy>
</mdrpi:RegistrationInfo>
</Extensions>
<SPSSODescriptor protocolSupportEnumeration="urnasis:names:tc:SAML:1.1rotocol urnasis:names:tc:SAML:2.0rotocol">
<Extensions>
<idpdisciscoveryResponse Binding="urnasis:names:tc:SAMLrofiles:SSO:idp-discovery-protocol" Location="https://shibboleth.ebscohost.com/Shibboleth.sso/Login" index="1"/>
<mdui:UIInfo><mduiisplayName xml:lang="de">EBSCO Information Services/EBSCO Publishing</mduiisplayName>
<mduiisplayName xml:lang="en">EBSCO Information Services/EBSCO Publishing</mduiisplayName>
<mduiescription xml:lang="de">EBSCO Publishing, a premier database aggregator, offers more than 200 research databases powered by EBSCOhost®, one of the most-used subscription services available. Through a library of tens of thousands of full-text journals, magazines, books, monographs, reports and various other publication types from renowned publishers, EBSCO serves the content needs of researchers at institutions around the world.</mduiescription>
<mduiescription xml:lang="en">EBSCO Publishing, a premier database aggregator, offers more than 200 research databases powered by EBSCOhost®, one of the most-used subscription services available. Through a library of tens of thousands of full-text journals, magazines, books, monographs, reports and various other publication types from renowned publishers, EBSCO serves the content needs of researchers at institutions around the world.</mduiescription>
<mdui:InformationURL xml:lang="de">http://www.ebscohost.com</mdui:InformationURL>
<mdui:InformationURL xml:lang="en">http://www.ebscohost.com</mdui:InformationURL>
</mdui:UIInfo>
</Extensions>
<KeyDescriptor use="signing">
<ds:KeyInfo>
<ds:KeyName>shibboleth.ebscohost.com</ds:KeyName>
<ds:X509Data><ds:X509SubjectName>CN=shibboleth.ebscohost.com,O=EBSCO Industries Inc.,L=Birmingham,ST=Alabama,C=US</ds:X509SubjectName>
<ds:X509Certificate>MIIFjzCCBHegAwIBAgIJALgyIfD0A59WMA0GCSqGSIb3DQEBCwUAMIG0MQswCQYD....
<AssertionConsumerService>
<Binding="urnasis:names:tc:SAML:1.0rofiles:browser-post" Location="https://shibboleth.ebscohost.com/Shibboleth.sso/SAML/POST" index="0"/>
<AssertionConsumerService Binding="urnasis:names:tc:SAML:1.0rofiles:artifact-01" Location="https://shibboleth.ebscohost.com/Shibboleth.sso/SAML/Artifact" index="1"/>
<AssertionConsumerService Binding="urnasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://shibboleth.ebscohost.com/Shibboleth.sso/SAML2/POST" index="2"/>
<AssertionConsumerService Binding="urnasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign" Location="https://shibboleth.ebscohost.com/Shibboleth.sso/SAML2/POST-SimpleSign" index="3"/>
<AssertionConsumerService Binding="urnasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location="https://shibboleth.ebscohost.com/Shibboleth.sso/SAML2/Artifact" index="4"/>
<AssertionConsumerService Binding="urnasis:names:tc:SAML:2.0:bindings:PAOS" Location="https://shibboleth.ebscohost.com/Shibboleth.sso/SAML2/ECP" index="5"/></SPSSODescriptor>
<Organization>
<OrganizationName xml:lang="de">e55</OrganizationName>
<OrganizationName xml:lang="en">e55</OrganizationName>
<OrganizationDisplayName xml:lang="de">EBSCO Publishing</OrganizationDisplayName>
<OrganizationDisplayName xml:lang="en">EBSCO Publishing</OrganizationDisplayName>
<OrganizationURL xml:lang="de">http://www.ebsco.com</OrganizationURL>
<OrganizationURL xml:lang="en">http://www.ebsco.com</OrganizationURL>
</Organization>
...
</EntityDescriptor>[/src]
Die angefragten Attribute können so ausschauen:
[src=xml]<RequestedAttribute FriendlyName="eduPersonScopedAffiliation" Name="urnace:dir:attribute-def:eduPersonScopedAffiliation" NameFormat="urnace:shibboleth:1.0:attributeNamespace:uri" isRequired="true"/>
<RequestedAttribute FriendlyName="eduPersonScopedAffiliation" Name="urnid:1.3.6.1.4.1.5923.1.1.1.9" NameFormat="urnasis:names:tc:SAML:2.0:attrname-format:uri" isRequired="true"/>
<RequestedAttribute FriendlyName="eduPersonPrincipalName" Name="urnace:dir:attribute-def:eduPersonPrincipalName" NameFormat="urnace:shibboleth:1.0:attributeNamespace:uri" isRequired="true"/>
<RequestedAttribute FriendlyName="eduPersonPrincipalName" Name="urnid:1.3.6.1.4.1.5923.1.1.1.6" NameFormat="urnasis:names:tc:SAML:2.0:attrname-format:uri" isRequired="true"/>
<RequestedAttribute FriendlyName="givenName" Name="urnace:dir:attribute-def:givenName" NameFormat="urnace:shibboleth:1.0:attributeNamespace:uri" isRequired="true"/>
<RequestedAttribute FriendlyName="givenName" Name="urnid:2.5.4.42" NameFormat="urnasis:names:tc:SAML:2.0:attrname-format:uri" isRequired="true"/><RequestedAttribute FriendlyName="sn" Name="urnace:dir:attribute-def:sn" NameFormat="urnace:shibboleth:1.0:attributeNamespace:uri" isRequired="true"/><RequestedAttribute FriendlyName="sn" Name="urnid:2.5.4.4" NameFormat="urnasis:names:tc:SAML:2.0:attrname-format:uri" isRequired="true"/>
<RequestedAttribute FriendlyName="mail" Name="urnace:dir:attribute-defail" NameFormat="urnace:shibboleth:1.0:attributeNamespace:uri" isRequired="true"/><RequestedAttribute FriendlyName="mail" Name="urnid:0.9.2342.19200300.100.1.3" NameFormat="urnasis:names:tc:SAML:2.0:attrname-format:uri" isRequired="true"/><RequestedAttribute FriendlyName="dfnEduPersonBranchAndDegree" Name="urnid:1.3.6.1.4.1.22177.400.1.1.3.9" NameFormat="urnasis:names:tc:SAML:2.0:attrname-format:uri" isRequired="false"/>[/src]
Es gibt einen sprechenden Namen (FriendlyName), dann noch eine genaue Beschreibung, was damit gemeint ist (Name) und das Format (NameFOrmat). MACE-Dir hat z.B. ein Schema erstellt (also wie Attribute heißen, wie sie ausschauen sollen) und genau dieses Schema wird stellenweise referenziert. isRequired ist so eine Sache. In anderen Ländern wird diese Info immer angegeben bzw. angefragt, hierzulande dürften eigentlich nur Attribute angefragt werden, die unbedingt zum Funktionieren eines Dienstes benötigt werden.
Und noch ein Beispiel eines IDPs (genauer gesagt AA, aber sieht wie IDP aus, ebenfalls gekürzt).
[src=xml]<EntityDescriptor entityID="https://aai-integration.dfn.de/idp/shibboleth">
<Extensions>
<mdrpi:RegistrationInfo registrationAuthority="https://www.aai.dfn.de" registrationInstant="2014-02-09T13:52:03Z">
<mdrpi:RegistrationPolicy xml:lang="en">https://www.aai.dfn.de/en/join/</mdrpi:RegistrationPolicy>
<mdrpi:RegistrationPolicy xml:lang="de">https://www.aai.dfn.de/teilnahme/</mdrpi:RegistrationPolicy>
</mdrpi:RegistrationInfo>
<mdattr:EntityAttributes>
<saml:Attribute Name="http://aai.dfn.de/loa/degree-of-reliance" NameFormat="urnasis:names:tc:SAML:2.0:attrname-format:uri"> <saml:AttributeValue>advanced</saml:AttributeValue>
</saml:Attribute>
</mdattr:EntityAttributes>
</Extensions>
<IDPSSODescriptor protocolSupportEnumeration="urnasis:names:tc:SAML:2.0rotocol">
<Extensions>
<saml1md:Scope regexp="false">testscope.dfn.de</saml1md:Scope>
<mdui:UIInfo>
....<mdui:Logo height="130" width="236">https://www.aai.dfn.de/fileadmin/pics/dfn_big.png</mdui:Logo></mdui:UIInfo>
</Extensions>
<KeyDescriptor>....
<AttributeService Binding="urnasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://aai-integration.dfn.de:8443/idp/profile/SAML2/SOAP/AttributeQuery"/><NameIDFormat>urnasis:names:tc:SAML:2.0:nameid-format:transient</NameIDFormat><NameIDFormat>urnasis:names:tc:SAML:2.0:nameid-formatersistent</NameIDFormat></AttributeAuthorityDescriptor>....[/src]
Statements
Die Benutzerinformationen werden über Statements ausgetauscht:
- Authentication Statement: Zusicherung, dass ein eindeutig identifizierbarer Nutzer sich zu einer bestimmten Zeit authentifiziert hat.
- Attribute Statement: Die vom SP angeforderten Attribute über einen Nutzer werden häufig im Anschluss an das Authentication Statement durch den IdP versendet.
- Authorization Decision Statement: Der IdP definiert in dieser Antwort, ob ein bestimmter Nutzer autorisiert ist eine bestimmte Handlung durchzuführen oder auf eine festgelegte Ressource zuzugreifen.
Vor- und Nachteile, sowie Tendenz
Vorteile: durch die festen Föderationen hat man strenge Regeln, wer mitmachen darf und wer nicht. Meist gibts vorher Verträge, Bedingungen, die man erfüllen muss usw.
Nachdem es jahrelang im Einsatz hat, ist es in gewissem Grad erprobt.
Es gibt einige Open Source Implementierungen und läuft mittlerweile auch bei großen Föderationen.
Durch den Aufbau kann man SAML auf viele Anwendungsfälle anpassen oder die passenden Bindings und Profiles aussuchen.
Nachteile: Durch die unterschiedlichen Bindings und Profiles kann es sein, dass SAML untereinander inkompatibel ist (eduGAIN-STORK geht nur über Proxys).
Mobil ist eine Katastrophe mit SAML.
Dynamisch geht auch eher wenig, auch wenn es einzelne Konzepte und Proof of Concept Implementierungen gibt.
Manche Implementierungen will man einfach nicht anfassen.
Tendenz: Weg von SAML zu OpenID Connect, wobei SAML sicherlich noch jahrelang existieren wird.
Ein paar Unterschiede:
SAML | OAuth/OIDC |
Identity Provider und Service Provider | OpenID Provider und Relying Party |
XML | JSON |
HTTP GET, HTTP POST, SAML SOAP usw. | HTTP POST und GET |
Feste Föderationen | Dynamische Verbindungen |
Web, größere feste Verbände | Web, Apps, alles was dynamisch ist |
Authentifizierung+Autorisierung | Autorisierung bzw. +Autorisierung |
Tipps
Wer mal SAML ein wenig sehen will, dem empfehle ich das Plugin SAML Tracer für Firefox. Damit kann man den Nachrichtenablauf und den Inhalt (wenn nicht verschlüsselt) sehen. Für Chrome gibts SAML DevTools.
Wer nicht schlafen kann, dem kann ich die SAML-Spezifikationen empfehlen
Zuletzt bearbeitet: