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.
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. Der Anwender ruft den Service des Service Providers auf, den er nutzen möchte.
2. Der Service Provider leitet den Browser des Anwenders zu dem angebundenen Identity Provider weiter.
3. Authentifizierung des Benutzers gegen den Identity Provider unter Verwendung von Einzelfaktor oder Mehrfaktorauthentifizierung.
4. Der Identity Provider gibt ein SAML-Token mit den Assertions an den Benutzer heraus. In mobilen Endgeräten und Webbrowsern wird SAML oft mit BASE64 in die HTML-Response eingebettet.
5. Der Browser des Benutzers wird vom Identity Provider zum Service Provider weitergeleitet. Der Browser des Benutzers stellt seine Anfrage an den Service Provider mit dem eingebetteten SAML-Token. Der Service Provider prüft das SAML-Token und seinen Inhalt, um die Zulässigkeit der Anfrage basierend auf der Vertrauensstellung mit dem Identity Provider zu klären. Der Service Provider stellt den Zugriff auf die verschiedenen Onlinebankinganwendungen basierend auf den SAML-Assertions, die in dem Token enthalten sind, bereit.
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.
Single Logout Protocol
Das Single Logout Protocol erlaubt es, alle Sessions eines Benutzers zu terminieren. Das Logout kann durch den Benutzer, den Service Provider oder den Identity Provider eingeleitet werden. Beispielsweise kann das Single Logout Protocol vom Service Provider nach einem Timeout der Benutzersession verwendet werden
Artifact Resolution Protocol
Das Artifact Resolution Protocol ermöglicht es, Referenzen auf SAML-Nachrichten zu versenden, statt die Nachrichten selbst zu übermitteln. Mit diesem Protokoll werden sehr kleine SAML-Artifacts via SAML-Binding anstelle einer größeren SAML-Nachricht verwendet. Das Protokoll wird verwendet, wenn die Nachrichtengröße kritisch ist oder wenn man die SAML-Nachrichten über einen separaten sicheren Kanal transportieren möchte.
SAML - Bindings
SAML-Bindings legen fest, wie die Nachrichten im Rahmen der SAML-Protokolle transportiert werden. Typischerweise werden SAML-Protokolle über SOAP oder HTTP transportiert.
SAML - Profile
SAML-Profile bündeln Assertions, Protokolle und Bindings für spezifische Anwendungsfälle. Eines der am häufigsten verwendeten SAML-Profile ist das Web Browser SSO Profile.
XACML
eXtensible Access Control Markup Language (XACML) ist ein XML-Schema, das die Darstellung und Verarbeitung von Autorisierungs-Policies standardisiert. Dieser Standard wurde vom OASIS-Konsortium definiert.
Ablauf: 1. Der Benutzer sendet einen Request an eine Ressource. Dieser wird vom Policy Enforcement Point (PEP) abgefangen.
2. Der PEP konvertiert den Request in einen XACML Authorisierungs Request.
3. Der PEP leitet diesen Request an den Policy Decision Point (PDP) weiter.
4. Der PDP prüft und evaluiert den Request gegen die konfigurierten Policies. Diese Policies werden vom Policy Retrieval Point (PRP) bereitgestellt und vom Policy Administration Point (PAP) verwaltet.
5. Der PDP fällt eine Entscheidung über Erlauben/Verbieten/Nicht Anwendbar und leitet diese an den PEP zurück.
Target
Legt fest über welcher Menge von Subjekten, Ressourcen und Aktionen die Policy/Regel definiert ist. Nur diese Regeln/Policies werden ausgewertet. Sowohl Regeln als auch Policies besitzen ein Target.
Rule
Eine Rule besteht aus einem Target (wann soll die Regel angewandt werden?), einem Effekt (wenn die Regel erfüllt wurde gib permit aus, sonst deny) und Conditions (die Regel ist erfüllt, wenn … – boolsche Entscheidungsfindung). Optional kann eine Rule noch einen Satz von Auflagen (Obligations) oder Hinweise (Advices) besitzen.
Policy
Eine Policy besteht aus einer oder mehrere Rules und einem Target. Optional kann eine Policy noch einen Satz von Auflagen (Obligations) oder Hinweise (Advices) besitzen.
PolicySet
Ein Policy Set besteht aus einer oder mehreren Policies, selbst aus einer oder mehr Policy Sets und einem Target, also wann das Policy Set angewandt werden soll. Optional kann ein Policy Set noch einen Satz von Auflagen (Obligations) oder Hinweise (Advices) besitzen.
Combining Algorithms
Durch das gleichzeitige Verwenden von Permit und Deny – Regeln können widersprüchliche Autorisierungsentscheidungen abgeleitet werden. Diese Widersprüche müssen aufgelöst werden. Die folgenden Entscheidungsalgorithmen für die Policy-Evaluation sind im XACML-Standard definiert:
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"}