OpenPHPNuke - das Open Source CMS

Autor	mongfevned
Datum	03.04.2006 09:05
Beiträge:	hi wiedermal heute sitz ich grad so herum - verwalte ein bisl das OPN... kommt dir doch glatt der Gedanke: Hey, Single Sign On wär fein Fiel mir deshalb ein weil unser zukünftiges ELAK System das nat. auch beherrscht. Deshab mal meine Frage: Besteht die Möglichkeit das unsere User sich über NDS od. LDAP nicht nur am PC sondern auch gleich auch am Portal anmelden ? lg, Mong

Autor	mongfevned
Datum	03.04.2006 17:41
Beiträge:	mhhh..keiner ne idee?

Autor	golive
Datum	04.04.2006 09:06
Beiträge:	eine LDAP Synchonisation fände ich auch cool - für das Intranet hier.... VG go

Autor	hardliner
Datum	04.04.2006 12:30
Beiträge:	Wie geht OPN mit Verzeichnispfaden um die auf anderen Servern liegen. Also im Intranet bestimmte Freigaben auf anderen Servern? Kann OPN damit umgehen? lg hardliner

Autor	golive
Datum	04.04.2006 16:42
Beiträge:	dafür gibts vermutlich den dokuviewer - wenn ich nur wüsste wie er funktioniert.... und ob er funktioniert... vg go

Autor	Gast
Datum	06.04.2006 12:45
Beiträge:	homberg sag doch was lg, mong

Autor	Gast
Datum	18.04.2006 10:02
Beiträge:	fragewiederherauskramundaufantworthoff

Autor	hombergs
Datum	23.04.2006 23:11
Beiträge:	So mal Antworten. Das Problem bei LDAP sind einige. 1. LDAP kann kein SQL. 2. Woher weiss der LDAP Server das User X auf Compi Y eingeloggt ist. Normalerweise wird der Name an den LDAP Server gesendet. Der übermittelt dann das Passwort und der Compi verlgeicht beide miteinander. 3. Was ist wenn der User für die Seite ein anderes Passwort als für seinen Compi haben will (Ich gehöre z.B. zu dieser Gattung User). Wie man sieht nich alles so einfach. 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.

Autor	Gast
Datum	27.04.2006 17:11
Beiträge:	danke hom! aber ich denke es ist swicher möglich ne Schnittstelle zu schaffen , oder ? lg, mong

Autor	golive
Datum	28.04.2006 10:02
Beiträge:	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

Autor	hombergs
Datum	29.04.2006 01:55
Beiträge:	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.

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

Autor	stefan
Datum	02.05.2006 13:56
Beiträge:	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

Autor	xweber
Datum	02.05.2006 17:03
Beiträge:	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

Autor	jgrotepass
Datum	02.05.2006 18:03
Beiträge:	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

Autor	xweber
Datum	03.05.2006 12:15
Beiträge:	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

Autor	stefan
Datum	03.05.2006 13:37
Beiträge:	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.

Autor	xweber
Datum	03.05.2006 14:52
Beiträge:	@stefan: bei jgrotepass ist alles anders. Ein Mann, ein Wort. Alex

Diese Seite drucken

Diese Seite schließen

Dieser Artikel kommt von: OpenPHPNuke - das Open Source CMS

http://www.openphpnuke.info/