Zugriffskontrolle (SSO,JWT,SAML,XACML)

Einleitung

Zugriffskontrolle ( engl. access control ) soll die Authentizität (Wer ist das?) und Autorisierung (Darf der das?) von Nutzern bei Zugriff auf Ressourcen sicher stellen.

Single Sign On (SSO)

Durch die Proliferation von gemeinen Haushaltsgeräten mit integriertem Computer (umg. IoT-Geräte) ist die herkömmliche Zugriffskontrolle per Login- und Passwortabfrage unpraktisch. Das Ziel von Single Sign On soll dieses Problem lösen, indem Identitäten zentral verwaltet werden und diese genutzt werden kann um sich überall an- und abzumelden.

SSO Kernidee

Anders wie bei herkömmlichen Verbindung, bei der sich zwei verschiedene Domänen auf Grund der Same Origin Policy nicht eine Sitzung zu einem Nutzer teilen können, verwendet ein SSO-Kontext einen Identity Provider/SSO-Server über dem die Authentifizierung durchgeführt wird und dann die Sitzung mit den Service Providern teilt. Bei diesem Vorgang spricht man von Cross-Domain SSO. Somit hat der Nutzer das Gefühl, dass er sich bei nur einer Domäne authentifiziert hat und dann auf Ressourcen in der anderen Domäne zugreifen, ohne sich ein zweites Mal anmelden zu müssen.

SSO mit zentraler Authentifizierungsdomäne

Protokolle

SSO wird durch verschiedene Protokolle implementiert. Die weit verbreitesten sind SAML, OpenID, Auth0 und Facebook Connect. An all diese Protokolle werden folgende Anforderungen gestellt:

Erhöhte Sicherheit

Durch Verwendung von verschiedenen und starken Authentifizierungsverfahren, die Bereitstellung von Single Sign Off - die Beendingung der gesamten Sitzung mit nur einer einzigen Abmeldung – und Forced Renewal - erzwungene erneute Authentifizierung u.a. wenn der Nutzer sein Passwort wechselt - soll SSO sicher gemacht werden.

Integrationsmöglichkeiten von bestehenden Systemen

SSO Frameworks bieten verschiedene Adapter an um die verschiedenen Bausteine eines Systems zu einem SSO-Kontext zu integrieren. Zugang zu Nutzerdaten wie Login,Passwort, Zertifikate für die Authentifizierung und Rollenzuweisung erhält der SSO-Server über Connectors zu Datenbanken und Vereichnisdienste. Anwendungen können mit Hilfe von SSO-Agents mit dem SSO Server kommunizieren.

Robustheit und Administrierbarkeit

Durch die Abhängigkeit vieler verschiedener Anwendungen von einem SSO-Server muss dieser sehr robust und leicht zu administieren sein.

Vorteile und Nachteile

Vorteile

Dem Kerngedanken von Smart Homes und IoT entsprechend erspahrt SSO Nutzern viel Zeit und Aufwand, da er sich nicht auf den verschiedenen Anwendungen an-und wieder abmelden muss. Dem Nutzer reicht es sich ein Passwort zu merken, sodass dieses zu hoher Wahrscheinlichkeit komplexer und somit sicherer ist, als dass er sich viele verschiedene unsichere merkt. Auch eine einzige Übertragung von Passwort und Kenndaten bietet eine kleinere Angriffsfläche als mehrere. Der SSO Server ist verantwortlich für die Authentifizierung, sodass auch sichere Sitzungen mit IoT-Geräten möglich sind, die nicht genug Energie, Rechenkapazität oder Speicherplatz haben um komplexe Authentifizierungsalgorithmen durchführen zu können. Durch den Zusammenschluss mehrerer Domänen innerhalb eines SSO-Kontextes enfällt die fehleranfällige und zeitraubende Konfiguration mehrerer Kennungen an unterschiedlichen Datenbanken.

Nachteile

Der Zusammenschluss mehrerer Identitäten bringt auch ein erhöhtes Risiko mit sich. Diebstahl der SSO-Identität erlaubt den Täter Zugriff auf viele verschiedene Systeme und der SSO-Anbieter kann die Abfolge der besuchten Services unbefugt mitverfolgen und die Daten zweckentfremden. Außerdem ist die Verfügbarkeit der verschiedenen Services/Ressourcen nicht nur von der eigenen Verfügbarkeit abhängen sondern zusätzlich von der Zuverlässlichkeit des SSO-Systems.

