Forum

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

Alex

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.

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

*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

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

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.

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

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.

hmm - vielleicht hab ich mich mit der synchronosation falsch ausgedrückt.

bei einer webbasierten videostreaminglösung die gerade für uns gemacht wird sieht das ganze so aus:

unter active directory weise ich bei einem nutzer nur bestimmte benutzergruppen zu (sagen wir mal webvideo1-5). im adminbereich der software lege ich dann fest was die ldap benutzergruppe webvideo1 für rechte hat,

wenn man also hier im hausnetz die seite aufruft muss ich mich nicht extra anmelden, habe aber jeweils die rechte die für mich vorgesehen sind - ohne extra login...

wenn man analog die brechtigungsgruppen mit den bezeichnungen aus opn für den benutzerlevel abgleicht oder harmonisiert müsste es doch funktionieren - oder ?

viele grüße
go

danke hom!

aber ich denke es ist swicher möglich ne Schnittstelle zu schaffen , oder ?

lg, mong