Authentifizierung beim Anzeigen externer Inhalte

Andreas

Gegeben: Ein REI-System mit Benutzerverwaltung und ein externer HTTP-Server, der auf die REI-Datenbank zugreift.

(Der externe HTTP-Server läuft am selben Host und schützt sich gegen die weite Welt, indem er nur mit 127.0.0.1 spricht. Und er muß natürlich mithilfe der REI-Datenbank feststellen, was der Benutzer überhaupt sehen darf, was aber ein separates Thema ist.)

Gesucht: Die extern generierten Seiten sollen in REI eingebettet werden. Wichtig ist die Authentifizierung, damit kein Bösling einfach den externen Server aufruft und so an Daten herankommt, die nur in bestimmte Forms eingebettet werden sollen.

Klar ist, daß ich in REI in Javascript irgendeinen Hash generiere nach einer Rezeptur, die der externe Server kennt, sodaß der dann diesen Hash verifizieren kann.

Störend ist, daß in 2 von 3 Aufrufmethoden nur GET zur Verfügung stehen dürfte. Man sagt, daß das übertragen von Tokens/Hashes/Paßwörtern über HTTPS GET nicht mehr so insecure ist wie es über HTTP definitiv war.

iFrame - GET, der URL kann ab 3.10 versteckt werden.
Textfeld in der Darstellung URL - GET, URL kann nur mitsamt dem Link-Icon versteckt werden, auf den der Benutzer klicken muß. Außerdem wird der externe Inhalt nur in einen separaten TAB angezeigt. Ausgeschieden.
API-Aufruf in JavaScript und Resultat in Rich Text Feld, das nur gelesen wird, speichern. Erlaubt POST und kann in Formular eingebettet werden, erlaubt aber keine Interaktion mit dem angezeigten Inhalt (bzw. habe ich da noch nicht die Grenzen gesucht).
Neue Idee: API-Aufruf plus iFrame: Der API-Aufruf mit POST, der die Authentifizierungsparameter enthält, liefert einen zufällig generierten Einmal-URL unter dem der Server den Inhalt über GET bereitstellt. Dieser URL wird von JavaScript in das iFrame-Feld kopiert.

Getestet habe ich letzteres noch nicht.

Ist das das Ende der Fahnenstange? Habe ich etwas übersehen?

gabriel

Grundsätzlich ist GET für den Zweck der richtige Ansatz, da Ressourcen geholt, aber auf dem Webserver nichts geändert werden soll. POST-Calls sollten, wenn man nach dem Standard geht, Daten auf dem Webserver ändern. Ob man POST oder GET verwendet, ist keine Frage der Sicherheit.

GET kann sicher sensible Daten übertragen - und das in 3 Varianten:

Getter parameter, also Token/hash/etc. als Teil der URL im Query-Part. Beispiel: https://my-system.com?token=123). Mit HTTPS wird der Getter-Teil verschlüsselt, nur die Domänenteil bleibt lesbar für DNS-Zwecke.
HTTP-Request Header: So machen es die allermeisten APIs und auch die meisten authentifizierten Web-Anfragen. Authentifizierungsdaten werden als Header im GET-Request übertragen und sind somit verschlüsselt.
Authentifizierungsdaten im GET-Request-Bodies. Eigentlich sollten GET-Requests keinen Body haben - der Standard lässt es aber zu und viele APIs nutzen das. Der Request-Body ist immer verschlüsselt.

So funktionieren GET-Calls allgemein und erlauben den sicheren Zugriff auf sensible Ressourcen.

Wenn du iFrames nutzen möchtest, um externe Inhalte in r3 einzubinden, hast du aber eine Einschränkung: Du hast nur eine URL - keine Header und auch keinen Request-Body. D. h. von den oben genannten Optionen bleibt nur Option 1.