[TYPO3-german] Partnerwebsite mit Zugriff auf fe_users

[Stephan Schuler]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hallo Julian.

Dass dir der Crossdomain-Krempel irgendwann um die Ohren fliegt war abzusehen.
Gerade wenn es darum geht, Daten von einer Domain auf eine andere zu übertragen ist vollkommen in Ordnung, dass vieles von Browsern verhindert wird.

Bleiben wir mal bei deiner Benennung: Seite A ist die die schon länger existiert, das TYPO3 und das mit den Benutzerdaten. Seite B die neue.

Vorweg: Ich beschreibe den Weg. Das sind keine TYPO3-Boardmittel die man einfach dazu klicken kann. Ich will nicht ausschließen dass es hierfür passende Module auf Github, git.typo3.org oder im TER gibt, aber das ist mir bei der Wegbeschreigung erst mal egal.

Die Seiten A und B brauchen ein gemeinsames Geheimnis um den Datenaustausch zu signieren. Nur so kannst du sicherstellen, dass die Anmeldeanfrage sowie die Rückmeldung inklusive Benutzerdatenpaket von den richtigen Servern kommen und zwischendrin nicht verändert wurden.

Für die Signatur schau dir zum Beispiel die TYPO3-Klasse TYPO3\CMS\Extbase\Security\Cryptography\HashService an. Die verwendet als Geheimnis den TYPO3-Encryption-Key. Den würde ich dafür nicht verwenden, du willst deinen Encryption-Key nicht außerhalb deiner TYPO3-Installation liegen haben.

Auf Seite B legst du eine Loginseite an.
Diese Seite kennt die Loginseite von A.
Wenn der Benutzer auf diese Seite klickt, darf der Server B die aktuelle Uhrzeit signieren, ihn als GET-Parameter an die URL der Loginseite von Server A hängen und dann einen Header-Redirect auf die Seite A machen.

Der Benutzer sieht jetzt auf Seite A ein Loginformular.
Server A kann das Uhrzeitargument validieren und sich überlegen, ob der Request gültig war (Signatur valide und Request zeitlich im Rahmen).

Hier darf sich der Benutzer nun anmelden, so wie TYPO3 das gerne hätte.

Wenn der Benutzer sich erfolgreich angemeldet hat, muss der Server A die Loginseite von Server B kennen.
Er packt alle Benutzerdaten die der Benutzer öffentlich sehen darf (Benutzername, E-Mail-Adresse, ggf. User-ID) in einen String, zusammen mit ebenfalls der aktuellen Uhrzeit, und signiert diesen.
Dieser signierte String aller Argumente kommt dann als GET-Argument an die Loginseite von Server B,
der Benutzer wird per Header-Redirect auf Server B weitergeleitet.

Server B kann jetzt die Antwort prüfen. Passt die Signatur zum Datenpaket und ist die Antwort zeitlich im Rahmen?
Wenn ja sind diese Daten alles was der Benutzer braucht.


Loginseite Server B:
* http://server-b/login
* Weiterleitung auf http://server-a/login?now=2015-01-22-16-38&requestHash=khasfkuhwefkh, wobei khasfkuhwefkh die Signatur von "now=2015-01-22-16-38" ist.

Loginseite Server A:
* http://server-a/login?now=2015-01-22-16-38&requestHash=khasfkuhwefkh
* Hier jetzt die Benutzeranmeldung.

Success-Seite Server A:
* http://server-a/login/success
* Weiterleitung auf http://server-b/login?username=ich&email=ich@domain.de&userId=1234&now=2015-01-22-16-41&requestHash=asugrkhsad, wobei asugrkhsad die Signatur von "email=ich at domain.de&now=2015-01-22-16-41&userId=1234&userName=ich" ist.

=> Tada.

Beim der Signatur und Valdierung von Argumenten spielt natürlich die Reihenfolge der Argumente eine Rolle, "userName=ich&userId=1234" wird eine andere Signatur haben als "userId=1234&userName=ich". Eine sinnvolle weil für alle nachvollziehbare Reihenfolge ist die alphabetische Sortierung.

Der sinnvolle Weg dabei ist aber, dass die Anmeldung genau auf dem Server passiert, der die Daten hat -- und das möglichst nicht im iFrame.

Solltest du die Daten nicht durch den Browser schleifen wollen, bleibt dir nur der Weg über eine Schnittstellen-URL.
Die URL "http://server-a/useraccounts?userId=1234" zum Beispiel könnte dir einfach als XML oder JSON die Accountdaten des Benutzers mit der ID 1234 liefern.
Natürlich musst du sicherstellen, dass diese URL nur von erlaubten Quellen aufgerufen werden. Im einfachsten Fall über eine .htaccess-Regel die die Quell-IP auf den "server-b" einschränkt. Oder aber du schickst hier jeweils wieder die signierte aktuelle Uhrzeit mit als Passwort. Einfach das Passwort im Klartext würde ich nicht nehmen, weil GET-Parameter naturgemäß im Access-Log auftauchen, und da will man Passwörter eigentlich auf keinen Fall finden.

