Chriz

Hallo,

für ein neues Intranet soll demnächst für die vielen Anwendungen SSO benutzt werden. Ich hab mich in die Materie eingelesen und sie grundsätzlich auch verstanden. Das Skript:
http://www.jasny.net/articles/simple...gn-on-for-php/
habe ich runtergeladen und mit verschiedenen VHosts (2 Broker, 1 Server) getestet, es funktioniert (nach etwas gefrickel). Nur gefällt mir der Code ganz und garnicht, daher möchte ich nochmal resümieren und mir einen Prototype schreiben, vielleicht habe ich ja einen Denkfehler oder das ganze doch noch nicht zu 100% verstanden. Die Sicherheitsaspekte lasse ich mal aussen vor, die kommen dran, wenn ich die Systematik voll verstanden habe.

Mein Verständnis:

War das in etwa richtig?

Wo gilt es hier nun Sicherheitsaspekte einzubauen?

Sollte es möglich sein, dass sich jeder als Broker anmelden kann (er erhält ja eigentlich nur die Info, ob der User sich schonmal woanders eingeloggt hat) oder muss der Loginserver seine Broker kennen? Über Checksummen und ein vereinbartes Passwort zwischen jedem Broker und dem Loginserver wäre das sicherlich möglich.

Wann sollte session_regenerate_id() eingebaut werden? Beim normalen Login ja direkt nach dem Login, damit niemand einem Session-IDs unterjubeln kann, die er selbst erzeugt hat (sie also nicht mehr zufällig sind). Wo wäre das dann hier einzubauen?

__________________
"Nuschel ich?" - "Was?"

Mister Ad

Sirke

Kommt ganz speziell auf die Implementierung an: In einem Firmennetz kann man u.U. den recht großen Overhead an Daten akzeptieren, um ein Single Sign Off aktiv mitzubekommen. In meinem Verständnis wäre ein passives Single Sign Off der Dienstserver besser, indem der Authentifikationsserver die Dienstserver über ein Single Sign Off informiert!

Grundsätzlich kümmert sich bei deiner Herangehensweise der Dienstserver um das Beschaffen der Informationen, wobei ich diese Aufgabe dem Client überlassen würde, der die Informationen heranschaffen soll. Ich würde damit folgenden Ansatz gehen:

1. Der Client möchte einen Dienst nutzen, wofür der Dienstserver eine Authetifikation verlangt.
2. Der Dienstsserver leitet die Anfrage des Clients unter Angabe der ID des Servers zum Authentifikationsserver weiter und verlangt eine Autentifikation!
3. Der Client sendet diese Anfrage an den AuthServer:
   1. ENTWEDER ist der Client noch nicht beim AuthServer authentifiziert und muss sich beim AuthServer mit einer vorgesehenen Methode authentifizieren. Der AuthServer speichert nun in einem Cookie die AuthInformationen des Clients wie bei vielen Anwendungen mit dem "Eingeloggt bleiben".
   2. ODER der Client ist bereits autentifiziert und legt seinen Cookie zur Authentifikation vor.
4. Der AuthServer senden nun eine Antwort an den Dienstserver, ob der Client sich erfolgreich Authentifiziert hat oder dem AuthServer nicht bekannt ist.
5. Für den Fall einer erfolgreichen Authentifikation sendet der AuthServer per Weiterleitung die AuthInformationen zu dem Client an den Dienstsserver, welcher diese Informationen auswertet und den Client authentifiziert.

Für bestimmte Funktionen müssen einige Informationen bei den entsprechenden Servern gespeichert werden:

• Alle DienstServer den Client mit dem AuthServer verknüpfen, ob das über eine immer gleiche ID passiert oder eine eigene ID für jeden Dienst ist Implementierungssache!
• Die Auth Informationen müssen geschützt werden (1. Punkt zur Sicherheit) damit keine Informationen mitgelesen werden können: Dazu müssen sich die DinestServer und der AuthServer einen Schlüssel teilen!
• Der AuthServer speichert bei welchen Diensten der Client zZ eingeloggt ist: Im Falle einen Logouts beim AuthServer weiß diese bei welchen Diensten der Client bekannt ist und kann jedem Dienst mitteilen den Client auszuloggen!

Jeder Dienst kümmert sich selbst im die Sicherheit und die Sitzungs-IDs und erhält vom Auth Server zur die Informationen zu Identität und Authentizität des Benutzers oder einen Logout!