SAML/XACML

Die Security Assertion Markup Language (SAML) ist ein XML-Framework zum Austausch von Authentifizierungs- und Autorisierungsinformationen. Sie stellt Funktionen bereit, um sicherheitsbezogene Informationen zu beschreiben und zu übertragen. SAML wurde ab 2001 von dem OASIS-Konsortium entwickelt. Zu diesem Konsortium gehören Unternehmen wie Sun Microsystems (übernommen von Oracle), IBM, Nokia und SAP. Bei SAML gibt es zwei wesentliche Rollen die zusammenspielen müssen. Den Identity Provider und den Service Provider

Identity Provider (IdP)

Dieser stellt den Authentifizierungsdienst dar, der dem Benutzer eine Anmeldemaske zur Verfügung stellt. Der IdP hat eine Verbindung zu einem Benutzer Verzeichnis (z.B. LDAP oder Microsoft Active Directory). Nach erfolgreicher Anmeldung durch den Benutzer wird dieser zum gewünschten Service Provider weitergeleitet.

Service Provider (SP)

Dieser stellt den Dienst (meist Webdienste wie z.B. eMail) zur Verfügung. Um diesen Dienst nutzen zu können, müssen sich Benutzer authentifizieren. Die Authentifizierung wird vom IdP übernommen.

Ablauf einer Authentifzierung mittels SAML

1. Wenn der Anwender Zugriff auf eine Ressource eines Service erhalten möchte – egal, ob intern oder extern – stellt er einen GET-Request an den Service, z.B. www.mail.org/login.

2. Von dem Service erhält er einen Redirect an den SingleSignOnService Link des Identity Providers. Dieser Redirect enthält die samlp:authnRequest, die vom Identity Provider unterzeichnet werden soll.

3. Der Browser des Anwenders ruft also den SingleSignOnService Link des Identity Providers auf und reicht die samlp:authnRequest ein.

4. Anschließend muss sich der Anwender authentifizieren und erhält dann...

5. ... eine samlp:response in Form eines XHTML Formulars zurück. Dieses XHTML Formular enthält unter anderem den AssertionConsumerService Link, den der User Agent des Browsers verwenden kann, um...

6. einen POST-Request an den Service Provider des Services zu stellen.

7. Der Service Provider erstellt nun einen Security Context und...

8. leitet den Anwender per Redirect weiter an die ursprüngliche Login-URL und, da ein Security Context existiert, auch an weitere Ressourcen des Services.

SAML - Assertions

Eine SAML assertion enthält Aussagen der Form:

<saml:Assertion ...>
  ...
</saml:Assertion>

Diese Aussagen beschreiben Fakten, die sich auf ein Subjekt beziehen:

Assertion A wurde zur Zeit t von Prüfer R bezüglich Subjekt S unter der Bedingung C geprüft.

SAML assertions werden vom Identity Provider zum Service Provider übertragen. Assertions sind Aussagen (statements), die ein Service Provider nutzt, um über das Zulassen eines Zugriffs zu entscheiden. Drei Typen von statements werden von SAML genutzt:

- Authentication Statements (welche Authentifizierung, wann und mittels welcher Auth-Methode)

- Attribute Statements (Attribute z.B. Username)

- Authorization Decision Statements (erlauben / blockieren)

SAML - Protokolle

Die Protokolle dienen zur Kommunikation zwischen IdP und SP. Folgende Protokolle sind dafür notwendig:

Authentication Request Protocol

Das Authentication Request Protocol wird verwendet, um Assertions über den Benutzer vom Identity Provider zu erhalten. Ziel ist es, einen Security Context mit dem Service Provider zu etablieren. Dieses Protokoll wird im weit verbreiteten Web Browser SSO Profile verwendet.

Json Web Token (JWT)

JSON Web Token sind ein kompaktes, URL-kodierbares Nachrichtenformat, welches zum Ziel hat "Claims" über die Identität einer Einheit sicher zu übertragen. Die Übertragung geschiet meißt über HTTP über den Authorization Bearer Header als Bearer Token dh wer den Token besitzt, rechtmäßig oder nicht, kann ihn verwenden. Für eine erhöhte Sicherheit kann der Token mit Proof of Possession übertragen werden, sodass die angefragen Service Providers sicher sein können, dass die Requests mit dem angehängten Token auch wirklich von der gleichen Entität kommt, die den Token ursprünglich verlangt hat. JWT sind seit 2011 Teil des RFC. Diese enthält auch eine Spezifizierung zu JWA- Json Web Algorithms, die kryptographischen Algorithmen – symmetrisch oder asymmetrisch, die für Signierung oder Verschlüsselung eines Tokens werden.