Gruß,


Stephan Schuler
Web-Entwickler | netlogix Media

Telefon: +49 (911) 539909 - 0
E-Mail: Stephan.Schuler at netlogix.de
Web: media.netlogix.de




netlogix GmbH & Co. KG
IT-Services | IT-Training | Media
Neuwieder Straße 10 | 90411 Nürnberg
Telefon: +49 (911) 539909 - 0 | Fax: +49 (911) 539909 - 99
E-Mail: info at netlogix.de | Web: http://www.netlogix.de

netlogix GmbH & Co. KG ist eingetragen am Amtsgericht Nürnberg (HRA 13338)
Persönlich haftende Gesellschafterin: netlogix Verwaltungs GmbH (HRB 20634)
Umsatzsteuer-Identifikationsnummer: DE 233472254
Geschäftsführer: Stefan Buchta, Matthias Schmidt



- -----Ursprüngliche Nachricht-----
Von: typo3-german-bounces at lists.typo3.org [mailto:typo3-german-bounces at lists.typo3.org] Im Auftrag von Julian F??rber
Gesendet: Donnerstag, 22. Januar 2015 15:46
An: typo3-german at lists.typo3.org
Betreff: [TYPO3-german] Partnerwebsite mit Zugriff auf fe_users

Hallo Forum,

auf einer Webssite A ist eine sehr große Typo3-Installation mit ca. 20.000 Usern (fe_user) installiert. Nun möchte der Kunde eine Partnerseite B starten, welche mittels dem Framework CakePHP selbst programmiert wurde. Nun soll es eine Schnittstelle geben, so dass es möglich ist, sich auf Seite B mit den Benutzerdaten von A anzumelden.

Technisch wurde das bisher folgendermaßen umgesetzt (zwar zugegeben nicht 100prozentig sauber, aber es funktioniert):
Auf der "Login-Seite" von B wird neben dem Header und Footer ein IFrame eingebunden, welcher eine extra hierfür angelegte Unterseite von A lädt. Auf dieser wurde das ausschließlich der Content-Bereich mit default Anmeldeplugin gesetzt und das Template mittels Parameter (type=99) angepasst, so dass es optisch nicht auffällt. An dieser URL hängen über die GET-Parameter success und error weitere zwei URLS der ursprünglichen Seite B an. Über den Anmelde-Link werden dann die Zugangsdaten gecheckt und im Falle, dass alles korrekt ist, auf eine reine PHP-Seite auf Server A weitergeleitet. Hier wird (unabhängig von Typo3) der per GET übergebene Username aus der fe_users-Tabelle gesucht und die Mail-Adresse des Benutzers selected. Über die header-Funktion gelangt man dann schließlich wieder zurück zu der success-URL, konkateniert mit "/<Mail-Adresse>". Hiermit wird dann der CakePHP-Cookie einfach so gesetzt, um auch in Cake angemeldet zu sein.

So, das funktioniert in allen Browsern ohne Problem.

Ähnliches Spiel beim Logout: Klickt der User auf "Logout", wird ein IFrame geladen, der wieder eine template-angepasste Version des Login/Logout-Plugins enthält. Hier (== Stelle X) muss man dann im IFrame bestätigen, dass man sich abmelden möchte. Bei Success kommt man zu einer extra CakePHP-Seite zurück, die dann (beim Aufruf) die Cake-PHP-Session bzw. den Cookie löscht. Somit wurde man wieder 2x abgemeldet.

Hat auch in allen Browsern funktioniert. Als dann aber Version 11 des IE herausgekommen ist, macht dieser Problem genau an der Stelle X. Ich vermute, es hängt mit neuen Sicherheitspolicies (Scripte von anderen Domains in IFrames) zusammen, leider hat es bis dato aber immer funktioniert.

Aufgrund dessen würde mich interessieren, ob hier einer der Entwickler schon einmal ein ähnliches Problem hatte, bzw. ob es unter Umständen einen ganz anderen Approach gibt, auf die User-Tabelle einer Typo3-Datenbank zugreifen zu können.

Für Hilfe und Tipps bin ich sehr dankbar!
Julian
_______________________________________________
TYPO3-german mailing list
TYPO3-german at lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 3.3.2 (Build 15704)
Charset: utf-8

wpUDBQFUwRwepp0IwsibV8MBCOn+A/9o5qR2ClZIOhV+1KXWQNVB/Jg0yhRNRZU9
WuY0DvsDuTAXwvn1hUQAQZmAkkdiL+9kEka9cXs+7JYdszvXEMEj+SwyGfG+HVZ2
tgqXwozokJAy2b8BNWOKmrs/3CAvHL9O+m/uanoLa8Zf9zuY/E5mpx8YziW/8NMy
mIaE5fKwlA==
=9y6U
-----END PGP SIGNATURE-----