Die Sicherheit spielt hier eine sehr große Rolle und eine Implementierung ist nicht einfach, da kleinste Fehler das System zu Fall bringen können: Der Client darf z.B. das AuthPaket zum Dienst nicht selbst erstellen können und auch nicht mehrfach benutzen können bzw dein Angreifer zu einem späteren Zeitpunkt nochmals. Der Dienst muss eine Bestätigung haben, dass das Auth Paket nur vom Auth Server kommen kann und der Auth Server, dass das Anfrage Paket nur vom Dienst Server kommen kann.

Ich würde mir sehr viele Gedanken zu der Sicherheit machen, da die Vergangenheit gezeigt hat, wie viel man falsch machen kann, sodass ein ganzes System in wenigen Sekunden ausgehebelt ist!

Deine Herangehensweise war eine etwas andere, welche auch möglich ist, aber in meinen Augen mehr Nach- als Vorteile hat! Ich würde mir als erstes eine Anforderungsliste machen, damit man abschätzen kann, was wie implementiert werden kann... Gerade auch der Unterschied Portal-System oder Ticket-System!

Chriz

Hallo,

danke fuer deine ausfuehrliche Antwort.

Der Overhead gefaellt mir auch nicht so wirklich, aber wenn es einen gemeinsamen Login gibt, finde ich einen gemeinsamen Logout nur logisch. Da man als PHP-Entwickler zwangslaeufig an die Einbahnstrasse Client-Server-Kommunikation denkt, ist mir das neue Konstrukt Server-Server-Kommunikation in diesem Zusammenhang garnicht in den Sinn gekommen.


Du meinst also der Login wird vom Client (Browser) direkt beim AuthServer und nicht ueber den DienstServer durchgefuehrt?


In meinem Fall waeren das die Session-IDs der jeweiligen DienstServer mit ihrem Client. Ich bin aber nicht sicher ob ich dich hier richtig verstanden habe, meinst du die Session-IDs der verschiedenen DienstServer sollten gleichgeschaltet werden? Hat das irgendeinen Vorteil?

Du meinst die Kommunikation zwischen DienstServer und AuthServer muss verschluesselt werden (SSL) oder nur faelschungssicher sein (Checksummen)?


Solange es funktioniert. Irgendwie bin ich damit trotzdem nicht so ganz gluecklich, kann aber nicht genau sagen wieso.
Ich versuchs mal: Ein Dienst hat fuer mich Eigenschaften wie Verfuegbarkeit, etc. Der Dienst ist allerdings ein Webserver, unwahrscheinlich, dass der Webserver mal ausfaellt oder in einem Husten den Request verschluckt, aber auch nicht unmoeglich. Dann waere der Benutzer fuer den einen Dienst vielleicht doch nicht ausgeloggt. Ganz bloed: Mr. Evil faehrt den DienstServer A runter/ueberlastet ihn und wartet bis Mr. Nice sich ausloggt (ueber Dienst B, in der Annahme auch bei Dienst A ausgeloggt zu sein) und in die Kantine geht. Dann gibt Mr. Evil die Kiste wieder frei, geht an den Rechner von Mr. Nice und ist doch noch eingeloggt fuer Dienst B. Um das zu verhindern muesste ich dem AuthServer sagen, dass er es solange probieren soll, bis er alle Dienste erreicht hat. Oder aber der Logout wird erst bestaetigt, wenn alle Dienste informiert sind, wodurch sich ein Logout dann moeglicherweise etwas verzoegert. Diese erhoehte Komplexitaet finde ich etwas gefaehrlich.


Sprich der DienstServer muss sich ein Ticket beim AuthServer holen, dass der Client dann einloesen kann?


Was du mit Ticketsystem meinst vermute ich mal: ein unsicherer Kommunikationspartner bekommt ein von einem sicheren Kommunikationspartner ausgehandeltes Ticket fuer eine einmalige Kommunikation mit dem AuthServer [oder einem Pendant, je nach dem fuer was man das Ticketing einsetzen will]. Portal-System sagt mir jetzt nichts.

Danke nochmal fuer deine Antwort, freue mich wenn du nochmal Zeit fuer ein paar Antworten findest.

Gruss,
Christian

__________________
"Nuschel ich?" - "Was?"

ChrisB

Wenn Mr. Nice nicht wenigstens seinen Rechner sperrt, so dass andere keinen Zugriff auf seinen Browser haben, dann ist er Mr. Dumb.

__________________
RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?

Chriz

Hehe richtig, das Problem befindet sich eben haeufig zwischen Tastatur und Stuhl. Das Thema Sicherheit und Unsicherheitsfaktor Mensch ist eben so eine Sache.

[offtopic]
Lustiges Beispiel zu Datenschutzrichtlinien (an die Entwickler), die mir kuerzlich untergekommen sind:
- Passwoerter muessen als Hash abgespeichert werden
- Passwoerter muessen mindestens halbjaehrlich vom Benutzer geaendert werden
- Neu gesetzte Passwoerter duerfen nicht einem vorher verwendeten Passwort entsprechen oder zu Teilen aus dem alten Passwort bestehen

