Um die Sicherheits-Schnittstelle zu aktivieren, muss zunächst dieses Features in der Datei
server-config/application/active-features.xml aktiviert werden. Die Konfiguration
erfolgt anschließend in der Datei server-config/application/security.xml.
Zur Authentifikation und Gewährung von Rollen wird auf das Framework Spring Security zurückgegriffen. Das Zusammenspiel zwischen jadice server und Spring Security zeigt Abbildung 8.1, „Zusammenhang zwischen jadice server und Spring Security“:
Um die Authentifikation zu verifizieren, greift jadice server bei der Erzeugung von
NodeWorkern auf den ProviderManager[1]
zurück. Dieser befragt die angegebenen
AuthenticationProvider[2],
ob diese die vom Client gelieferten Credentials anerkennnen. In der
beispielhaften Konfiguration sind dies zum einen der DaoAuthenticationProvider, der in der
XML-Konfiguration hart codierte Accounts beinhaltet. Außerdem ist ein
AnonymousAuthenticationProvider vorkonfiguriert, der Clients, die ohne Credentials auf
jadice server zugreifen, die Rolle ROLE_ANONYMOUS gewährt.
An dieser Stelle können weitere AuthenticationProvider konfiguriert werden, die z. B.
eine Authentifikation gegen eine LDAP-Datenbank vornehmen. Eine weitergehende Beschreibung
finden Sie in der Dokumentation zu Spring Security. Dort finden Sie auch die weiteren
jar-Dateien zum Download, die dafür eventuell notwendig sind. Diese können in den Ordner
/server-lib/ kopiert werden.
Konnte eine Authentifikation erfolgreich durchgeführt werden, wird anschließend (falls
Nodes aufgerufen werden sollen, die einer Restriktion unterliegen) der
AccessDecisionManager[3]
befragt, ob diese Authentifikation der Restriktion genügt. Dies
geschieht über den RoleVoter, der dies anhand der gewährten Rolle(n)
überprüft.
Der Zugriff auf jadice server kann in verschiedene Richtungen beschränkt werden. Dies
geschieht regelbasiert entweder durch AccessRules, die den Zugriff auf Knoten beschränken,
oder durch LimitRules, die Limits für Jobs oder Nodes erzwingen:
Abbildung 8.2. Klassenhierarchie der Security-Regeln (XML-Namespace http://www.levigo.com/jadice-server/schema/security)
Die Bedingung, ob eine Regel zutrifft, ist in der Spring Expression Language (SpEL) formuliert. Neben den in SpEL vordefinierten
logischen Operatoren and, or, ! (nicht) und den
relationalen Operatoren >, <,
<=, >=, == und
!= gibt es mehrere spezielle Operatoren für die Evaluation von
Nodes und den dort gesetzen Werten (properties):
Tabelle 8.1. Operatoren zur Evaluation von Nodes und dort gesetzten Werten
|
Operator |
Beschreibung |
|---|---|
|
access('Klassenname Knoten') |
Evaluiert zu |
|
call('Klassenname Knoten') |
|
|
property('Klassenname Knoten', 'Name der Property') |
Evaluiert zu dem Wert, den ein Knoten vom gegebenen Typ als angegebene Property hat. Dies kann auch geschachtelt auf Properties von Properties angewandt werden (siehe Beispiel unten). |
|
value('Klassenname Knoten', 'Name der Property') |
Folgende Möglichkeiten gibt es, diese Operatoren zu kombinieren:
-
Regeln, die access oder call verwenden, dürfen auf verschiedenen Knotentypen matchen, z. B.
access('com.levigo.jadice.server.nodes.StreamInputNode') or access('com.levigo.jadice.server.nodes.StreamOutputNode')Eine Regel mit dieser Bedingung zieht für alle Knoten vom Typ
StreamInputNodeoderStreamOutputNode -
Regeln, die property oder value verwenden, dürfen nur auf einen Typ von Knoten matchen, z. B.
value('com.levigo.jadice.server.nodes.URLInputNode', 'URLs[0].host') !='localhost' or value('com.levigo.jadice.server.nodes.URLInputNode', 'URLs[0].protocol') != 'http'Eine Regel mit dieser Bedingung zieht nur für
URLInputNodes, deren erste angegebene URL nicht mithttp://localhostbeginnt.
Für Regeln, die in Abhängigkeit der gewährten Rolle(n) greifen sollen, gibt es die Operatoren isAnonymous() und hasRole('Rollenname'). Diese können auch mit den anderen Operatoren gemischt werden, z. B.
access('com.levigo.jadice.server.nodes.URLOutputNode') and !hasRole('ROLE_SUPER') Eine Regel mit dieser Bedingung greift, wenn ein Client, der nicht die Rolle ROLE_SUPER besitzt,
versucht, auf den URLOutputNode zuzugreifen.
Mit Hilfe dieser Bedingungen können Regeln vom Typ AccessRule und vom Typ LimitRule
gebildet werden. Die XML-Schemadefinition, der diese in der Konfigurationsdatei folgen
müssen, ist innerhalb der jar-Datei
/server-lib/server-core-5.x.y.z.jar unter
com/levigo/jadice/server/core/security/jadice-server-security-5.0.xsd zu finden.
Regeln vom Typ AccessRule enthalten ein oder mehrere Elemente mit Name requiredRole,
die definieren, welche Rolle benötigt wird, wenn die angegebene Bedingung zutrifft. Diese
werden in der XML-Konfiguration unter dem Eintrag <property name="nodeAccessRules">
eingefügt.
Regeln vom Typ LimitRule enthalten eine oder mehrere Referenzen auf Limits, die
angewandt werden, wenn die angegebene Bedingung zutrifft. Diese Limits werden in der
XML-Datei als normale Spring-Beans deklariert, die eine von Limit abgeleitete Klasse und
eine ID besitzen müssen. Werden Limits der selben Klasse mit Limit.WhenExceedAction ABORT sowohl
clientseitig also auch über die Security-Schnittstelle gesetzt, hat das restriktivere
Vorrang.
Solche Regeln, deren Limits nur auf bestimmte Knoten angewandt werden sollen, können im
Abschnitt <property name="nodeLimitRules"> eingefügt werden. Solche Regeln, deren Limits
auf den kompletten Job angewandt werden sollen, können im Abschnitt
<property name="jobLimitRules">
eingefügt werden; dabei ist jedoch zu beachten, dass die Operatoren
access, call, property und value
nicht in der Bedingung verwendet werden können.
