Autor jgrotepass
Datum 02.05.2006 12:12
Beiträge: OK, nettes Thema. Also muss ich als "Schläfer" aus meinem "Loch" kriechen und auch meinen Senf dazugeben.

Zunächst wäre ich für eine klare Begriffsdefinition:
In dieser Materie unterscheidet man zwischen:
- SSO (Single Sign On) und
- SLI (Single Log In)

Haarspalterei? Nein.
Wenn bei der Thread Eröffnung von ELAK (Elektronischer Akt) gesprochen wird (sehr wahrscheinlich Österreich) dann wird von SSO gesprochen. Dabei wird sich, unabhängig von der Userid auf der Workstation, gegenüber einem Portal authentisiert. Dieses Portal setzt entsprechende HTTP-Cookies, die über die Policy Server der zugeordneten / untergeordneten Systeme (in der Regel Webserver, Web-Applications) geprüft werden. Im Regelfall sind die Policy-Server Directory-Server orientiert und verwenden LDAP als Protokoll (einen LDAP Server per se gibt es ncht - LDAP ist ein Protokoll).
Wenn der Benutzer nun eine Applikation aufruft, können im Verzeichnis (Directory Server) Attribute hinterlegt sein, die sein Login an der entsprechenden Applikation automatisch durchführen. Das kann auch ein "getrusteter" User sein, der in einem Portal-Verbund aufgrund gesetzter Rechte den Benutzer als bereits korrekt authentisiert akzeptiert. So etwas machen wir (meine Firma) in Österreich bei einem sehr grossen Anbieter auch für Mainframes.

SLI (Single Login) denkt eine Ebene höer. Hier wird durch die Anmeldung an die Workstation ein - in der Regel Kerberos - Ticket verwendet. Dieses vermittelt gegenüber den Berechtigungssystemen einen bereits authentisierten Benutzer, der aufgrund des Kerberos Tickets keine weitere Berechtigung mehr benötigt. Diese Art der Implementierung setzt aber eine Reihe von Funktionen voraus, die unter anderem dem Browser klarmachen müssen, dass ein Ticket als HTTP-Cookie mitgesendet wird.
Dann können die untergeordneten / zugeordneten Systeme diese Information prüfen.

So, nun etwas zu Active Directory:
Microsoft hat kein neues Rad erfunden. ADS ist nicht anderes als eine Weiterentwicklung des Novell Directory Services mit stärkerer Einbindung in das Betriebssystem. Daneben stellt der ADS aber genauso wie jeder andere Directory Server einen Port für LDAP Zugriffe zur Verfügung. Einzig die Verzeichnisstruktur ist etwas "gewöhnungsbedürftig".
Somit gibt es also keine Probleme, einen ADS als Directory Server einzubinden.

Mir liegt es fern, als "Klugscheisser" hier auftreten zu wollen, aber der Satz
"Und wenn Kleinstweich da ihr eigenes Süppchen kocht und vermerkt ob der User eingeloggt ist dann verstossen die gegen alle LDAP Standards" ist so nicht richtig. Es gibt nirgends Regeln die festlegen, wie mit Verzeichnis-Servern verfahren werden soll. Ob man dort in einem Attribut ein "Logged On" Flag setzt oder nicht ist nicht in den RFCs für die Directory Services geregelt. Daneben macht Microsoft eben genau so etwas nicht, sondern authentisiert via Kerberos.

Letztlich mein Beitrag zu dem Thread an sich:
Als ich vor 2 Jahren OPN hier installiert habe, fiel mir schon auf, dass es keine LDAP Unterstützung gibt. Somit ergibt sich zwangsläufig eine mehrfach-Pflege von Benutzern.
Das LDAP kein SQL ist, wie gesagt wurde, ist natürlich logisch. Aber für eine Implementierung in Unternehmensnetzte, die wohl scheinbar auch bei anderen vorgenommen werden, ist die mehrfach Pflege von Usern schon nervig und öffnet auch das eine oder andere Sicherheitsloch (User vergessen zu löschen etc).

Attribute in Verzeichnisdiensten sind gleichzusetzen mit Daten in einer SQL-orientierten Datenbank. warum also nicht das Authentisierungs-Modul erweitern? Kann doch eine Option sein?
Den Abgleich und die Attribute zu definieren sollte keinen Akt darstellen.
Werbung ist ja nicht erlaubt, aber gedanklich kann man sich mal mit dem Thema "Virtual Data Federation" auseinandersetzen. Der Ansatz besteht darin, einen Data-Abstraction Layer zwischen eine Anwendung und den Daten-Sourcen zu legen. Damit wird man von der eigentlichen Datenherkunft unabhängig. Man schreibt ja heute auch nicht mehr den Code für eine Netzwerkkarte, sondern nutzt den IP Stack des Systems (oder eines anderen Herstellers).

Nun denn, ich werde jetzt wohl erschlagen mit all den gut gemeinten Kommentaren, weshalb ich auch wieder brav in mein "Loch" zurück krieche.

Viele Grüße aus Rheinhessen,
Jochen


Diese Seite drucken
Diese Seite schließen

Dieser Artikel kommt von: OpenPHPNuke - das Open Source CMS

http://www.openphpnuke.info/