Links einbinden mit Hilfe von OpenID

Guido 2020-06-06 17:38:09 UTC #1

@all,
ich möchte einen Link in der Egroupware mit Hilfe der Anwendung OpenID erstellen und weiß nicht genau wie das im Detail funktioniert.

Die Egroupware dient bei uns für alle Mitarbeiter als Arbeitsplattform und ich möchte für mein Team Links zu unseren Gude-Powerswitches im Intranet bereitstellen. Das sind 220V Stromschalter im Rackformat, die über eine eigene Weboberfläche verfügen. aus Sicherheitsgründen sollen sie nicht direkt von außen erreichbar sein und wären von daher hinter der Sicherheitsabfrage der Egroupware sehr gut aufgehoben.

Also Ziel ist es sich in die Egroupware einzuloggen, über den mit OpenID erzeugten Link den Powerswitch zu erreichen und dort angeschlossene PCs, Server oder Workstations bei Bedarf einzuschalten, über Guacamole darauf zuzugreifen und die Geräte nach Verwendung dann wieder auszuschalten.

Mal sehen, ob das reibungslos klappt.

Stefan hat bereits seine Unterstützung angeboten.

Hallo Stefan, wie gehe ich da nun vor?

Viele Grüße,
Guido

RalfBecker 2020-06-07 07:25:45 UTC #2

Hallo Guido,

das ist möglich, allerdings nicht ganz so einfach wie Du vielleicht denkst. Es gibt zwei Probleme:

ich gehe mal nicht davon aus, dass die Steckdosenleiste selbst OAuth2 oder OpenID Connect unterstützt
in einer Webseite die https benutzt darfst Du keine iframe mit http aufmachen, https wird in der Regel von der Steckdosenleiste auch nicht unterstützt

Beide Problem sind technisch auf die gleiche Weise lösbar: Du brauchst einen Proxy der neben der Umsetzung nach https auch noch die Authentifizierung per OAuth unterstützt. Nginx kann das zum Beispiel:

Für die Steckdosenleiste ist das allerdings “mit Kanonen auf Spatzen geschossen” wie man so schön sagt. Da könnte vermutlich ein PHP Skript das wir einfacher mitliefern könnten das Gleiche bei ausreichender Performance und automatische Konfiguration erreichen.

EGroupware’s OpenID Connect / OAuth2 Server kann andere Anwedungen Autorisieren die OAuth2 als Client zur Authorisierung unterstützen, er kann momentan nicht als Proxy arbeiten der gegen sich selbst autorisiert.

Dafür braucht es ein externes Tool wie Nginx (siehe obigen Link) oder für einfachere Benutzung und automatische Konfiguration bei geringerer Performance ein zusätzliches Proxy-Skript.

Beides finde ich eine sehr interessante Ergänzung, da es vermutlich ein häufigeres Problem ist, das man nicht oder nur unzureichend autorisierende andere Webdienste sicher bereit stellen will.

Ralf

RalfBecker 2020-06-07 07:45:46 UTC #3

Habe noch eine weitere Alternative gefunden:

Die Nginx Lösung ist vermutlich deutlich komplexer und erfordert entweder Nginx PLUS oder deutlich mehr Konfiguration, auch wenn wir das dort angesprochene Problem das auth_request Module einen HTTP Status braucht mit unserem /userinfo Endpunkt relativ einfach realisieren kann.

Wenn man keine extremen Performance Ansprüche hat und keine Websockets braucht, wäre eine PHP Skript die deutlich universellere Alternative. Es schließt ja andere externe Lösungen nicht aus.

Ralf

Guido 2020-06-07 08:20:39 UTC #4

Hallo Ralf,
danke fürs Feedback.

Wie aufwändig wäre denn die Erstellung eines solchen Skripts?
Muss man das dann für jeden http-Link neu erstellen/ergänzen oder wäre das mit einer Anfertigung getan?

Ich habe mittlerweile etwas rumgespielt, die Clients in der Anwendung lassen sich jetzt ordentlich deaktivieren, jedoch bleibt das Icon in der linken Taskleiste trotz Deaktivierung weiterhin präsent. Wäre sinnvoll, wenn das bei Deaktivierung ausgeblendet würde. Wie bekommt man das denn so wieder los?

Viele Grüße,
Guido

RalfBecker 2020-06-07 08:42:53 UTC #5

Ich denke das ich da einen Tag beschäftigt bin.

Nein, das wäre ja das schöne bei so einem Skript, das könnte komplett automatisch aus der OpenID App heraus konfiguriert werden, sprich Du machst nur einen Haken an Proxy und dann macht die App alles andere.

Ist ein bekannter Fehler, der auf meiner Liste zur Behebung steht. Workaround ist die App im Setup zu löschen.

Ralf

Guido 2020-06-07 10:54:05 UTC #6

Zunächst mal führe ich hier die kleinen “Bugs” auf, die ich bisher gefunden habe:

Deaktivieren sollte das Entfernen des Icons beinhalten
Reiter “Gemanagt als Egroupware Anwendung”: Felder “Anwendungsname” und “Start Adresse” lassen sich nicht mehr editieren, wenn einmal etwas eingegeben worden ist.
Reiter “Gemanagt als Egroupware Anwendung”: Im Feld “Erlaubt für” muss immer irgendwas stehen, dort alle Berechtigungen zu entnehmen funktioniert nicht.

Dann mache ich nun noch einen weiteren Test unseren Router per https zu erreichen.

Wird leider mit folgender Fehlermeldung quittiert:

192.168.1.1 hat die Verbindung abgelehnt.

Gruß,
Guido