Struktur

JWT bestehen aus einen Header und einen Payload Teil, in denen sich jeweils key : value Paare als Parameter befinden. Welche Paramter angegeben werden und die restliche Struktur ist abhängig davon, ob es sich um ein signiertes oder ein verschlüsseltes JWT handelt.

Header

Der Header eines JWT ist ein JSON Object und ist immer von type : „jwt“. Die verschiedenen Parameter können hier eingesehen werden. Der Header wird auch als JOSE-Header bezeichnet.

Payload

Der Payload eines JWT ist ein JSON Object und enthält die Claims dh die Behauptungen, die über die Identität einer Einheit aufgestellt werden, und zusätzliche Metadaten zu dem Token. Jede Anwendung definiert für sich, welche Claims optional sind und welche nicht. Es gibt 3 Arten von Claims: die Reserved Claims, die die im RFC vordefiniert und empfohlen sind, die Public Claims, welche öffentlich registirert oder als UUID oder URI definiert sein müssen , und die Private Claims - Parameter auf die sich die Beteiligten im Vorraus geeinigt haben. Die wichtigsten Claims sind: issuer: der Ersteller des Tokens subject: die Einheit die identifiziert wird expiration time, not before: der Zeitabschnitt, in dem das Token gültig ist audience: Menge an Einheiten für die das Token vorbehalten ist

JWS

Ein signiertes Token besteht neben dem Header und dem Payload aus einer Signatur, die die Intergrität des Tokens sichert. Sie wird berechnet aus dem Header und Payload mit Hilfe eines JWA, gesetzt als Paramter im Header. Die Signatur fungiert beim Dekodieren als Verifikation, dass der Inhalt nicht verändert wurde und als Authentifizierung des Ersteller des Tokens, da nur dieser das MAC oder den privaten Schlüssel passend zum JWA kennt. Ist kein „alg“ Paramter gesetzt, so bezeichnet man das Token als unsigniertes JWS und sollte für die Übertragung TLS benutzen. Header, Payload und Signatur werden jeweils Base64 codiert und mit jeweils einem Punkt konkateniert – bezeichnet als JWS CompactSerialization, sodass die letzendliche Darstellung des Tokens ein kompakter URL-safer String ist: BASE64URL(UTF8(JWS Protected Header)) || ‘.’ || BASE64URL(JWS Payload) || ‘.’ || BASE64URL(JWS Signature) Eine weiter Option der Darstellung ist die JSON Serialisierung, die jedoch weder kompakt noch URL safe ist, aber die Möglichkeit bereitstellt, für die verschiedenen Empfänger angepasste Signaturen zu erstellen.

Beispiel JWS

Header mit Signatur- oder Verschlüsselungsalgorithmus (hier HMAC SHA256) und dem Typ des Tokens (hier JWT)

{
 "alg": "HS256",
 "typ": "JWT"
}

Payload besteht hier aus Subject, Name und Issued At Zeitstempel:

{
 "sub": "1234567890",
 "name": "John Doe",
 "iat": 1516239022
}

Signatur besteht aus:

HMACSHA256(
 base64UrlEncode(header) + "." +
 base64UrlEncode(payload),
 Passw0rt1234
)

Dies generiert das Token:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.
WetwNp0BkAboJQMpyRPNJ2MiVw5Af-Iyt3mU1DX_GiY

JWE

