Authorization

Mindbreeze erlaubt dem Benutzer nur Objekte zu finden, für die er berechtigt ist. Die Autorisierung der Objekte kann mit Access Control Lists (ACLs) und Live Access Check durchgeführt werden. Die bevorzugte, weil schnellere, Variante sind ACLs.

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 

erlaubt allen marketing Gruppenmitgliedern den Zugriff außer john doe. Das Resultat ist der Wert des ersten übereinstimmenden Principals. Als Gegenbeispiel, erlaubt

marketing:GRANT, john doe:DENY

john doe den Zugriff auf das Dokument, falls er Mitglied der Gruppe marketing ist.

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> 

Folgendes Beispiel zeigt nur die Zuordnung einer Gruppe mit einem Zeichenkettenvergleich. Bei einer konkreten Datenquelle werden die Principals aus der Datenquelle oder über z.B. Microsoft Active Directory zugeordnet.

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();
}
}
}

Dieses Beispiel zeigt nur einen Zeichenkettenvergleich. Bei einer konkreten Datenquelle wird bei der Datenquelle nachgefragt, ob der Benutzer das Objekt sehen darf.
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.