\subsection{HERAS-AF}

Die Abkürzung \emph{HERAS-AF} steht für \emph{Holistic Enterprise-Ready
Application Security -- Architecture Framework} und stellt die
Referenzimplementation von \emph{XACML} dar (\emph{Extensible Access Control
Markup Language}). Derzeit besteht es nur aus einem Kern, welcher XACML 2.0
implementiert (d. h. sogenannte \emph{access requests} auswerten kann).
Weitergehende Komponenten wie z. B. das Management von \emph{policies} stehen
noch nicht zur Verfügung.

\subsubsection{XACML}

XACML ist ein XML-Dialekt, mit welchem sowohl Zugriffsrechte als auch deren
Interpretation festgelegt werden.

Das typische Anwendungsszenario läuft dabei so ab, dass ein Benutzer eine
Anfrage an eine durch einen \emph{PEP} (\emph{Policy Enforcement Point})
geschützte Ressource stellt. Der PEP sendet dann eine XACML-Anfrage mit den
Daten des Zugriffs (Benutzer, Ressource, Aktion, etc.) an einen \emph{PDP}
(\emph{Policy Decision Point}). Dieser entscheidet dann anhand von
\emph{policies}, ob der Zugriff gewährt werden kann und sendet eine
entsprechende Antwort an den \emph{PEP}.

Dieser Entscheidung zu Grunde liegen \emph{PolicySets}, welche aus
\emph{Policies} bestehen, die einzelne \emph{Rules} enthalten. Jede einzelne
Regel trifft eine konkrete Entscheidung, die dann von verschiedenen
\emph{Combining Algorithms} zu einer Gesamtentscheidung zusammengefasst werden
(z. B. \emph{Deny Overrides}, der bei einer einzigen Teilverweigerung den
Zugriff verweigert).

Die Domänen, auf welchen Regeln entscheiden, sind sogenannte \emph{Targets} und
\emph{Attributes}. Targets bestehen aus Bedingungen für Benutzer, Ressource und
Aktion, welche festlegen, ob eine Regel überhaupt auf einen Anfrage anwendbar
ist. Attributes sind einfache Schlüssel-Wert-Paare, angereichert mit
Zeit- und Ausstellungsinformationen, anhand derer Regeln entschieden werden.
Eine Anfrage von einem PEP an den PDP enthält solche Attribute, z. B. über die
konkrete Ressource.

Ein Beispiel für das Zusammenspiel zwischen Anfrage, Policy und Antwort findet
sich unter \url{http://sunxacml.sourceforge.net/guide.html#xacml-example}.

\subsubsection{Implementation}

Die Implementation kann nicht beurteilt werden, da keine sinnvolle Dokumentation
zur Verfügung steht.

Es existieren auch andere XACML-Implementationen:

\begin{itemize}
	\item PicketBox XACML (von JBoss\footnote{
	\url{http://community.jboss.org/wiki/PicketBoxXACMLJBossXACML}}), auch
	weitestgehend undokumentiert

	\item Sun XACML (\url{http://sunxacml.sourceforge.net/}): Diese
	Implementation scheint aktiv entwickelt zu werden. Leider steht kein
	Referenzhandbuch zur Verfügung. Außerdem liegt nur eine Datei-basierte
	Implementation eines \emph{PolicyFinders} vor. Eigene Erweiterungen sind
	möglich (und auch mit Beispielen dokumentiert), jedoch würde der Aufwand den
	Nutzen aufgrund der hohen Komplexität von XACML deutlich übersteigen.
\end{itemize}

\subsubsection{Einschätzung}

Der XACML-Standard hat bisher noch keine breite Unterstützung erfahren. Dies
könnte zum einen daran liegen, dass er eine hohe Komplexität hat und daher nicht
nur für Bibliotheksentwickler, sondern auch -anwender schwierig umzusetzen ist.
Es ist allerdings möglich, Berechtigungen sehr feingranular umzusetzen, unter
anderem auch unter Berücksich der aktuellen Systemzeit. Ob eine derartige
Flexibilität jedoch nötig ist, bzw. nicht besser ad hoc unter Umgehung von
umfangreicher Konfiguration implementiert werden kann, ist jedoch fraglich.

