Hallo,

auf meinen Server habe ich seit längerem ein Forum, in welchem sich viele Nutzer bereits angemeldet haben. Nun würde ich gerne diese Nutzerdaten bzw. den Status "angemeldeter Benutzer" in ein zweites System übernehmen (per Link); d.h. dass die gültige Session an das zweite System übergeben.

Z.Z. liegen beide System auf einem Server, die Lösung sollte aber so flexibel sein, dass dies auch über Servergrenzen hinaus funktioniert (der Transfer der Nutzer-Daten ist dann ein anderes Problem).

Eine Suche im Internet war leider wenig erfolgreich, wahrscheinlich weil mit das passende Fachwort dafür fehlt.

Gruß

Hagen

Nur zum Verständnis meinerseits.
Ein im "System A" eingeloggt Benutzer soll, sobald er nach "System B" wechselt, eingeloggt sein.

Wenn das ist, was du willst, brauchst du in der "einfachen" Variante den Loginnamen und den Klartext des Passwortes, von "System B". Damit musst du einen Link generieren, der alles enthält um sich erfolgreich auf dem "System B" ein zu loggen, und diesen dem Nutzer zur Verfügung stellen. Sobald er darauf klickt wird er eingeloggt.
Mit Javascript kann man das im Hintergrund machen, aber davon halte ich nichts.
Der Nutzer sollte bei so was sehen was passiert.

Wenn du einen tieferen Zugriff auf die Systeme hast, kannst du einen Sesessionkey erzeugen, der von beiden Systemen erkannt wird. Dazu ist es nötig eine eindeutige Benutzerkennung und
Zertifizierungsdaten ein zu bauen. GPG würde sich, so meine ich, dazu anbieten. in dem du die mit GPG verschlüsselten Daten als Sessionkey verwendest

Alternativ könnte "System B" bei "System A" nachfragen, ob der Sessionkey gültig ist.

Klingt mir nach Signle-Sign-On

Quote

Nur zum Verständnis meinerseits. Ein im "System A" eingeloggt Benutzer soll, sobald er nach "System B" wechselt, eingeloggt sein.

Quote

Klingt mir nach Signle-Sign-On

Beides ist richtig.

Quote

Wenn du einen tieferen Zugriff auf die Systeme hast, kannst du einen Sesessionkey erzeugen, der von beiden Systemen erkannt wird. Dazu ist es nötig eine eindeutige Benutzerkennung und Zertifizierungsdaten ein zu bauen. GPG würde sich, so meine ich, dazu anbieten. in dem du die mit GPG verschlüsselten Daten als Sessionkey verwendest.

Wie von euch beschrieben, soll für den Benutzer ein Link bereit gestellt werden, in welchem der Benutzer (/ID) und ein Sesessionkey vorkommen.

Da das Forum mit PHP läuft, System B mit Perl und ggf. System C mit ??? würde ich gerne recht einfach Prozesse zur Erzeugung des Sesessionkeys benutzten. Aber wie baue ich diesen sinnvoll auf, damit er sicher ist (z.B. nicht unbegrenzt gültig, nie identisch, ...)

Ein ganz gutes verfahren um einen Benutzer hinreichend eindeutig zu identifizieren, ist sein (Login)Name, sein IP und der Timestamp des Zugiffes, zusammen mit einem Schlüssel (der einzigartig für jedes System sein sollte), mit einem Schlüssel, den jedes System kennt zu verschlüsseln und als Sessionkey zu verwenden. Da relativ einzigartige und für den Benutzer spezifische Werte benutzt wurden, ist auch der Sessionkey einzigartig, und enthält zudem alle nötigen Daten, um den Benutzer zu identifizieren, und die Gültigkeit der ID zu bestimmen.

Um die Gültigkeitsdauer des Key zu bestimmen muss der Timestamp im Key in regelmäßigen Abständen (z.B nach jedem Zugriff) aktualisiert werden. Dadurch ändert sich natürlich der Sessionkey, was aber nicht schlimm ist, da er alle Daten enthält um einen Benutzer zu identifizieren. Das schwächt zwar auch die Verschlüsselung, aber nicht so sehr dass man sich für einen Sessionkey sorgen machen bräuchte. Um das wieder aus zu gleichen könnte man ein wenig Zufallsdaten einstreuen.

Was die Verschlüsselung betrifft so gibt es ein paar weit verbreitete Bibiotheken. Um portabel zu bleiben würde sich wohl eine Bibliothek wie "GCrypt" gut eigenen, da sie gut getestet ist und für viele Systeme/Programmiersprachen zur Verfügung steht.

Mmmh ... interessant, dass du die IP (mit) zur Identifizierung nutzten willst. Ich hatte auch darüber nachgedacht, es dann aber schnell wieder verworfen, da mehrere Benutzer die gleiche IP haben können (wg. Proxy, ...).

Also dein Vorschlag wäre (von der Idee her):



Irgendwie habe ich immer darüber nachgedacht, dass ich zum "verschlüsseln" z.B. md5 anwende. Nur zum entschlüsseln (mir ist klar, dass man md5 nicht rückgängig machen kann) hatte ich keine (gute) Idee.

Was spricht gegen Sessionkey + gemeinsame Datenbank?

Dubu+2008-10-20 21:33:18--

Was spricht gegen Sessionkey + gemeinsame Datenbank?

Gar nichts. Das war nur zum Verständnis.

Naja, ich wollte nur mal darauf hinweisen. Es scheint mir nur, dass Entwicklern manchmal nicht so klar ist, dass Datenbanken (zumindest die meisten) netzwerkfähig sind. Man kann also von einem anderen Rechner genauso auf sie zugreifen wie lokal, auch ohne Skripts, Webserver oder irgendwelche zusätzlichen Programme - zumindest sofern die Zugriffsrechte und evtl. Firewallregeln passend gesetzt sind.

Dubu+2008-10-20 21:33:18--

Was spricht gegen Sessionkey + gemeinsame Datenbank?

Das Ploblem ist der Zugriff. Die Systeme sollen ja nicht alle auf dem selben Rechner laufen. Datenbankzugriffe übers Netz würden mir Bauchschmerzen machen, da so was ein beliebtes Ziel für Angriffe ist. Man könnte die Datenbank hinter einem Script verstecken, aber für dieses braucht man dann wieder eine Benutzerkennung und Zertifizierung. Man könnte über ssh tunneln, aber das wird von einigen Hostern nicht gerne gesehen. Auch die Bandbreite könnte unter Umständen ein Problem darstellen.

Hagen+2008-10-20 21:24:09--

Mmmh ... interessant, dass du die IP (mit) zur Identifizierung nutzten willst. Ich hatte auch darüber nachgedacht, es dann aber schnell wieder verworfen, da mehrere Benutzer die gleiche IP haben können (wg. Proxy, ...).

Eindeutig ist ja nicht die IP sondern "Name + IP + Passwort". Und ich halte es für reichlich unwahrscheinlich, das sich zwei verschiedenen Benutzer über den selben Namen von der selben IP aus mit dem selben Passwort anmelden. Wenn noch was sicherer sein willst kannst du z.B. noch eine md5Summe über die Browser-Kennung machen und mitschicken. (in so ein Cookie passt viel rein :-) )

Hagen+2008-10-20 21:24:09--

Also dein Vorschlag wäre (von der Idee her):

Code: (dl )

1
2
3
4
5
6

index.cgi?action=login&sid=$sid

mit

$timestamp = localtime()
$sid = GCrypt($benutzer_id.'-'.$ip.'-'.$timestamp, 'Schlüssel')

ja so in der Art.
Man kann das noch etwas Verfeineren.

Das "pack('C', int rand 255)" fügt eine ein Byte Zufallszahl hinzu. Das macht das Knacken schwerer
Mit dem "$applicationkey" weißt du wo sich der Nutzer eingeloggt hat. Das ist ganz Sinnvoll, wenn Leute von bestimmten Systemen nicht überall hin dürfen. Kann ein Login von einer Adminseite einen anderen Applikationkey tragen, als der von einem Guestlogin.
Es ist damit auch ersichtlich, das sich der Nutzer woanders Eingeloggt hat, und er unter Umständen nicht ganz so "vertrauenswürdig" ist wie einer, der sich auf dem eigenen System eingeloggt hat.
Mit dem md5-verschlüsselten Passwort kann auch noch nachträglich nach dem Passwort gefragt werden. z.B wenn der User wichtige Daten löschen will.
"$version" beschreibt welcher Schlüssel verwendet werden soll. Das ist nötig, da der Schlüssel regelmäßig ausgetauscht werden sollte. (je nach Wichtigkeit, alle 2Monate bis einmal im Jahr)
Base64 solltest du nutzen, damit die Daten nicht bei der Übertragung oder dem Zwischenspeichern im Browser verstümmelt werden.

Hagen+2008-10-20 21:24:09--

Irgendwie habe ich immer darüber nachgedacht, dass ich zum "verschlüsseln" z.B. md5 anwende. Nur zum entschlüsseln (mir ist klar, dass man md5 nicht rückgängig machen kann) hatte ich keine (gute) Idee.

Der Vorteil ist, das der Nutzer all seine wichtigen Daten mitbringt. Ein System braucht den Nutzer gar nicht zu kennen. Es muss nur der Verschlüsselung trauen können. Mit den übergeben Daten könnte auch ein minimaler Account angelegt werden.

Aber ich will hier nicht in einer Featuritis ausbrechen :-)