AW: AW: AW: LDAP-Auth. auf mehreren Apache-Servern ->Single Sign- On

["Lenz, Steffen" <St...@FIZ-Karlsruhe.DE>]

hi,

zunächst mal vielen Dank! Aber irgendwie hat mir die Diskussion um die
Cookies nicht wirklich weitergeholfen.

Sollte meine gewünschte Funktion mit Cookies lösbar sein, dann nehm ich doch
aber an, wenn ihr von PHP-Funktionen redet, daß ich ohne Programmierung
nicht weiterkomme. Ist das richtig?

Ich habe zunächst gehofft, daß ich mit dem selben "AuthName" das mehrmalige
Prompten der Passwortabfrage verhindern kann. Scheinbar geht das aber nur
innerhalb eines Hosts:
"Therefore, you can prevent a user from being prompted more than once for a
password by letting multiple restricted areas share the same realm. Of
course, for security reasons, the client will always need to ask again for
the password whenever the hostname of the server changes."

Kann irgendjemand bezüglich der Cookies eine gesicherte Aussage treffen und
mir vielleicht auch mit Beispielen weiterhelfen oder einen anderen
Lösungsvorschlag unterbreiten?

Im Vorraus besten Dank,
Gruß Steffen Lenz

> -----Ursprüngliche Nachricht-----
> Von: Erik Abele [mailto:erik@codefaktor.de]
> Gesendet am: Montag, 7. März 2005 14:05
> An: users-de@httpd.apache.org
> Betreff: Re: AW: AW: LDAP-Auth. auf mehreren Apache-Servern ->Single
> Sign-On
> 
> On 07.03.2005, at 13:52, Dieter Soost wrote:
> 
> > Hallo,
> >
> >>> Cookies werden nur vom Netz zum PC "gesendet", nicht 
> zurück. Zurück
> >>> zum Netz
> >>> (Server) kommen sie durch "Abfrage".
> >>>
> >>> D.h., der Server "fragt" den PC, ob er einen bestimmten 
> Cookie hat.
> >>
> >> Na das wäre ab äusserst unpraktisch bzgl. Sicherheit - da 
> könnte ein
> >
> > Genau deshalb wird ja immer vor diesen "harmlosen" Keksen gewarnt...
> 
> Nein, das hat andere (aber ähnliche) Gründe.
> 
> >> Webmaster ja einfach alle Cookies seiner Nutzer auslesen (bzw.
> >> 'Abfragen' wie Du es nennst) und die dazu verwenden um sich auf den
> >> entspr. Seiten zu authentifizieren... hmmm... da solltest Du mal
> >
> > Ne ne, so einfach ist das nun auch wieder nicht. Man kann 
> die Dinger 
> > nämlich
> > auch verschlüsseln, was jeder macht, schon dehalb, damit 
> der User nicht
> > sieht, was da drin steht...
> 
> Haha, ist doch mir egal was da drinsteht, wenn die 'verschlüsselte' 
> Cookie-Version vom Server akzeptiert wird und genau das macht was sie 
> soll. Ich denke das ist Augenwischerei mit der Verschlüsselung...
> 
> > Btw: Hast Du noch nie einen "sextrackercom" Cookie auf der Platte 
> > gehabt ?
> > Dazu musst Du nicht mal die Seiten besuchen, die der Name 
> suggeriert...
> 
> Naja, es kann ja ein bel. Cookie vom einem Server 'gesetzt' 
> werden aber 
> eben nicht ausgelesen/abgefragt - du bekommst da momentan ganz 
> eindeutig was durcheinander.
> 
> >> gründlich drüber nachdenken.
> >
> > Ich habe drüber nachgedacht ;-)
> 
> Scheint mir nicht so, sorry :(
> 
> > Deswegen werden von meinem System grundsätzlich Cookies 
> abgelehnt. Ok, 
> > das
> > schränkt meine Surf-Möglichkeiten natürlich ein, aber "Trau 
> - Schau- 
> > Wem"
> > :-)
> >
> >>> Schau mal ins PHP-Manual: "GetCookie", ist einer der Befehle.
> >>
> >> Lt. http://www.php.net/manual-lookup.php?pattern=GetCookie&lang=de 
> >> gibt
> >> es keinen 'Befehl' mit diesem Namen;
> >
> > Sorry, dann heist wohl so meine selbstdefinierte Funktion 
> im include 
> > so.
> > Müsste ich mal nachschauen, wie genau die Funktion heisst, 
> ist schon 
> > Jahre
> > her (Wenn includes fertig sind und funktionieren, sehe ich da nie 
> > wieder
> > rein).
> >
> > Aber ok, wird langsam OT das Thema... :-)
> 
> Ok, das ist tatsächlich OT aber wie sieht es denn dann mit den 
> verwendeten HTTP-Headern aus? Was macht denn Deine selbstdefinierte 
> Funktion in dieser Richtung? Gibt es bei Dir etwa einen 
> Get-Cookie-Header mit dem der Server den Client zur 
> Übermittlung eines 
> Cookies veranlasst? Und wann macht das der Client dann? Bei der 
> nächsten Verbindung? Oder ist bei Deiner Theorie in diesem 
> Fall gar der 
> Server der Client?
> 
> Naja, no comment...
> 
> Cheers,
> Erik
> 

