Forum

Moderiert von: stefan, spinne
Forum Index
Support
     Administration
     Single Sign On // LDAP od. NDS
Hilfe anzeigen
Hilfe anzeigen

Seite 1 2 vorherige Seite 


Autor Druckerfreundliche DarstellungSingle Sign On // LDAP od. NDS
hombergs
Registriert: 05.09.2001
Beiträge: 256
Wohnort: Frankfurt (Main)


Sende eine Private Nachricht an hombergs Besuche die Homepage von hombergs
ICQ AIM YIM MSNM
Geschrieben: 29.04.2006 01:55

Go nochmal langsam zum mitschreiben. Ich spreche von LDAP und nicht dem ADS Gedöns von Mickeysaft.
Bei LDAP kann man nicht feststellen ob ein User eingeloggt ist oder nicht. Weil das macht die Workstation.
Bei LDAP geht es folgendermassen:
1. User loggt sich ein (Workstation oder Webseite)
2. Das Authsystem des OS oder der Webseite verbindet sich zum LDAP Server.
3. Anfrage an den LDAP Server: Hey du, gibt es den User mit dem Namen xyz?
4a. Wenn nein Login gescheitert
4b. Wenn ja Frage an den LDAP Server: Hey du, wie lautet sein Passwort den?
5a. Wenn Passwort vom LDAP Server != eingegebenes Passwort dann Abbruch
5b. Wenn Passwort vom LDAP Server == eingegebenes Passwort dann Frage an den LDAP Server: Hey du, in welchen Gruppen ist er den?
6. Zuweisung der entsprechenden Gruppenrechten.

Also ist nix mit automatisierter Anmeldung an die Webseite. Weil das ist das korrekte System wie eine LDAP Auth funktioniert. Weil ich kann mich ja mit meinem Benutzername an X Workstations anmelden. Wie soll das bitte ein LDAP Server verarbeiten?
Und wenn Kleinstweich da ihr eigenes Süppchen kocht und vermerkt ob der User eingeloggt ist dann verstossen die gegen alle LDAP Standards.
Und nein extra was für diesen Redmonder Verein wird nicht gecodet. Wenn ich sowas im Trunk sehe, wird es gleich von mir dort entfernt.



H.O.M.B.E.R.G.S.: Hydraulic Obedient Machine Built for Efficient Repair and Galactic Sabotage
Es gibt keine Probleme, nur Herausforderungen.

Stoppt Softwarepatente, sonst wird Softwareentwicklung in Europa für die meisten illegal!
Infos: Der Patentierte Europäische Online-Shop
Utopia 1: Die Welt wo alle Browser valides HTML und valides CSS 2 verstehen und alle es gleich anzeigen.
Utopia 2: Die Welt wo alle SQL Server den ANSI SQL Standardsyntax einwandfrei beherschen und ausführen.

Zitieren Druckerfreundliche Darstellung nach oben
jgrotepass

Registriert: 16.01.2004
Beiträge: 17


Sende eine Private Nachricht an jgrotepass
Geschrieben: 02.05.2006 12:12

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


Zitieren Druckerfreundliche Darstellung nach oben
stefan
Wohnort: Münster


Sende eine Private Nachricht an stefan
ICQ
Geschrieben: 02.05.2006 13:56

Sehr Netter Beitrag Jochen, 2 Sachen nicht jetzt aus meiner Sicht nicht erwähnt worden.

Eine Implementierung setzt aber auch voraus Zugang zu dem entsprechenden Medium zuhaben, sofern dieses keiner von uns im Testbereich laufen hat scheitert es schon an dem Vorhandensein eines entspre-chendes Umfeldes.

Ob für eine Implementierung in Unternehmensnetze dieses Zwingend notwendig ist, ist eine Interessante Frage. Allerdings; Diese näher zu erörtern würde zu weit OT werden. Nur soviel, das Argument habe ich noch nicht in der Praxis vernommen.



Erst nachlesen, dann nachdenken, dann nachfragen...
http://www.catb.org/~esr/faqs/smart-questions.html

openPHPnuke Developer

Zitieren Druckerfreundliche Darstellung nach oben
xweber
Registriert: 22.08.2001
Beiträge: 1496


Sende eine Private Nachricht an xweber
Geschrieben: 02.05.2006 17:03

Ich hab hier (theoretisch) auch einen LDAP Dienst mit Benutzern. Leider hat sich da mein (schon vor einiger Zeit) angedachtes einbinden in opn mittlerweile aus div. Gründen erledigt.

Problem, so wie ich das momentan sehe, ist aber auch das die Struktur innerhalb des LDAP Baumes nicht zwingend überall gleich ist. Da würde man wohl wieder was sehr flexibles bauen müssen.

Viel wichtiger war für mich aber, das mir da bzgl. der Sicherheit der Durchblick fehlt. Also ob man es als Anmeldesystem leicht aushebeln kann. Eine mögliche Anwendung wäre hier z.b. zentrale Pfelge des Users bzw. Passwortes (gewesen). Dazu zählt auch Passowortrotation und Historie etc.

Bei MS ist da was im IIS integriert, das er auf den Domänencontroller zurückgreifen kann. Es gibnt/gab für windows-Apache patches, die das nachgerüstet haben.

