Ergebnis 1 bis 7 von 7

Thema: SAML, OAuth und OIDC

  1. #1
    in Schwarz

    Moderator

    Avatar von LadyRavenous
    Registriert seit
    Dec 2016
    Ort
    hello world
    Beiträge
    2.707
    ngb:news Artikel
    79

    SAML, OAuth und OIDC

    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.
    • 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.

    Code (XML):
    1. <EntityDescriptor entityID="http://shibboleth.ebscohost.com">
    2. <Extensions>
    3.  <mdrpi:RegistrationInfo registrationAuthority="https://www.aai.dfn.de" registrationInstant="2009-05-26T08:35:28Z">
    4.   <mdrpi:RegistrationPolicy xml:lang="en">https://www.aai.dfn.de/en/join/</mdrpi:RegistrationPolicy>
    5.   <mdrpi:RegistrationPolicy xml:lang="de">https://www.aai.dfn.de/teilnahme/</mdrpi:RegistrationPolicy>
    6.  </mdrpi:RegistrationInfo>
    7. </Extensions>
    8. <SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:1.1:protocol urn:oasis:names:tc:SAML:2.0:protocol">
    9.  <Extensions>
    10.   <idpdisc:DiscoveryResponse Binding="urn:oasis:names:tc:SAML:profiles:SSO:idp-discovery-protocol" Location="https://shibboleth.ebscohost.com/Shibboleth.sso/Login" index="1"/>
    11.   <mdui:UIInfo><mdui:DisplayName xml:lang="de">EBSCO Information Services/EBSCO Publishing</mdui:DisplayName>
    12.   <mdui:DisplayName xml:lang="en">EBSCO Information Services/EBSCO Publishing</mdui:DisplayName>
    13.   <mdui:Description 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.</mdui:Description>
    14.   <mdui:Description 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.</mdui:Description>
    15.   <mdui:InformationURL xml:lang="de">http://www.ebscohost.com</mdui:InformationURL>
    16.   <mdui:InformationURL xml:lang="en">http://www.ebscohost.com</mdui:InformationURL>
    17.  </mdui:UIInfo>
    18. </Extensions>
    19. <KeyDescriptor use="signing">
    20.  <ds:KeyInfo>
    21.  <ds:KeyName>shibboleth.ebscohost.com</ds:KeyName>
    22.  <ds:X509Data><ds:X509SubjectName>CN=shibboleth.ebscohost.com,O=EBSCO Industries Inc.,L=Birmingham,ST=Alabama,C=US</ds:X509SubjectName>
    23.  <ds:X509Certificate>MIIFjzCCBHegAwIBAgIJALgyIfD0A59WMA0GCSqGSIb3DQEBCwUAMIG0MQswCQYD....
    24. <AssertionConsumerService>
    25.  <Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post" Location="https://shibboleth.ebscohost.com/Shibboleth.sso/SAML/POST" index="0"/>
    26.  <AssertionConsumerService Binding="urn:oasis:names:tc:SAML:1.0:profiles:artifact-01" Location="https://shibboleth.ebscohost.com/Shibboleth.sso/SAML/Artifact" index="1"/>
    27.  <AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://shibboleth.ebscohost.com/Shibboleth.sso/SAML2/POST" index="2"/>
    28.  <AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign" Location="https://shibboleth.ebscohost.com/Shibboleth.sso/SAML2/POST-SimpleSign" index="3"/>
    29.  <AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location="https://shibboleth.ebscohost.com/Shibboleth.sso/SAML2/Artifact" index="4"/>
    30.  <AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" Location="https://shibboleth.ebscohost.com/Shibboleth.sso/SAML2/ECP" index="5"/></SPSSODescriptor>
    31. <Organization>
    32.  <OrganizationName xml:lang="de">e55</OrganizationName>
    33.  <OrganizationName xml:lang="en">e55</OrganizationName>
    34.  <OrganizationDisplayName xml:lang="de">EBSCO Publishing</OrganizationDisplayName>
    35.  <OrganizationDisplayName xml:lang="en">EBSCO Publishing</OrganizationDisplayName>
    36.  <OrganizationURL xml:lang="de">http://www.ebsco.com</OrganizationURL>
    37.  <OrganizationURL xml:lang="en">http://www.ebsco.com</OrganizationURL>
    38. </Organization>
    39. ...
    40. </EntityDescriptor>
    Die angefragten Attribute können so ausschauen:

    Code (XML):
    1. <RequestedAttribute FriendlyName="eduPersonScopedAffiliation" Name="urn:mace:dir:attribute-def:eduPersonScopedAffiliation" NameFormat="urn:mace:shibboleth:1.0:attributeNamespace:uri" isRequired="true"/>
    2. <RequestedAttribute FriendlyName="eduPersonScopedAffiliation" Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.9" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" isRequired="true"/>
    3. <RequestedAttribute FriendlyName="eduPersonPrincipalName" Name="urn:mace:dir:attribute-def:eduPersonPrincipalName" NameFormat="urn:mace:shibboleth:1.0:attributeNamespace:uri" isRequired="true"/>
    4. <RequestedAttribute FriendlyName="eduPersonPrincipalName" Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" isRequired="true"/>
    5. <RequestedAttribute FriendlyName="givenName" Name="urn:mace:dir:attribute-def:givenName" NameFormat="urn:mace:shibboleth:1.0:attributeNamespace:uri" isRequired="true"/>
    6. <RequestedAttribute FriendlyName="givenName" Name="urn:oid:2.5.4.42" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" isRequired="true"/><RequestedAttribute FriendlyName="sn" Name="urn:mace:dir:attribute-def:sn" NameFormat="urn:mace:shibboleth:1.0:attributeNamespace:uri" isRequired="true"/><RequestedAttribute FriendlyName="sn" Name="urn:oid:2.5.4.4" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" isRequired="true"/>
    7. <RequestedAttribute FriendlyName="mail" Name="urn:mace:dir:attribute-def:mail" NameFormat="urn:mace:shibboleth:1.0:attributeNamespace:uri" isRequired="true"/><RequestedAttribute FriendlyName="mail" Name="urn:oid:0.9.2342.19200300.100.1.3" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" isRequired="true"/><RequestedAttribute FriendlyName="dfnEduPersonBranchAndDegree" Name="urn:oid:1.3.6.1.4.1.22177.400.1.1.3.9" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" isRequired="false"/>
    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).

    Code (XML):
    1. <EntityDescriptor entityID="https://aai-integration.dfn.de/idp/shibboleth">
    2. <Extensions>
    3.  <mdrpi:RegistrationInfo registrationAuthority="https://www.aai.dfn.de" registrationInstant="2014-02-09T13:52:03Z">
    4.  <mdrpi:RegistrationPolicy xml:lang="en">https://www.aai.dfn.de/en/join/</mdrpi:RegistrationPolicy>
    5.  <mdrpi:RegistrationPolicy xml:lang="de">https://www.aai.dfn.de/teilnahme/</mdrpi:RegistrationPolicy>
    6. </mdrpi:RegistrationInfo>
    7. <mdattr:EntityAttributes>
    8.  <saml:Attribute Name="http://aai.dfn.de/loa/degree-of-reliance" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">    <saml:AttributeValue>advanced</saml:AttributeValue>
    9. </saml:Attribute>
    10. </mdattr:EntityAttributes>
    11. </Extensions>
    12. <IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
    13. <Extensions>
    14. <saml1md:Scope regexp="false">testscope.dfn.de</saml1md:Scope>
    15. <mdui:UIInfo>
    16. ....<mdui:Logo height="130" width="236">https://www.aai.dfn.de/fileadmin/pics/dfn_big.png</mdui:Logo></mdui:UIInfo>
    17. </Extensions>
    18. <KeyDescriptor>....
    19. <AttributeService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://aai-integration.dfn.de:8443/idp/profile/SAML2/SOAP/AttributeQuery"/><NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</NameIDFormat><NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</NameIDFormat></AttributeAuthorityDescriptor>....
    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
    Für diesen Beitrag bedankt sich poesie noire
    Geändert von LadyRavenous (07.12.17 um 13:41 Uhr)
    "Das Internet? Gibts diesen Blödsinn immer noch?"
    Homer Simpson, Sicherheitsinspektor im Kernkraftwerk Springfield

    Hasenbraten-Rezepte

  2. #2
    in Schwarz

    Moderator

    (Threadstarter)

    Avatar von LadyRavenous
    Registriert seit
    Dec 2016
    Ort
    hello world
    Beiträge
    2.707
    ngb:news Artikel
    79

    Re: SAML, OAuth und OIDC

    SAML in Webanwendungen kann teils noch ein ziemliches gefrickel sein. Meist sind die IdPs leichter aufzusetzen.

    In einiger Software gibts aber auch schon Erweiterungen genau dafür.

    • Bei Powerfolder wars, wenn ich mich erinnere, noch etwas nervige Konfigurierarbeit nötig.
    • Bei VMWare habe ich auch von der Möglichkeit gehört,
    • bei gitlab ist es inzwischen auch integriert,
    • ebenso bei ownCloud (neben OAuth2)


    um ein paar zu nennen. Falls es euch begegnen sollte, wisst ihr jetzt zumindest, wofür es steht, auch wenn es für euch nicht relevant sein sollte.
    Zum Glück gibts im Netz ein paar Testserver.
    Für diesen Beitrag bedankt sich poesie noire
    "Das Internet? Gibts diesen Blödsinn immer noch?"
    Homer Simpson, Sicherheitsinspektor im Kernkraftwerk Springfield

    Hasenbraten-Rezepte

  3. #3
    in Schwarz

    Moderator

    (Threadstarter)

    Avatar von LadyRavenous
    Registriert seit
    Dec 2016
    Ort
    hello world
    Beiträge
    2.707
    ngb:news Artikel
    79

    Re: SAML, OAuth und OIDC

    OAuth

    Die Entwicklung von OAuth startete Blaine Cook 2006; 2007 gab es bereits die erste Spezifikation von OAuth Core 1.0. Seitdem wird OAuth in einer Working Group der IETF weiterentwickelt. OAuth 2.0 ist ein Framework, welches durch RFC6749 sowie RFC6750 spezifiziert ist. Das Protokoll erlaubt es Nutzern Dritten, wie Service Providern (die im OAuth Sprech Relying Party heißen) und Consumern, Zugriff auf private Ressourcen zu geben. Die standardisierten Nachrichten basieren auf JavaScript Object Notation (JSON) zum Datenaustausch und dem Übertragungsprotokoll HTTP. OAuth stellt somit einen Standard für Entwickler zu Verfügung, damit diese ihre Dienste über eine API an Nutzer bereitstellen, ohne dass diese ihr Passwort offen legen müssen.

    OAuth basiert auf einem Kern, bestehend aus OAuth 2.0 Framework und einer Beschreibung des Bearer Tokens. Dieser Kern kann entsprechend des Anwendungsgebiets erweitert werden. Recht häufig verwendet wird das JSON Web Token. Im Endeffekt gibts verschiedene Workflows, vor allem explizit und implizit, wodurch der Nutzer dann den Zugriff gewährt.

    Protokolle, die auf OAuth aufbauen:

    • Open ID Connect
    • UMA
    • IndieAuth
    • Green Button
    • Blue Button (obsolet)


    Was ich faszinierend finde, ist der Code, den es zu OAuth gibt. Im Endeffekt gibt es für die geläufigen Programmiersprachen Libraries für Server und Client, die man verwenden kann.
    Den Kurs von rohe auf github zu OAuth, OIDC und UMA kann ich übrigens empfehlen, allerdings fehlt halt die Tonspur. Dafür beschreibt er auch aktuelle Drafts der Working Group (also, aus der Idee von einem oder mehreren wird erst ein Draft geschrieben. Nach mehreren Iterationen kann daraus ein RFC werden. Dauer von dem Verfahren je nachdem zwischen wenigen Monaten und mehreren Jahren, letzteres ist üblicher).
    Interessant sind auch die Security Threats. Je nachdem welche Implementierung man nimmt, kann man da schon Lücken haben. Dann kommt es auch darauf an, wie man die Software konfiguriert und außerdem wurden beim Design auch ein paar mögliche Angriffe gelassen, beschrieben in einem extra Dokument (bei der IETF brauchts für jeden Draft und jedes RFC einen Security-Abschnitt. Wenns länger wird, gerne auch ein eigenes Dokument).

    Ich muss mal schauen, ob ich ein wenig detaillierter in die Workflows von OAuth gehe. Ich persönlich finde OIDC und UMA interessanter.
    Für diesen Beitrag bedankt sich poesie noire
    "Das Internet? Gibts diesen Blödsinn immer noch?"
    Homer Simpson, Sicherheitsinspektor im Kernkraftwerk Springfield

    Hasenbraten-Rezepte

  4. #4
    in Schwarz

    Moderator

    (Threadstarter)

    Avatar von LadyRavenous
    Registriert seit
    Dec 2016
    Ort
    hello world
    Beiträge
    2.707
    ngb:news Artikel
    79

    Re: SAML, OAuth und OIDC

    OAuth Teil 2

    Workflow

    Standard:

    • User wants to use the photo service B.
    • User is forwarded to service A, where it authenticates
    • (Authorization Request). It is shown, which service wants to access which data.
    • User consents (Authorization Grant). Service A generates authorisation code (Authorization Token) and forwards it to service B. User is also forwarded to service B.
    • Service B asks service A for an access token.
    • Service A generates access token and forwards it to service B.
    • Service B sends consecutive requests to photos of service A with the access token.
    • Service A sends the protected pictures of the user to service B.


    Varianten:
    • Authorization Code Grant
    • Implicit Grant
    • Resource Owner Password Credentials Grant
    • Client Credentials Grant


    Standards

    OAuth 2.0 Core
    • OAuth 2.0 Framework - RFC 6749
    • Bearer Token Usage - RFC 6750
    • Threat Model and Security Considerations - RFC 6819

    OAuth 2.0 Extensions
    • OAuth 2.0 Device Flow
    • OAuth 2.0 Token Introspection - RFC 7662, to determine the active state and meta-information of a token
    • PKCE - Proof Key for Code Exchange, better security for native apps
    • Native Apps - Recommendations for using OAuth 2.0 with native apps
    • JSON Web Token - RFC 7519
    • OAuth Assertions Framework - RFC 7521
    • SAML2 Bearer Assertion - RFC 7522, for integrating with existing identity systems
    • JWT Bearer Assertion - RFC 7523, for integrating with existing identity systems


    JW*

    OAuth und auch OIDC basieren auf JSON-Files, die ausgetauscht werden, grob gesagt. Davon gibts:

    • JWT - JSON Web Token
    • JWS - JSON Web Signature
    • JWE - JSON Web Encryption
    • JWK - JSON Web Key
    • JWA - JSON Web Algorithms


    Besonders wichtig sind dabei die Tokens.

    Access Token: String = Autorisierung des Clients

    Code (Text):
    1.     {
    2.     'access_token':             ’s87BT60pp2UbNX2HnkWpfPfWNo9Gi7chACuWoa2IDND',
    3.     'expires_in': 3600,
    4.     'refresh_token': ’s87BT60pp2U+bNX2HnkWpVCnDYPsy8EOpI’
    5.     'state': ’STATE0’,
    6.     'token_type': 'Bearer',
    7.     }
    8.  
    Bearer Token: Security Token, was jeder mit einem Token (Bearer) verwenden kann

    Eine JSON Signature schaut so aus:
    Code (Text):
    1.  
    2.     {
    3.     "payload": “eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0…",
    4.     "signatures":[
    5.          {"protected":"eyJhbGciOiJSUzI1NiJ9",
    6.         ”header": {"kid":"2010-12-29"},
    7.         "signature":
    8.             "cC4hiUPoj9Eetdgtv3hF80EGrhuB__dzERat0XF9g2VtQgr9PJbu3XOiZj5RZ
    9.             mh7AAuHIm4Bh-0Qc_lF5YKt_O8W2Fp5jujGbds9uJdbF9CUAr7t1dnZcAcQjb
    10.             KBYNX4BAynRFdiuB--f_nZLgrnbyTyWzO75vRK5h6xBArLIARNPvkSjtQBMHl
    11.             b1L07Qe7K0GarZRmB_eSN9383LcOLn6_dO--xi12jzDwusC-eOkHWEsqtFZES
    12.             c6BfI7noOPqvhJ1phCnvWh6IeYI2w9QOYEUipUTI8np6LbgGY9Fs98rqVt5AX
    13.             LIhWkWywlVmtVrBp0igcN_IoypGlUPQGe77Rw"},
    14.         {"protected":"eyJhbGciOiJFUzI1NiJ9",
    15.         ”header": {"kid":"e9bc097a-ce51-4036-9562-d2ade882db0d"},
    16.         "signature":
    17.         ”DtEhU3ljbEg8L38VWAfUAqOyKAM6-Xx-F4GawxaepmXFCgf…."}]
    Software

    https://oauth.net/code/


    Extensions
    • Open ID Connect: Authentication
    • UMA: User-centric approach to manage accounts and permissions
    • IndieAuth
    • früher gabs noch was im Grid-Bereich


    Persönlich finde ich OIDC und UMA deutlich interessanter als OAuth, allerdings bauen beide darauf auf.
    "Das Internet? Gibts diesen Blödsinn immer noch?"
    Homer Simpson, Sicherheitsinspektor im Kernkraftwerk Springfield

    Hasenbraten-Rezepte

  5. #5
    in Schwarz

    Moderator

    (Threadstarter)

    Avatar von LadyRavenous
    Registriert seit
    Dec 2016
    Ort
    hello world
    Beiträge
    2.707
    ngb:news Artikel
    79

    Re: SAML, OAuth und OIDC

    OpenID Connect

    OpenID Connect (OIDC) baut auf OAuth 2 auf und sorgt für die Authentifizierung. Wichtigste Elemente sind eben diese Authentifizierung und der Claim. Claim ist praktisch eine Information über die Authentifzierung, meist in Form von Nutzerattributen. OIDC ermöglicht dem Client die Endnutzerverifikation über die Authentifizierung, die beim Authentizierungsserver aufläuft. Dies geschieht interoperable und REST-like.
    OIDC wird von Google, Amazon, Microsoft und vielen mehr verwendet.

    Unterschiede zu OAuth

    • Nur Authorization grant und implicit grant flows
    • Dynamischer Provider Discovery und Client Registration
    • ID Token
    • Additions/Clarifications/Constrictions
    • UserInfo endpoint


    Elemente

    • Core: Hauptfunktionalität
    • Discovery (Optional): Discovery Service
    • Dynamic Registration (Optional)
    • OAuth 2.0 Multiple Response Types
    • OAuth 2.0 Form Post Response Mode (Optional)
    • Session Management (Optional)
    • Front-Channel Logout (Optional)
    • Back-Channel Logout (Optional)



    Workflow

    • Relying Party (RP) is using OpenID Connect by adding the scope value openid to the authentication request.
    • This request is redirected to the OP.
    • The OP verifys the successful authentication with an authentication code.
    • The RP transforms the authentication code to a token.
    • The OP sends the id_token in the body of the request, which contains attributes and information about the authentication process. The JSON Web Token (JWT) can be signed.


    Dynamic Discovery

    Im Gegensatz zu SAML, wo die Metadaten der IdPs aggregiert werden, geschieht der Discovery bei OIDC dynamisch durch das Protokoll Webfinger.
    Find the provider: WebFinger
    User identifier: URL
    carol@ngb.to ->
    Code (Text):
    1.     GET /.well-known/webfinger?
    2.     resource=acct:carol@ngb.to&
    3.     rel=http://openid.net/specs/connect/1.0/issuer
    4.     Host: ngb.to
    Antwort: JSON
    Discover provider configuration
    GET /.well-known/openid-configuration HTTP/1.1
    Host: openid.example.com
    Register client information

    ID Token

    Security Token mit dem Claim über die Authentifzierung des Endnutzers an Autorisierungsserver und andere Claims, als JSON Web Token (JWT)
    Code (Text):
    1. {
    2. "iss":"https://accounts.ngb.to",
    3. "sub":"723423467677",
    4. "aud":"SDFGHJJKLSDFZTREDFGHJ",
    5. "exp":1388700360000,
    6. "iat":1388696760000,
    7. "auth_time":1388696760000,
    8. "acr":"urn:ngb:to:level−2„
    9. }
    Claims

    Es gibt mehrere Standardclaims und zudem Standardisierungsbemühungen zu anderen Claims.

    • sub
    • name, given_name,...
    • profile, picture
    • website
    • email, email_verified
    • gender, birthdate
    • zoneinfo, locale
    • phone_number,...
    • address
    • updated_at
    "Das Internet? Gibts diesen Blödsinn immer noch?"
    Homer Simpson, Sicherheitsinspektor im Kernkraftwerk Springfield

    Hasenbraten-Rezepte

  6. #6
    in Schwarz

    Moderator

    (Threadstarter)

    Avatar von LadyRavenous
    Registriert seit
    Dec 2016
    Ort
    hello world
    Beiträge
    2.707
    ngb:news Artikel
    79

    Re: SAML, OAuth und OIDC

    Security

    Wenn man Protokolle z.B. für die IETF schreibt (bzw. an einem Draft dran sitzt), dann beschreibt man auch die Security Implications. Bei SAML wurden beispielsweise viele Sicherheitsrisiken einfach hingenommen. Vieles wird durch Policies und andere Regelwerke versucht beizukommen. Bei OAuth und OIDC gibts auch einiges. Zudem können durch missglückte Implementierungen und Konfigurationen auch Probleme entstehen. Ich bin mal so frei und paste einfach die englischen Inhalte mal rein.

    OAuth: Specification Flaws

    • RFC6819 https://tools.ietf.org/html/rfc6819 (PDF has 71 pages!)
    • Malicious endpoints attacks
    • Broken end-user authentication
    • Server side Request Forgery (SSRF)
    • Code injection attacks
    • Denial-of-Sevice (DoS) attacks
    • Session Overwriting


    Implementation Flaws

    Client flaws
    • Replay attacks
    • Signature Manipulation
    • Token Recipient Confusion
    • ID Spoofing
    • Key Confusion
    • Sub Claim spoofing within the access token


    Identity Provider flaws
    • Sub Claim spoofing
    • Redirect URI Manipulation


    Replay Attack

    Header:
    Code (Text):
    1.  { "alg": "HS256" }
    2.  
    Body:
    Code (Text):
    1. {
    2. "iss": "http://openidConnectProvider.com/",
    3. "sub": ”user1",
    4. "exp": 1444148908,
    5. "iat": 1444148308,
    6. "nonce": "40c6b33b9a2e",
    7. "aud": "http://client.com/",
    8. }
    Signature:
    Code (Text):
    1. AF45JF93LKD76D...
    2.  
    Signature Manipulation

    Token Recipient Confusion

    Header:
    Code (Text):
    1. { "alg": "HS256" }
    2.  
    Body:
    Code (Text):
    1. {
    2. "iss": "http://openidConnectProvider.com/",
    3. "sub": ”user1",
    4. "exp": 1444148908,
    5. "iat": 1444148308,
    6. "nonce": "40c6b33b9a2e",
    7. "aud": „another client“,
    8. }
    Signature:
    Code (Text):
    1. AF45JF93LKD76D...
    2.  
    ID Spoofing

    ID = sub : iss
    The combination of sub and iss are the only claims that the Client can rely upon as a stable identifier!

    Key Confusion

    Sub Claim Spoofing
    The sub Claim in the UserInfo Response MUST be verified to exactly match the sub Claim in the ID Token

    Redirect URI Manipulation
    "Das Internet? Gibts diesen Blödsinn immer noch?"
    Homer Simpson, Sicherheitsinspektor im Kernkraftwerk Springfield

    Hasenbraten-Rezepte

  7. #7
    in Schwarz

    Moderator

    (Threadstarter)

    Avatar von LadyRavenous
    Registriert seit
    Dec 2016
    Ort
    hello world
    Beiträge
    2.707
    ngb:news Artikel
    79

    Re: SAML, OAuth und OIDC

    Privatsphäre

    Muss sein

    • Social Platforms normally combine OAuth and OIDC
    • Facebook: login at more than 15.000 websites
    • Privacy comes down to what data third-party apps and websites can access, who can see that data, and how well you the user can control those apps and websites.
    • Apps: Review and revoke access
    • App data: different permissions, depends on the app and service
    • OP knows where you login, sometimes also data of the app
    "Das Internet? Gibts diesen Blödsinn immer noch?"
    Homer Simpson, Sicherheitsinspektor im Kernkraftwerk Springfield

    Hasenbraten-Rezepte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •