Anmeldeverfahren in cardo3

In cardo3 können verschiedene Verfahren der Benutzeridentifikation verwendet werden.

Intern wird dies über Identifikationsprovider realisiert. Dieser Provider muss sich dabei um die Authentifizierung kümmern und als Ergebnis den Benutzernamen und die möglichen Gruppen für diesen Benutzer liefern.

Nach der erfolgreichen Authentifizierung ordnet cardo diesem Benutzer anhand seines Benutzernamens bzw. der verfügbaren Gruppen die internen Objekt-Ids zu, die dem System bekannt sind. In einem zweiten Schritt werden dann die cardo internen Gruppen zugeordnet.

1. Integrierte Windows Authentifizierung

Dieses Verfahren wird automatisch erkannt, wenn im IIS in den Einstellungen der Website bzw. des virtuellen Verzeichnisses als Anmeldeverfahren "Windows integriert" eingestellt ist. (Hinweis: Die Option "Anonymer Zugriff" darf nicht aktiviert sein!!!)
Der Benutzername wird ermittelt und die Domänen-Gruppen des Benutzers werden durch Abfrage des Domaincontrollers ausgelesen. Die eigentliche Authentifizierung wird dabei von den Betriebsystemkomponenten durchgeführt. Kennwörter werden dabei i.d.R. nicht noch mal vom Nutzer abgefragt. Der Benutzername muss in cardo nicht zwingend vorhanden sein. Der Benutzer gilt als bekannt, wenn mindestens eine der Gruppen, in denen der Nutzer Mitglied ist, in cardo vorhanden ist.

Zusätzlich zu den Windows- und cardo-Gruppenmitgliedschaften erhält der Nutzer automatisch noch die Gruppe SYSTEM_AUTHENTICATED_USERS.

2. Basic-Auth, cardo interne Verwaltung

Bei diesem Verfahren sendet cardo den HTTP Header 401 um Nutzername und Kennwort abzufragen. Dieses Kennwort wird mit den cardo internen Einstellungen verglichen. Auch dieses Verfahren erkennt cardo anhand der Einstellungen im IIS automatisch. Die Verzeichnissicherheit muss hier auf "Anonymer Zugriff" eingestellt sein. (Hinweis: Die Option "Windows integriert" darf nicht aktiviert sein!!!)

Als Gruppen stehen ausschließlich die internen in cardo angelegten und gepflegten Gruppen zur Verfügung. Die Benutzernamen müssen in cardo vorhanden und ein Kennwort muss vergeben sein.

Zusätzlich zu den cardo-Gruppenmitgliedschaften erhält der Nutzer automatisch noch die Gruppe SYSTEM_AUTHENTICATED_USERS.

3. Anonymer Zugang

Alle Aufrufe an Inhalte (Webseiten, Dienste) unterhalb eines Ordners "public" werden immer automatisch unter dem Account SYSTEM_ANONYMOUS_USER ausgeführt. cardo interne Gruppen werden ausgewertet. (Soll heißen - SYSTEM_ANONYMOUS_USER kann Mitglied in cardo-Gruppen sein und auf diesem Wege Berechtigungen zugewiesen bekommen.)

SYSTEM_ANONYMOUS_USER wird kein Mitglied der Gruppe SYSTEM_AUTHENTICATED_USERS.

4. cardo.map

Alle cardo.map Aufrufe, außer denen im Ordner "public", werden intern mit dem Benutzer CARDO_MAP_INET_USER ausgeführt. Als Sonderfall prüft dieser Provider noch im Request das Attribut PreviewMode. Wenn dieser Wert = 1 ist, wird intern der Benutzer CARDO_MAP_PREVIEW_USER verwendet.

Beide Pseudo-Nutzer erhalten keine Mitgliedschaft in der Gruppe SYSTEM_AUTHENTICATED_USERS.

5. Externe Identifikation über ein Sicherheitstoken

Bei diesem Verfahren muss ein Dienst bereitgestellt werden, der anhand eines Sicherheitstokens eine Antwort gemäß dem Schema http://webs.idu.de/xsdschemas/Cardo/1.0.0/TokenBasedIdentificationProviderServiceResult.xsd liefert.
Der Aufrufer muss das Token nach einem bestimmten Schema in die Url einbetten. Die Syntax entspricht dabei der der HTTP_FILTER in ASP.Net.
Bsp.: http://localhost/net3/(I(saena_beba785c4fb098771a4a4XXXXXXXX))/

Der Aufbau entspricht genau der Form "I({SiteId}_{Token})"

Die "SiteId" ist ein Parameter über den in der Web.config die Einstellungen (Url, Verhalten) für den zuständigen Dienst ermittelt werden. Die Einstellungen müssen dabei in der Sektion "appSettings" nach folgendem Schema beschrieben sein:

add key="IDU.TokenBasedAuthenticationProviderServiceUrl.saena"  value="http://foo.de/service/token.php?token="
add key="IDU.TokenBasedAuthenticationProviderServiceUrl.saena.behavior"  value="Default"
add key="IDU.TokenBasedAuthenticationProviderServiceUrl.saena.minTimeoutSeconds"  value="20"
key="IDU.TokenBasedAuthenticationProviderServiceUrl.saena.defaultGroupNames"  value="externe,externeX"

Wobei "saena" in diesem Beispiel die SiteId ist.

In dem gesamten Schlüssel dürfen keinerlei Umlaute oder Sonderzeichen enthalten sein (dies ist eine Restriktion des ISAPI-Filters, der die Umsetzung vornimmt).

Auf diese Weise authentifizierte Nutzer werden nicht Mitglied der Gruppe SYSTEM_AUTHENTICATED_USERS.