XACML
Dieses Material ist Teil des Leitfadens IHE Cookbook.
|
Extensible Access Control Markup Language (XACML)
Die Extensible Access Control Markup Language (XACML) ist ein XML-basierter OASIS Standard. Die letzte verabschiedete Version ist XACML 2.0. Dieser Standard bietet einerseits eine Sprache, mit der Policies, Authorisierungsanfragen und -antworten definiert werden können und andererseits ein (nicht-normatives) Kommunikationsmodell in dem verschiedene Akteure und Transaktionen vorgegeben werden. XACML spezifiziert außerdem, wie Policies interpretiert werden müssen, um eine Autorisierungsanfrage, beispielsweise einen Dokumentenzugriff, zu erlauben oder zu verbieten.
Ähnlich wie IHE Integrationsprofile legt XACML eine Reihe von abstrakten Akteuren fest, die in einem oder mehreren konkreten Systemen umgesetzt werden können. Die zwischen den Akteuren durchgeführten Transaktionen können prinzipiell über Bindings in verschiedene Kommunikationsprotokolle umgesetzt werden, praktisch ist aber ausschliesslich das Binding auf OASIS SAML standardisiert und verbreitet.
XACML sieht folgende Akteure vor: Der Policy Administration Point (PAP) ist für die Verwaltung der Policies zuständig. Dieser Akteur wird häufig mit einem Policy Repository kombiniert, das als persistenter Speicher für Policies zu verstehen ist. Der Policy Decicion Point (PDP) übernimmt die Evaluation von Anfragen, die Prüfung der Anfrage gegen die vorhandenen Policies und entscheidet über die Autorisierung. Der Policy Enforcement Point (PEP) ist schließlich für die Durchsetzung der Entscheidung des PDP verantwortlich. Es können ausserdem weitere Akteure wie ein Policy Information Point (PIP) und ein Context Handler zur Beschaffung weiterer Inputs für die Autorisierungsentscheidung eingesetzt werden, dies ist aber nicht in allen Situationen sinnvoll.
Die wichtigsten Strukturen in der Policy-Definitionssprache sind Policy Set, Policy und Rules. Ein Policy-Set besteht aus einer oder mehreren Policies, kann aber auch weitere Policy Sets referenzieren. Eine Policy besteht aus einer oder mehreren Regeln (Rules).
Sowohl Policy Sets, Policies als auch Rules beziehen sich auf genau ein Target. Anhand des Targets wird entschieden, ob dieses Objekt relevant für eine bestimmte Anfrage ist und somit genauer evaluiert werden muss. Targets haben Attribute aus folgenden vier Kategorien: Subject ("wer greift zu?"), Resource ("worauf wird zugegriffen?"), Action ("wie wird darauf zugegriffen?") und Environment ("unter welchen Umständen wird zugegriffen?"). Zum Beispiel kann eine Policy als Target definieren "Die folgenden Regeln gelten wenn Ärzte (Subject) auf die longitudinale Akte von Patient X (Resource) lesend (Action) im April 2012 (Environment) zugreifen". Das Target wird mit den Attributen der Anfrage abgeglichen. In diesem Beispiel würde bei einem Target Match die unterhalb dieser Policy definierten Rules als relevant angesehen werden und somit tiefergehend evaluiert werden.
Die einzelnen Regeln haben ausser einer eigenen Target Definition auch noch einen Effect und ggf. Conditions. Conditions sind Statements über Attribute die bei der Evaluation entweder "true" oder "false" (oder auch "indeterminate") zurückgeben. Der Effect beschreibt welche Entscheidung, d.h. "permit" (erlaubt) oder "deny" (verboten), aus dieser Regel resultiert wenn das Target zutrifft und die Condition "true" ergibt. Da bei einer Autorisierungsentscheidung mehrere Rules ein relevantes Target haben können, gibt es die sogenannten "Rule Combining Algorithms" die dafür zuständig sind, die häufig unterschiedlichen Resultate der zutreffenden Regeln zu einem Gesamtergebnis für die Policy zu kombinieren. Ebenso gibt es pro Policy Set einen "Policy Combining Algorithm", der die Ergebnisse der einzelnen Policies zu einem Gesamtergebnis für das Policy Set kombiniert. Folgende Algorithmen stehen für die Kombination von Policy Ergebnissen sowie die Kombination von Regel Ergebnissen zur Verfügung: Permit-override ("solange mindestens einer 'erlaubt' sagt, ist das Gesamtergebnis 'erlaubt'"), Deny-override ("solange mindestens einer 'verboten' sagt, ist das Gesamtergebnis 'verboten'"), First-applicable ("das erste richtige Ergebnis zählt als Gesamtergebnis"), Only-one-applicable ("wenn genau eine Regel/Policy zutraf ist ihr Ergebnis das Gesamtergebnis, ansonsten gibt es kein Gesamtergebnis").
Obligations sind die Actions, die der PEP in Verbindung mit dem Enforcement einer Autorisierungsentscheidung ausführen muss. Dies kann beispielsweise die Protokollierung der Transaktion sein. Nach der Evaluation einer Policy werden Obligations an den PEP gesendet. Er ist verpflichtet, diese Actions zusammen mit dem Enforcement auszuführen. Es gibt in XACML 2.0 keine Standard Obligations, d.h. die Definition von durchzuführenden Aktionen und die dafür notwendigen Daten müssen zwischen dem Policy Autor und dem PEP abgestimmt sein.