Bei der JWE-Darstellung handelt es sich um ein verschlüsseltes Token, um die Vertraulichkeit des Tokens zu sichern. Dieser besteht aus drei Teilen: einem Header, der unverschlüsselt ist und unteranderem im „enc“ und im „alg“ Feld jweils einen JWA angibt, einen CEK - Content Encrypion Key, verschlüsselt mit dem JWA angegeben in „alg“ - und dem Payload, verschlüsselt mit dem CEK und einem zufällig generiertem Initialisierungvektor. Der Token kann nur von ausgewählten Einheiten entschlüsselt werden, da nur diese den CEK dekodieren können. Um die Integrität des JWE zu sichern, kann dieses als geschachteltes Token signiert werden, oder zur Verschlüsselung des Payloads wird ein AEAD Algorithmus verwendent, da diese auch auf Integrität und Authentiziät der Daten prüft. Die jeweiligen Teile werden jeweils Base64 codiert und mit jeweils einem Punkt konkateniert – bezeichnet als JWE CompactSerialization, sodass die letzendliche Darstellung des Tokens ein kompakter URL-safer String ist: BASE64URL(UTF8(JWE Protected Header)) || '.' || BASE64URL(JWE Encrypted Key) || '.' || BASE64URL(JWE Initialization Vector) || '.' || BASE64URL(JWE Ciphertext) || Falls ein AHEAD Algorithmus verwendet wurde, wird der Token um '.' || BASE64URL(JWE Authentication Tag) verlängert.

Eigentschaften

JWTs sind „self-contained“, dh. alle Informationen, die man über die Identität benötigt, passen in den Token, sodass die Einheit, die diesen erhält keine Anfrage an eine Datenbank stellen muss. Auf Grund der Kodierung ist die Darstellung der Token ist kompakt und „URL-safe“. Die Token sind Cross-Domain einsetzbar und „stateless“, dh. der Service Provider muss sich nicht den Zustand des Nutzers merken, solange er keine Black- oder Whitelist führt. Die Signatur sorgt für Integrität und Authentifizierung und die Verschlüsselung für Vertraulichkeit.

Verwendung

Auf Grund der benannten Eigenschaften sind JWT gut geeignet für die Authentifizierung im Web: der Client wird von einem Server einmal authentifizeirt und erhält von diesem ein entsprechendes Token, welches nur der Client sich speichert und in jedem Request mitschickt. Somit können über einen unsicheren Kanal sicher Daten ausgetauscht werden. Protokolle die JWTs zum Beispiel verwenden sind OpenID Connect.

Minimum Working Example

In einem minimum working example soll das Zusammenspiel der im Artikel besprochenen Elemente vergegenwärtigt werden. Die Architektur basiert auf der vorgestellten SAML-XACML Architektur, wobei nur der Policy Decicision Point, die Policy Enforcement Points und der Identity Provider implementiert werden. Zusätzlich wurden der SAML Prozess durch einen JWT-basierten Tokenaustausch ersetzt. Der Messageaustausch geschieht durch HTTP REST.

Setup

1. Code laden von github

2. Requirements laut Readme.md installieren

Beispielablauf eines Servicerequests

JWT holen

POST gegen den Registrierungsendpunkt oder Loginendpunkt des IDP:

POST /login HTTP/1.1
Host: 127.0.0.1:3000
Content-Type: application/x-www-form-urlencoded
Cache-Control: no-cache

username=stepo&password=stepo

Antwort mit Json Web Token im Payload:

HTTP/1.1 200
status: 200
content-type: application/json
content-length: 610

