Die Authentifizierung bezeichnet den Vorgang der Überprüfung der Identität eines Benutzers. Die Authentisierung hingegen bezeichnet den Vorgang des Nachweises der eigenen Identität.
Bei einer Identitätsüberprüfung oder Identifizierung gibt es daher immer einen Teilnehmer, der sich authentisiert und einen, der diesen authentifiziert. Im Englischen wird zwischen den beiden Begriffen nicht unterschieden, das Wort authentication steht für beides.
In einem Computerprogramm werden einer Identität (das heißt einer identifizierten Person) üblicherweise Rechte zugeordnet. Autorisierung bezeichnet den Vorgang, mit dem ein Programm prüft, ob eine bestimmte Identität ein bestimmtes Recht besitzt und damit zum Beispiel eine bestimmte Datei lesen darf.
Die Möglichkeiten des Portal Managers zur Authentifizierung können nahezu beliebig erweitert werden, indem die entsprechenden Filter hinzugefügt werden. Die folgenden Mechanismen werden bereits im Standardlieferumfang unterstützt.
Der AuthenticationFilter in CMS Fiona unterstützt die folgenden Mechanismen:
RemoteUser. Dadurch kann ein
beliebiger vorgeschalteter Mechanismus eingesetzt werden.Der NTLMFilter ermittelt über den Einsatz von NTLM einen
RemoteUser. Dadurch genügt es beim Einsatz von Windows und des
Internet Explorers (eingeschränkt auch Firefox), wenn sich der Benutzer
einmal bei Windows anmeldet. Dieses Login steht dann auch im Portal Manager
zur Verfügung.
Der NTLMFilter erzwingt eine Authentisierung. Es ist allerdings möglich, einen Fallback auf Basic-Authentication zu aktivieren, falls die NTLM-Authentifizierung fehlschlägt.
Es ist möglich, bestimmte URLs und bestimmte IP-Bereiche von der Authentifizierung auszunehmen.
Kommt kein expliziter Login-Request und ist kein RemoteUser
gesetzt, wird der Request anonym behandelt. Greift ein anonymer Benutzer auf
eine geschützte Datei zu, blockiert der PermissionFilter den
Request. Der Benutzer erhält anstelle der Datei den HTTP-Response-Code "401
Unauthorized". Dieser wird vom Servlet-Container typischerweise auf eine in
der web.xml konfigurierte Fehlerseite umgelenkt.
Beim Einsatz des NTLMFilters ist es im Auslieferungszustand des Portal
Managers nicht möglich, als anonymer Benutzer auf Inhalte zuzugreifen, da der
NTLMFilter eine Authentifizierung erzwingt. Indem jedoch das URL-Muster des
Filters (URL pattern) in der Filterkonfiguration (diese befindet
sich in der web.xml) so gesetzt wird, dass der Filter in
bestimmten Bereichen der Website nicht greift, können diese Bereiche auch
nicht authentifizierten Benutzern zugänglich gemacht werden.
Die Auslieferung sowohl textueller als auch binärer Inhalte kann auf bestimmte Benutzergruppen beschränkt werden.
Die Prüfung der Zugriffsberechtigung geschieht auf Dateiebene. Typischerweise hat eine Datei entweder keine Zugriffsbeschränkungen (frei verfügbarer Inhalt) oder es ist eine Reihe von Gruppen definiert, die die Datei lesen dürfen (geschützer Inhalt). Im ersten Fall wird die Datei einfach ausgeliefert. Im zweiten Fall wird geprüft, ob es Gründe dafür gibt, dass der Benutzer die Datei lesen darf. Hierfür wird die Liste der Gruppen des Benutzers ermittelt und geprüft, ob mindestens eine davon unter den Gruppen ist, die die Datei lesen dürfen.
Alternativ können beliebige weitere Prüfungen hinzukonfiguriert werden. Mitgeliefert wird bereits eine Prüfung auf der Basis der IP-Adresse des zugreifenden Rechners.
Die Benutzergruppen, die dazu berechtigt sind, eine exportierte Datei zu
lesen, werden der entsprechenden Datei im Redaktionssystem (mittels Content
Navigator oder per Tcl-Befehl im Content Management Server) zugewiesen.
Dieses Recht heißt "Liveserver-Leserecht", das entsprechende
Tcl-Schlüsselwort heißt permissionLiveServerRead.
Der Portal Manager verfügt über die folgenden beiden Mechanismen zur Unterdrückung von Links auf geschützte Inhalte.
In der Template Engine lässt sich konfigurieren, ob Links auf geschützte
Inhalte automatisch unterdrückt werden sollen. Ein Link wird dadurch
unterdrückt, dass das href-Attribut im a-Tag
entfernt wird. Zur Unterdrückung wird beim Export jedes
href-Attribut mit Velocity-Code umgeben, der zur Request-Zeit
eine Zugriffsprüfung ausführt und das Attribut gegebenenfalls entfernt.
Diese Vorgehensweise hat den Vorteil, dass auch Inhalte, die von Redakteuren erzeugt werden, garantiert keine Links auf geschützte Inhalte enthalten sind.
Sie hat allerdings folgende Nachteile:
Die automatische Linkunterdrückung kann in der Konfiguration in der Datei
export.xml mit Hilfe des Konfigurationswertes
export.convertNpspm.hideForbiddenLinks ein- und ausgeschaltet
werden. Sie ist voreingestellt aktiviert.
Mit Hilfe von npspm-Elementen können Layout-Designer den
HTML-Code, mit dem beispielsweise Linklisten angezeigt werden, gezielt
anpassen, so dass die relevanten Teile nur sichtbar sind, wenn der Benutzer
bestimmte Bedingungen erfüllt:
Um zu vermeiden, dass Benutzer über die Suche Dokumente finden können, die sie nicht lesen dürfen, werden die leseberechtigten Gruppen gemeinsam mit den Dokumenten indiziert. Die Suchanfrage kann dann so erweitert werden, dass zusätzlich zum Suchbegriff des Benutzers verlangt wird, dass mindestens eine der Gruppen des Benutzers in den leseberechtigten Gruppen des Dokuments enthalten ist, oder dass das Dokument frei verfügbar ist.
Die folgende Beispiel-Konfiguration für das Such-Portlet
(SearchPortlet) implementiert eine solche Suchanfrage:
#macro (getPermissionQuery)
#set($groups = "")
#foreach ( $perm in $user.permissions)
#if ("$!groups" != "")
#set ($groups = "$groups , "$perm.trim()"" )
#else
#set ($groups = ""$perm.trim()"")
#end
#end
#if ("$!groups" != "")
<#ANY>((($groups) <#IN> permissionLiveServerRead), (
"free" <#IN> noPermissionLiveServerRead))
#else
<#YESNO>("free" <#IN>noPermissionLiveServerRead)
#end
#end
...
<condition>
<and>
[Hier steht Ihre Search-Query-Formulierung]
<vql-statement>#getPermissionQuery</vql-statement>
</and>
</condition>
...
Ab Version 6.5 unterstützt der Portal Manager von CMS Fiona neben der eigentlichen Suchanfrage auch eine Base-Query. Die Base-Query ist der eigentlichen Suchanfrage vorgeschaltet und reduziert die Menge der Dokumente, auf die die Suchanfrage angewendet wird. Sie vereinfacht den Code erheblich.
Die and-Sektion der Base-Query wird um Folgendes ergänzt:
<or>
<vql-statement>
"free" <#IN>noPermissionLiveServerRead
</vql-statement>
#foreach ($group in $user.permissions)
<vql-statement>
"$group" <#IN>permissionLiveServerRead
</vql-statement>
#end
</or>