StefanU 2020-06-07 14:29:21 UTC #7

Hallo Guido,

Bitte mache für so etwas jeweils ein Thema auf. Dann können wir das kleinteilig durchgehen.

Dieses Thema habe ich die neu geschaffene Kategorie “Further Apps” verschoben. Ich muss die noch beschreiben… Aber das gehört es jetzt hin.

Gruß
Stefan

StefanU 2020-06-07 14:30:05 UTC #8

grafik

Ist das eine IPFire, die du versuchst zu integrieren?

Wer zeigt das wo?

Stefan

Guido 2020-06-07 14:53:08 UTC #9

Es ist ein Vigor 2960 und der Fehler erscheint, wenn man das neu erzeugte Icon dazu in der Egroup anklickt im Fenster rechts (iframe).

Guido

StefanU 2020-06-07 15:14:12 UTC #10

Was passiert denn, wenn du die eingetragene Adresse direkt aufrufst, sprich in einem eigenen Browser-Tab?

Sieht das denn nach einer Meldung vom Router aus? Dann mal im Router-Log schauen…

Habt ihr einen Proxy in Verwendung?

Stefan

Guido 2020-06-07 15:37:56 UTC #11

Dann gelangt man auf die Loginseite des Routers

Ja, tut es. Wird denn der Port bei den Links berücksichtigt?

Nein.

Guido

StefanU 2020-06-07 15:47:18 UTC #12

Also ich habe das hier mit Proxmox und Port 8006 eingetragen und es funktioniert. Das sollte nicht das Problem sein.

Gibt das Log von dem Router etwas her?

Weißt du, wie man mit Webbrowser Entwicklertools umgeht?
Damit müsstest du mal schauen, ob der Router ein X-Frame-Options-Eintrag mitgibt.

Stefan

Guido 2020-06-07 16:40:33 UTC #13

Das Log vom Router kann ich selbst nicht interpretieren, da rasen auch die Einträge nur so durch … ich habe jetzt mal den Placetel Login Link verwendet: https://accounts.placetel.de/users/sign_in

Auch da kommt das gleiche Resultat zurück.

Hat das denn überhaupt schon mal jemand getestet mit Zugriffen auf Seiten ohne OpenID? Und ist es egal, was im “Allgemein”-Reiter ausgewählt wird? Ein paar Einstellungen, so wie Kennung, Geheimnis und Erlaubte Verfahren sind ja offenbar zwingend obwohl man sie gar nicht benötigt?

Guido

StefanU 2020-06-07 20:32:12 UTC #14

Stefan

Guido 2020-06-08 06:20:13 UTC #15

Leider nicht.

Guido

StefanU 2020-06-08 09:41:37 UTC #16

Ich habe mal fix angefangen zu dokumentieren:

Darin zu dem Thema X-Frame-Options auch wie man das prüft.

Stefan

Guido 2020-06-08 10:48:43 UTC #17

Hi Stefan,
danke für die Erklärungen. sowohl die Login-Seite des Routers als auch die Login-Seite von Placetel geben folgendes zurück:

x-frame-options: SAMEORIGIN

Doof, oder?

Gruß,
Guido

StefanU 2020-06-08 11:09:15 UTC #18

Denke ja. Aber an der endgültigen Interpretation feile ich noch. Das ist ein wenig verwirrend.

Noch einmal zurück zu deiner Steckdosenleiste:
Kann die kein https? Sollte/müsste heutzutage schon.
Du hattest mir ja den Link zu dem Produkt gesendet. Da ist aber selbst das öffentlich zugängliche Demo unverschlüsselt…

grafik

Toll! Passwortschutz ohne Transportverschlüsselung…
Gut, man kann (und sollte) eine IP Acess Control List in dem Gerät pflegen.

Gerade mal geschaut: Meine APC können/machen https.

Mal abgesehen davon:
Für deine Aufgabenstellung: Zugriff auf Systeme (von fremden Systemen wo du deine Bookmarks nicht parat hast) gäbe es ja noch EGw Lesezeichen.
Hast du dir das schon einmal in dem Kontext angeschaut?

Stefan

StefanU 2020-06-08 11:15:23 UTC #19

Ergänzungen:

http://wiki.gude.info/FAQ_EPC_HTTP_Authentifizierung

In dem Config-Prog scheint man auf https umstellen zu können. Ob auch bei den Modellen?..:

http://wiki.gude.info/FAQ_EPC_Passwort_vergessen

Stefan

RalfBecker 2020-06-08 12:10:07 UTC #20

Das ist ein Sicherheitsfeature.

Wenn Du eine Seite Framen darfst, kannst Du auch einen transparenten Layer darüber legen und Dir so einen Bestätigung per Click vom Benutzer erschleichen und damit diverse Schutzmechanismen des Browsers aushebeln.

EGroupware setzt den Header genau aus dem Grund auch und wir haben auch nichts vorgesehen, den Header auszuschalten. Manche Programme bei denen Einbetten wohl üblicher ist, habe eine Konfiguration ob sie einbetten per IFrame erlauben sollen bzw. von welchen Seiten.

Generell kannst Du da natürlich mit einem Proxy wieder was machen, sprich den Header entfernen oder den Origin der EGroupware dazu nehmen. So bekommst Du der Steckdosenleiste auch https verpasst. Das ist jetzt für jede einzelne Seite ein Rumgefummel in der Nginx Konfiguration, oder wir machen für (performance-unkritische) Anwendungen ein Proxy Skript in der OpenID App, das dann nur einen Haken “URL Proxyen” zur Konfiguration braucht …

Ralf