{"message": "Logged in as stepo", "access_token": 
"eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpYXQiOjE1MzcwOTcxNTYsIm5iZiI6MTUzNzA5NzE1NiwianRpIjoi
NGI1ZjY2M2ItNTRkMi00NzY2LTkxOWUtNThlZjdhZGUxZDljIiwiZXhwIjoxNTM3MDk4MDU2LCJpZGVudGl0eSI6InN0ZX
BvIiwiZnJlc2giOmZhbHNlLCJ0eXBlIjoiYWNjZXNzIn0.QCtGHX4odS5togFgnJnPlNWfum5SWJkud2yXwA_xnE4", 
"refresh_token":  "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpYXQiOjE1MzcwOTcxNTYsIm5iZiI6MTUzNz
A5NzE1NiwianRpIjoiNGYwODgwOTEtOThjMi00MWVhLWFmZmUtN2U1N2JlYTY5MjU2IiwiZXhwIjoxNTM5Njg5MTU2LCJp
ZGVudGl0eSI6InN0ZXBvIiwidHlwZSI6InJlZnJlc2gifQ.H9SqGRcY5RKla23jcp_lNUUflsfepHCfbkPaahGxTSU"}

Service Anfragen mit JWT

POST gegen Serviceendpunkt:

POST /protected_toaster HTTP/1.1
Host: 127.0.0.1:4000
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpYXQiOjE1MzcwOTY2NjksIm5iZiI6MTU
zNzA5NjY2OSwianRpIjoiZmZhNDlmZGMtMTJhNC00OTk1LTk5NjctMmVkOTc2NDUyNzM3IiwiZXhwIjoxNTM3MDk3NTY5L
CJpZGVudGl0eSI6InN0ZXBvIiwiZnJlc2giOmZhbHNlLCJ0eXBlIjoiYWNjZXNzIn0.egBiDeU2IC4hb7hBoUVGkAbo-c4
_UYCrisAJreLVIuM
Cache-Control: no-cache

Serviceendpunkt schickt POST gegen Policy Decision Point für eine Autorisierung:

POST /services/pdp HTTP/1.1
Host: localhost:10000
Content-Type: application/xacml+json
Cache-Control: no-cache

{"Request":{"ReturnPolicyIdList":false,"CombinedDecision":false,"Category":[
  {"CategoryId":"urn:oasis:names:tc:xacml:1.0:subject-category:access-subject","Attribute":[{"IncludeInResult":false,"AttributeId":"urn:oasis:names:tc:xacml:1.0:subject:subject-id","DataType":"http://www.w3.org /2001/XMLSchema#string","Value":[
      "stepo"
    ]}]}
  ,{"CategoryId":"urn:oasis:names:tc:xacml:3.0:attribute-category:resource","Attribute":[{"IncludeInResult":false,"AttributeId":"urn:oasis:names:tc:xacml:1.0:resource:resource-id","DataType":"http://www.w3.org /2001/XMLSchema#anyURI","Value":[
      "protected_toaster"
    ]}]}
  ,{"CategoryId":"urn:oasis:names:tc:xacml:3.0:attribute-category:action","Attribute":[{"IncludeInResult":false,"AttributeId":"urn:oasis:names:tc:xacml:1.0:action:action-id","DataType":"http://www.w3.org /2001/XMLSchema#string","Value":[
      "post"
    ]}]}
  ,{"CategoryId":"urn:oasis:names:tc:xacml:3.0:attribute-category:environment","Attribute":[]}
]}}

Der Policy Decision Point überprüft seine Datenbank nach der XACML Regel für diesen User und Endpunkt:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<Policy xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" PolicyId="urn:oasis:names:tc:xacml:2.0:conformance-test:IIA1:policy" RuleCombiningAlgId="urn:oasis:names:tc:xacml:3.0:rule-combining-algorithm:deny-overrides" Version="1.0">
    <Description>
        Policy for Conformance Test IIA001.
    </Description>
    <Target/>
    <Rule Effect="Permit" RuleId="urn:oasis:names:tc:xacml:2.0:conformance-test:IIA1:rule">
        <Description>
            stepo can post to green and red resource
        </Description>
        <Target>
            <AnyOf>
                <AllOf>
                    <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
                        <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">stepo</AttributeValue>
                        <AttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id" Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject" DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="false"/>
                    </Match>
                </AllOf>
            </AnyOf>
            <AnyOf>
                <AllOf>
                    <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:anyURI-equal">
                        <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#anyURI">protected_toaster</AttributeValue>
                        <AttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id" Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource" DataType="http://www.w3.org/2001/XMLSchema#anyURI"  MustBePresent="false"/>
                    </Match>
                </AllOf>
                <AllOf>
                    <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:anyURI-equal">
                        <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#anyURI">protected_tv</AttributeValue>
                        <AttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id" Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource" DataType="http://www.w3.org/2001/XMLSchema#anyURI" MustBePresent="false"/>
                    </Match>
                </AllOf>
            </AnyOf>
            <AnyOf>
                <AllOf>
                    <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
                        <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">post</AttributeValue>
                        <AttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action" DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="false"/>
                   </Match>
                </AllOf>
            </AnyOf>
        </Target>
    </Rule>
</Policy>

Da die Anfrage eine Regel findet wird autorisiert mit:

HTTP/1.1 200
status: 200
date: Sun, 16 Sep 2018 11:38:31 GMT
content-type: application/json
transfer-encoding: chunked

{"Response":[{"Decision":"Permit"}]}

Der Serviceendpunkt antwortet an den Konsumenten final:

HTTP/1.1 200
status: 200
content-type: application/json
content-length: 23

{"message": "success"}