Authorization
ACLs
Bei jedem Objekt kann eine Liste von Principals hinterlegt werden. Während einer Suche wird geprüft, ob der aktuell ein Principal des angemeldeten Benutzers Teil dieser Liste ist. Der entsprechende ACL-Eintrag entscheidet dann über die Auffindbarkeit eines Objekts. Als Principals werden typischerweise Benutzer- und Gruppennamen verwendet. Eine typische ACL sieht folgendermaßen aus:
john doe:GRANT, marketing:GRANT
Dadurch erhalten der Benutzer john doe und die Gruppe marketing Zugriff auf das Objekt. Alle anderen Principals können das Objekt nicht finden.
Die Reihenfolge kann zur Strukturierung der ACLs verwendet werden. Die ACL
john doe:DENY, marketing:GRANT
marketing:GRANT, john doe:DENY
Die ACLs werden bei der Indizierung mit setAcl gesetzt:
indexable.setAcl(AccessControlList.newBuilder() . addEntry(AccessControlEntry.newBuilder() .setPrincipal("john doe") .setAction(AccessControlEntry.Action.GRANT) ).build() );
Entscheidend für die Prüfung der ACLs ist die Zuordnung von Principals zum angemeldeten Benutzer. Dazu dient die resolveUser
-Methode im AuthorizationProvider, der auch Teil des Plugins ist.
<Plugin> … <Extension> <point>com.mindbreeze.query.mes3.Authorization</point> </Extension> … <java_class>mindbreeze.example.cmis.query.CmisAuthorizationProvider</java_class> … </Plugin>
public Collection<String> resolveUser(Principal principal, String categoryInstance) { LinkedList<String> principals = new LinkedList<String>(); principals.add(principal.getName().toLowerCase()); if ("john doe".equalsIgnoreCase(principal.getName())) { principals.add("marketing"); } return principals; }
Das Konzept der Principals ist wichtig, weil damit Änderungen an Gruppenmitgliedschaften keine Aktualisierung aller Objekte im Index bedeutet. Es müssen nur die Principals von resolveUser korrekt geliefert werden und die Resultate werden korrekt angezeigt.
Bei der Autorisierung mittels ACLs stellt Mindbreeze folgende Einstellungen zur Verfügung.
Beim "Approved Hits Reauthorize" Dropdown Box soll Token Cache ausgewählt sein.
Die “Use Authentication Cache” Option ist standardmäßig aktiviert und erlaubt das Cachen von zwischenspeicherbaren Autorisierungsergebnissen innerhalb eines “Authentication Cache Flushing Intervals”.
Live Access Check
Warnung: Live Access Check kann die Geschwindigkeit der Suche stark beeinträchtigen!
Beim Live Access Check werden alle gefundenen Dokumente an die authorize
-Methode des AuthorizationPlugins übermittelt. Diese Methode entscheidet für jedes Dokument, ob der Benutzer das Dokument finden darf.
public void authorize(AuthorizationRequest request) { boolean isJohnDoe = "john doe".equalsIgnoreCase(request.getPrincipal().getName()); for (AuthorizableObject authorizableObject : request.getObjects()) { if (isJohnDoe && authorizableObject.getKey().contains("john doe")) { authorizableObject.authorize(); } else { authorizableObject.reject(); } } }
Der Vorteil dieses Ansatzes ist, dass das Resultat der Rechteprüfung immer aktuell ist. Allerdings auf Kosten der Geschwindigkeit, da ACLs viel schneller geprüft werden können, als die Anfrage an eine Datenquelle gestellt werden kann.
Eine Möglichkeit ist ein zweistufiger Prozess, bei dem zuerst ACLs geprüft werden und dann auf den möglichen Treffern noch ein Live Access Check gemacht wird. Dadurch ist sichergestellt, dass der Benutzer keine Dokumente sehe kann, auf die er keine Rechte mehr hat und die ACLs noch nicht aktualisiert wurden.
Wenn „External Authorizer“ beim "Approved Hits Reauthorize" Dropdown Box ausgewählt ist, werden ACLs nicht überprüft.