--------------------------------------------------------------------------
                Apache HTTP Server Mailing List "users-de" 
      unsubscribe-Anfragen an users-de-unsubscribe@httpd.apache.org
           sonstige Anfragen an users-de-help@httpd.apache.org
--------------------------------------------------------------------------

RE: AW: AW: LDAP-Auth. auf mehreren Apache-Servern ->Single Sign-On

[Steffen Heil <li...@steffen-heil.de>]

Hi

> Sollte meine gewünschte Funktion mit Cookies lösbar sein, 
> dann nehm ich doch aber an, wenn ihr von PHP-Funktionen 
> redet, daß ich ohne Programmierung nicht weiterkomme. Ist das richtig?

Mit reiner Konfiguration kannst du dein Vorhaben vergessen.

> Ich habe zunächst gehofft, daß ich mit dem selben "AuthName" 
> das mehrmalige Prompten der Passwortabfrage verhindern kann. 

Nein, natürlich nicht.
Stell dir vor jemand gibt seiner Seite den AuthName von ebay.de. Nach deiner
Vorstellung würde dann der Browser beim betreten der Seite die ebay-Login
fleißig ausplaudern... Nein....

> Kann irgendjemand bezüglich der Cookies eine gesicherte 
> Aussage treffen und mir vielleicht auch mit Beispielen 
> weiterhelfen oder einen anderen Lösungsvorschlag unterbreiten?

In der Tat kannst du das so einfach gar nicht umsetzen.
Cookies und alles andere (z.B. gespeicherte Kennworter) werden per-Host
gespeichert. Sobald du irgendwo einen direkten Link auf eine andere Domain
hast, ist dein Login futsch. Das kannst du als gesichert annehmen.

Was unser CMS z.B. macht: Es erkennt (unter bestimmten Umständen) Links auf
andere Domains, die auf demselben Serververbund laufen und ersetzt die Links
in die fremde Domain gegen Links auf ein spezielles Wechselmodul. Dieses
erzeugt einen eindeutigen Zufallscode und speichert in einer Datenbank zu
diesem Code alle Logindetails. Dann wird weitergeleitet auf ein passendes
Gegenstück auf dem anderen Server, mit dem Zufallscode als Parameter. Dieses
Modul wiederum liest die Logindetails aus der Datenbank, trägt diese wieder
in der Session ein und geht dann auf die eigentlich erbetene Seite. Die
Zufallscodes sind "lang genug" und nur 1 Sekunde gültig.

Das erfordert insbesondere viel Planung und programmierarbeit im Backend,
alsauch die Modifikation aller Links zwischen den beteiligten Seiten.

Ähnlich funktionieren übrigens Single-Sign-In-Dienste, die du eventuell für
dein Login verwenden kannst, wie z.B. passport.com, nur nehmen die dir viel
Arbeit ab.

Gruß,
  Steffen