Wer einen Algorithmus findet, der Richtlinie 1 und 3 vereint, der kann sich gesegnet fuehlen - vielleicht eine Anstiftung zur Verwendung von Rainbowtables? Naja ...
[/offtopic]

__________________
"Nuschel ich?" - "Was?"

Sirke

Ich bin in meinen Ausführungen etwas gesprungen, daher versuche ich mal das ganze etwas besser zu strukturieren:
Neben vielen verschiedenen SSO Varianten gibt es an sich zwei große Herangehensweisen: (1) dem Portal-System und (2) dem Ticket-System. Die erste Variante verwendet den AuthServer wie bei deinen ersten Ausführungen wie eine Datenbank und mit einer festen API zum Beschaffen aller Informationen. Hierbei kümmert sich jeder Dienst um die Kommunikation mit dem AuthServer selbst im Hintergrund. Bei der zweite Variante stellt der AuthServer Tickets zum Login bei den Dienstservern aus, welche zum einmaligen Login eingesetz werden.

Jain, in meinem Verständnis von SSO holt sich der Client das Ticket vom AuthServer - wird jedoch vom Dienstserver durch einen Redirect dazu veranlasst.

Ja, wieder in meinem Verständnis von SSO authentifiziert sich der Client beim AuthServer und der AuthServer bestätigt dann jedem Dienst die Authentizität des Clients.

Nein, hierbei ging es rein im die ID des Clients zur Identifikation und nicht um eine Session ID. Ein Benutzer registriert sich bei dem AuthServer mit seinen Informationen und erhält dort wie in jeder Datenbank eine ID. Damit nun der AuthServer dem Dienstserver die Identität des Benutzers mitteilen kann, muss der diesem die ID des Clients übermitteln. Das habe ich mit der Verknüpfung gemeint! Die Ausführung über unterschiedliche IDs habe ich hinzugefühgt, da die Dienste u.U. keine Verknüpfungen zwischen den bei ihnen angemeldeten Benutzern herstellen können sollen. Kennt jeder Dienst die selbe ID wie der AuthServer und damit alle die selbe ID zu jedem Benutzer, dann können sie diese Informationen verknüpfen...

Ich meine hier muss gewährleistet sein, dass die Tickets vertraulich und fälschungssicher sein müssen. Daher würde ich die Tickets selbst verschlüsseln, unanhängig ob die Schicht vorher bereits eine Verschlüsselung vorsieht, falls es Dienste ohne SSL gibt. Sicherheit auf andere Schichten oder Dienste zu übertragen halte ich für sehr gefährlich: Jedes Sicherheits Protokoll muss ohne zusätzliche Vorraussetzungen zur Sicherheit möglich sein!!!

Das Szenario kannst du auch ohne SSO bauen, indem ein Angreifer einen Server überlastet, sodass der Client sich selbst bei dem nicht ausloggen kann. Da der Benutzer in die Mittagspause muss, kann er auch nicht warten, bis der Dienst wieder da ist.
Die ganze Single Sign Off Geschichte ist in meinen Augen nicht ganz leicht, da sich beide Seiten (AuthServer und DienstServer) um den Status kümmern müssten. Gerade der Dienstserver muss sicher sein, dass der Benutzer nicht schon ausgeloggt ist. Hier gibt es viele Herangehenweisen: (a) Logout wird vom AuthServer initiiert und der DienstServer lässt bei kritischen Aktionen immer nochmals gegenprüfen. (b) Der Status wird vom DienstServer alle X Minuten beim AuthServer erfragt. (c) Der AuthServer ist kein WebServer im eigentlichen Sinne mehr und lässt sich beim globalen Logout den lokalen Logout bei den Diensten bestätigen und versucht bei Unerreichbarkeit bzw keiner Bestätigung druchgehend den Dienst zu erreichen, bis er eine Bestätigung bekommen hat - vorsicht: hier kann ordentlich Traffic entstehen!

xm22

Würde ja auch nichts bringen, da man nicht weiß, ob das gefundene Resultat tatsächlich dem Passwort entspricht

Chriz

Hallo Sirke,

ich muss jetzt erstmal abwarten, welche Anforderungen nötig sind, ein Konzept habe ich hier vorgeschlagen. Grundsätzlich finde ich das Ticket-System sehr gut.

Danke für deine Ausführungen, auch speziell zum Logout-Thema.

Ich gebe zu gegebener Zeit noch einmal Feedback.

__________________
"Nuschel ich?" - "Was?"