Sicherheits-Schnittstelle
Mit der Sicherheits-Schnittstelle ist es möglich, in jadice server eine statische Konfiguration zu hinterlegen, anhand der der Clientzugriff rollenbasiert eingeschränkt werden kann. Folgende Einschränkungen sind in Abhängigkeit der gewährten Rolle möglich:
Kompletten Zugriff auf Knoten verbieten
Zugriff auf Knoten in Abhängigkeit der gesetzten Werte verbieten
Node-Limits erzwingen (optional in Abhängigkeit der gesetzten Werte)
Die hierzu notwendigen Anpassungen werden in den folgenden Unterkapiteln beschrieben.
Konfiguration
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.
Authentifikation
Zur Authentifikation und Gewährung von Rollen wird auf das Framework Spring Security zurückgegriffen. Das Zusammenspiel zwischen jadice server und Spring Security zeigt die folgende Abbildung:
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.
Restriktionen
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):
|
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') |
Tabelle 8.1. Operatoren zur Evaluation von Nodes und dort gesetzten Werten
Folgende Möglichkeiten gibt es, diese Operatoren zu kombinieren:
Regeln, die
accessodercallverwenden, 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
StreamInputNodeoderStreamOutputNodeRegeln, die
propertyodervalueverwenden, 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">{.xml} 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">{.xml}
eingefügt werden. Solche Regeln, deren Limits auf den kompletten Job
angewandt werden sollen, können im Abschnitt
<property name="jobLimitRules">{.xml} eingefügt werden; dabei ist
jedoch zu beachten, dass die Operatoren access, call, property und
value nicht in der Bedingung verwendet werden können.
Clientseitige Verwendung
Die clientseitige Verwendung beschränkt sich darauf, im Job die
Zugangsdaten (Credentials) zu setzen:
Beachten Sie, dass die Credentials -- abhängig vom verwendeten MOM und dessen Konfiguration -- möglicherweise in Klartext übertragen werden.
Job job = createServerJob();
job.setType("authenticated job");
// Authenticate against jadice server
job.setServerCredentials(new Credentials("myUsername", "myPassword"));
Beispiel 8.1. Clientseitige Authentifikation
Kann die Authentifikation nicht vom Server verifiziert werden, schlägt
der Job mit dieser Fehlermeldung fehl (siehe
JobListener#executionFailed):
|
|
|
|
|
Sie konnten nicht mit dem Benutzernamen 'unbekannter Benutzername' angemeldet werden. |
|
|
|
Tabelle 8.2. Details der Fehlermeldung, wenn Authentifikation fehl schlägt
Besitzt der Client nicht die geforderte Rolle, um auf einen Knoten zugreifen oder diesen mit bestimmten Werten belegen zu dürfen, schlägt der Job mit dieser Fehlermeldung fehl:
|
|
|
|
|
Sie besitzen nicht die erforderliche Berechtigung [benötigte Rolle(n)] für diese Aktion: Name der verantwortlichen Regel |
|
|
|
Tabelle 8.3. Details der Fehlermeldung, wenn Rechte nicht ausreichen