Auto Login Proxy

[rkr]

Moin, da hier wohl auch einige im Corporate-Umfeld unterwegs sind, wollte ich mal fragen, ob jemand einen Autologin-Proxy im Einsatz hat, bzw. einen empfehlen kann. Hintergrund ist, dass in letzter Zeit immer Probleme mit Zugangsdaten von verschiedenen Portalen auftreten und durch die so entwendeten Daten das Problem "SocialEngineering" steigt. Einem befreundeten Unternehmer wurden jetzt bei verschiedenen Verkaufsportalen sensible Daten geändert (Mitarbeiter hat auf eine Mail eines eigentlich privilegierten Kollegen mit sensiblen Daten geantwortet). Leider ist es auch bei uns so, dass zu viele Mitarbeiter Zugangsdaten zu vielen verschiedenen Portalen haben und die Accounts jeweils alle Rechte bei diesen Portalen haben.

Meiner Vorstellung nach sollte ein dazwischen geschalteter sso-proxy den Loginvorgang durch einen eignen Crawler (also durch ein pro-portal-script) übernehmen (dabei muss auch ssl geöffnet werden), so dass der Nutzer keine eigenen Logindaten benötigt. Ausserdem sollte man über eine White- oder Blacklist steuern können, dass niemand eine Url öffnen kann, mit der man Schaden anrichten könnte.

Kennt jemand so eine Lösung?

[erc]

Über HTTPS-Interception filtern Unternehmen über eine Firewall gefährlichen Traffik in beide Richtungen. Theoretisch kann man dieses Prinzip auch für SSO verwenden.

Soweit ich das überblicke, gibt es so eine Lösung nicht. Und SSL macht es auch nicht wirklich zu einer leichten Aufgabe.

Squid bringt dafür theoredisch alles mit und lässt sich auch als Reverse-Proxy konfigurieren (transparente umleitung per Firewall oder DNS). Der Aufwand dahinter ist aber nicht zu unterschätzen. Ich hab schon mal was in die Richtung umgesetzt, da gings aber nicht um den Login sondern um auslesen/modfizieren von Daten. Ich hab nach einem Tag Squid mich dann doch für eine Lösung mit Greasemonkey entscheiden. Die Einarbeitung Squid frisst richtig Zeit, ich hab zwar nach dem Tag Land gesehen, aber ich wusste danach kommt noch viel mehr Wasser (Icap Server, Fail Safe). Mit Greasemonkey war ich nach einem Tag durch und der Vorteil ist es ist extern verwendbar und hebelt SSL nicht aus.

[rkr]

Auf jeden Fall vielen Dank, dass du dich in das Thema eingebracht hast.

jede url welche änderungen ermöglicht, ermöglich auch schaden.

Genau aus diesem Grund eine White- / Blacklist.

Was mir vorschwebt ist im Grunde ganz einfach - aber wie es scheint nicht so einfach, wie ich denke. Sonst gäbe es sowas wohl schon. Knackpunkt ist in jedem Fall SSL.

Im Grunde sähe die für mich optimale Lösung so aus: User will sich in einem Portal anmelden. Dieses Portal unterstützt keine externen SSO-Verfahren wie SAML etc (so eine Unterstützung ist wahrscheinlich auch nur Selten der Fall). Der Http(s)-Request geht dann nicht direkt an das Portal, sondern erst an einen Proxy, der seinerseits mit dem Portal kommuniziert. An sich ist der komplette Verkehr transparent. Der Proxy merkt aber, dass der User noch nicht authentifiziert ist und unternimmt die dafür notwendigen Calls im Hintergrund, ohne dass der User etwas davon sieht. Resultat ist, dass der User sich danach auf dem Portal in einem gesteckten Rahmen bewegen kann. Eine zugrunde liegende White- oder Blacklist verhindert, dass der User (bzw. der Browser des Users) durch vom Portalbetreiber nicht geschützte Bereiche durch SocialEngineering oder durch csrf aufrufen kann.

Es gibt verschiedene SSO-Lösungen am Markt. SSO ist an sich ein Begriff, unter dem man viele Technologien zusammenfassen kann. Wie es scheint allerdings keine, die sowas vermag.

Ein geskripteter Login kann beispielsweise von OneLogin gemacht werden. Allerdings Client-seitig, über ein Browserplugin. Ein etwas geübter User kann die Logindaten abfischen.

Über HTTPS-Interception filtern Unternehmen über eine Firewall gefährlichen Traffik in beide Richtungen. Theoretisch kann man dieses Prinzip auch für SSO verwenden.

Soweit ich das überblicke, gibt es so eine Lösung nicht. Und SSL macht es auch nicht wirklich zu einer leichten Aufgabe.

Ausserdem sollte man über eine White- oder Blacklist steuern können, dass niemand eine Url öffnen kann, mit der man Schaden anrichten könnte.

jede url welche änderungen ermöglicht, ermöglich auch schaden.
genau weiss ich nicht, was du willst, sorry

-> cas oder doch shibboleth?
artikel der uni münster:

http://www.uni-muenster.de/ZIV/Techn...e_Sign_On.html