Alex


Zitieren Druckerfreundliche Darstellung nach oben
jgrotepass

Registriert: 16.01.2004
Beiträge: 17


Sende eine Private Nachricht an jgrotepass
Geschrieben: 02.05.2006 18:03

*ausdemlochkriech*
@stefan
Ist mir schon klar, dass ein entsprechendes Umfeld und vor allem die Kenntnis über den richtigen Einsatz gegeben sein sollte, sonst wird das nichts. Hier gibt es aber Möglichkeiten, angefangen von xweber bis hin zu unseren Umgebungen und, falls gewünscht/gestattet, unsere/meine Mitarbeit daran. An sowas sollte es nicht scheitern.
Daneben ist eine "zwingende" Implementierung so (noch) nicht zu sehen. Jedoch denke ich, dass es die Integration von OPN Systemen innerhalb von Unternehmen schon vereinfacht, wenn dort eben Directory Server zum Einsatz kommen.

@xweber
Es gibt keine einheitliche Struktur des Baumes innerhalb eines Verzeichnisses. Das ist aber so auch vorgesehen. Genau hier kann eben jedes Unternehmen entscheiden was es wie und vor allem innerhalb welchem Zweig darstellen möchte. Letztlich aber kein Thema, wenn die Struktur bei der Implementierung von Anfang an gut durchdacht und eben anpassungsfähig ist. Das ist genau die Stärke von OPN (und auch unsere). Deshalb habe ich da keine Bedenken.

Was das Anmeldesystem an sich betrifft, so ist hier noch keine Festlegung getroffen worden. Mein Beitrag sollte letztlich die Unterscheidung zwischen den verschiedenen Begriffen klären und die damit verbundenen Strukturen.
Diese Implementierung im IIS (warum hat der wohl so ein langgezogenes I??) ist genauso zu betrachten, wie der mod_auth_ldap im Apache. Grundsätzlich werden hier, bezogen auf den Anmeldevorgang am Webserver, Informationen in dem Server hinterlegt (oder per Cookie in den HTTP-Header eingestellt). Dadurch wird jeder Request prüfbar.

Das eigentliche Thema, und hier begann mal mein Wunsch und offenbar nicht nur meiner, besteht darin, sich nicht extra am OPN anmelden zu müssen und die entsprechenden Rechte aus einer übergeordneten/beigeordneten Umgebung zu beziehen. Das setzt voraus, dass sich der OPN Server "unterhalb" eines Authentisierungs-Systems befindet das bereits einen Authentication-Cookie gesetzt hat. Wie sich dieser zusammensetzt und welche Rechte sich daraus ableiten lassen kann dann entweder von einem Directory-Server oder einer Datenbank geholt werden. Die Verwaltung der Benutzer ist dann jedoch zentral.

Ich bin offen für jede Diskussion zu diesem Thema, wohl wissend, dass nicht jeder solch eine Implementierung braucht. OPN hat eine stabile und vernünftige Benutzerverwaltung, die für sich alleine betrachtet vieles um Längen schlägt. Wenn diese noch durch eine andere Background-Technik erweiterbar wäre, würde es heute vielleicht wenigen, morgen aber unter Umständen mehreren Anwendern helfen.

Jochen


Zitieren Druckerfreundliche Darstellung nach oben
xweber
Registriert: 22.08.2001
Beiträge: 1496


Sende eine Private Nachricht an xweber
Geschrieben: 03.05.2006 12:15

Bin gerne dabei eine enspreche Umsetzung zu realisieren. Wir sollten uns vielleicht im IRC zu einem Gesprächskreis treffen. Dann kann jeder was mitnehmen (das ist ein absoluter Insiderwitz den nur eingeweihte verstehen können)

Alex


Zitieren Druckerfreundliche Darstellung nach oben
stefan
Wohnort: Münster


Sende eine Private Nachricht an stefan
ICQ
Geschrieben: 03.05.2006 13:37

jgrotepass schrieb am 02.05.2006 um 18:03:15 Uhr folgendes:


@stefan

... bis hin zu unseren Umgebungen und, falls gewünscht/gestattet, unsere/meine Mitarbeit daran. An sowas sollte es nicht scheitern.



Diese Art von Sätzen ist für mich nach Jahren OPN sehr negativ behaftet. Den Gebrauch solcher Sätze sollte man in meiner Gegenwart besser einstellen. Dieses zu verstehen setzt Insider Wissen voraus das alex liefern kann.



Zitieren Druckerfreundliche Darstellung nach oben
xweber
Registriert: 22.08.2001
Beiträge: 1496


Sende eine Private Nachricht an xweber
Geschrieben: 03.05.2006 14:52

@stefan: bei jgrotepass ist alles anders. Ein Mann, ein Wort.

Alex


Zitieren Druckerfreundliche Darstellung nach oben
sortieren nach
Seite 1 2 vorherige Seite 

Hilfe anzeigen
Hilfe anzeigen
Vorheriges Thema:  Fehler nach Themewechsel
Nächstes Thema:  Mail gehen nicht immer durch

Gehe zu:

Benutzername:
 
Sicherheits-Code
Sicherheits-Code
Neu laden