Hi Anja,
On 17 Apr., 15:52, acl68 <[EMAIL PROTECTED]> wrote: > danke für die schnelle Antwort. Leider ist das genau die Richtung die > ich nicht nehmen kann. Ich brauche die Daten von den anderen > Applikationen, da diese die führende Applikation sind, an die sich > meine nur ranhängt. > Die Userdatenbank, in der die Rechte drinstehen, teilen wir uns schon. > Nur wie kann ich im MVC-Modell von Cake die Userdaten laden ohne ein > zusätzliches Login? SSO ist ein Konzept und beinhaltet mehr als nur das "Teilen von Anmeldedaten". In heterogenen Netzwerkumgebungen wird dazu oft Kerberos eingesetzt, wo man sich gegen einen zentralen Authentifizierungsserver anmeldet und ein Ticket bekommt. Dieses Ticket zeigt man nun bei jeder Anwendung vor und die Anwendungen schauen nun, ob derjenige mit dem Ticket auch berechtigt ist, die jeweilige Anwendung zu benutzen, wieder unter Zuhilfenahme von Kerberos. Kerberos kann natürlich auch für Webapplikationen eingesetzt werden, und hat halt den großen Vorteil, dass es offen und interoperabel ist. Für kleinere Anwendungen gestaltet sich im Kontext von Webapplikationen ein SSO ohne Kerberos schwierig. Dazu muss zuallererst das bisherige Authentifizierungskonzept untersucht werden. Ist es eine "normale" Anmeldung mittels Formulardaten und dem anschließenden Aufbau einer Session, so gibt es nicht viele Optionen. Ein Server A ist der "Anmeldeserver" , er weiß welche Sessions gerade gültig sind und welche Benutzer damit verknüpft sind. Wenn eine Session zustande kommt, dann bekommt der Benutzer entweder a) einen Session-Cookie, einen b) permanenten Cookie oder aber er überträgt mit jedem HTTP-Request eine c) Session-Id in der URL. Der Trick besteht jetzt darin, diese Session-Id zu Server B zu übertragen, damit der bei Server A nachfragen kann, ob diese Session gültig ist und dann anhand dem mit der Session assozierten Benutzer herauszufinden ob dieser die Anwendung auf Server B verwenden kann. Die Lösung ist abhängig vom eingesetzten Umfeld, und je nach Realisierung der Sessionverwaltung auf Server A gibt es Vor- und Nachteile. Permanente Cookies sind oft ungünstig und mitunter ein Sicherheitsrisiko. Session-IDs an URLs anzuhängen birgt Session- Diebstahl über den Referrer, so dass eigentlich nur Session-Cookies übrig bleiben. Wenn ich dieses Problem lösen müsste, dann würde ich Session-Cookies verwenden und vermutlich wird man die Sessionverwaltung auf Server A umprogrammieren müssen, denn mit den Standardmechanismen von PHP (session_start & Co.) gibt es obige geforderte Funktionalität (Abfrage ob Session gültig ist, Zuordnung zu Nutzer) nicht. Aber eine eigene Sessionverwaltung zu programmieren ist nicht soo schwer und ein kurzer Blick ins PHP-Handbuch sagt, dass es dafür auch einige Einklinkpunkte in PHP gibt (oder schmutzige Hacks :) ). Eine unsichere, naive Alternative wäre die Speicherung der Zugangsdaten nach Authentifizierung an Server A im Session-Cookie, so dass Server B diesen auslesen kann und den Benutzer wiederum damit gegen Server A authentifizieren kann. Dazu sollte natürlich auch die Verbindung von Server B zu A verschlüsselt sein und ein Cookie-Klau wirkt sich umso dramatischer aus. Aber vermutlich sind die Änderungen an Server A dafür geringer. MfG, Christian Ulbrich --~--~---------~--~----~------------~-------~--~----~ Bitte bei Fragen immer auch die aktuell verwendete cakePHP Version angeben und wenn möglich auch das verwendete Betriebssystem und die PHP Version. Danke. Sie erhalten diese Nachricht, weil Sie Mitglied sind von Google Groups-Gruppe "CakePHP-de für deutsche CakePHP Entwickler". Für das Erstellen von Beiträgen in dieser Gruppe senden Sie eine E-Mail an [email protected] Um sich von dieser Gruppe abzumelden, senden Sie eine E-Mail an [EMAIL PROTECTED] Weitere Optionen finden Sie in dieser Gruppe unter http://groups.google.com/group/cakephp-de?hl=de -~----------~----~----~----~------~----~------~--~---
