JSF: Authentifizierung für einen einzigen Fall "umgehen

[jelly]

Hallo,

ich habe eine Anwendung bei der bestimmte Prozesse manuell über ein Webinterface (in JSF) ausgeführt werden. Die gesamte Anwednung kann nur über ein Login erreicht/bedient werden. Das Problem ist nun das auch ein externes Skript eine bestimmte Seite aufrufen soll und durch übergabe bestimmter Parameter per URL soll ein bestimmter Prozeß (der sonst ebend manuell ausgeführt werden kann) automatisch angestoßen werden. Mit Prozeß meine ich eine Action meiner Bean. Also ich habe es geschafft dass, wenn besagte URL aufgerufen wird und gewisse Parameter übergeben werden, meine Action automatisch ausgeführt wird. Aber wie mache ich das wenn die gesamte Anwendung eine Authentifizierung erfordert? Das Skript kann sich ja schlecht einloggen...

Momentan dachte ich bei der Authentifizierung an einen Filter, der Prüft ob ein User-Objekt in der Session liegt. (Dieses Userobjekt wird bei erfolgreichem Login in die Session gelegt.) Wenn man versucht eine geschützte URL aufzurufen und das Session-Objekt nicht vorhanden ist dann wird man auf die Login-Seite zurückgeführt. Wenn das Skript jetzt versuchen würde die URL aufzurufen dann dann würde nichts passieren da ja theoretisch festgestellt wird das keine Berechtigung da ist.

Ich hoffe ihr versteht einigermaßen was ich meine... :bahnhof:

manuell würde die Seite .../myApp/seite.jsf aufgerufen werden und automatisch .../myApp/seite.jsf?admin=auto&prozess=automatisch&kategorie=1

Gibt es eine Möglichleit den URL-Aufruf mit Parametern aus dem Filter rauszunehmen? Oder kann man irgendwie beim URL-Aufruf künstlich ne Session mit Dummyobjekt mitgeben? Oder muß man die Authentifizierung komplett anders machen? Ich weiß nicht so recht wie ich das anstellen soll das alles geschützt ist nur eben dieser automatische Seitenaufruf mit Parametern nicht...

Gruß
jelly

 

[KSG9|sebastian]

Mach nen POST-Request mittels Apache HTTPClient oder ähnliches und Pack User/Passwort in den Request. Und im Skript eben überprüfen ob Logindaten im Request sind...

 

[puddah]

wenn ich das richtig verstanden habe, hinterlegst du username und passwort in einem Session Objekt. Das würde ich über JAAS machen.

 

[jelly]

Hallo,

also so richtig weiß ich nicht ob ich das verstanden habe Sebastian. An dem Skript kann ich nichts verändern. Das besteht ebend nur aus dem Seitenaufruf...das Skript selber agiert wie ein Benutzer und hat vollen Zugriff hat. Denn desweiteren muß ich für die menschlichen Benutzer veschiedene Rollen verteilen. Es gibt ebend ne Vollansicht und eine eingeschränkte für die Anwendung...

jelly

 

[SlaterB]

> das Skript selber agiert wie ein Benutzer und hat vollen Zugriff hat

ja wie denn nu, bisher klang es ja eher danach als hättest du Problem, dich mit dem Skript einzuloggen
(daher die entsprechenden Antworten)

worum gehts denn überhaupt?

wer soll sie wo wie einloggen?,
wer soll den beschränkten Zugriff haben?,
was hat das denn auf einmal mit der Session zu tun?
was kann alles verändert werden und was nicht?,
wie ist es bisher, wie soll es werden?

benutzt das Skript überhaupt Cookies oder was anderes, um eine Session zu ermöglichen,

 

[jelly]

Hallo,

vielleicht habe ich mich etwas mißverständlich ausgedrückt...
ich weiß nichts von dem skript nur das es periodisch eine URL mit bestimmtem Parametern aufruft wodurch eine bestimmte action ausgeführt werden soll. das skript wird auch nicht geändert werden und ich bekomme auch keine einsicht/zugriff

soweit so gut. das problem ist das die webanwendung bisher offen wie ein scheunentor war. es soll also ein login drübergelegt werden. wer sich einloggt ist entweder ein light-admin (darf auf die hälfte der seiten der webanwendungen zugreifen) oder ein voll-admin (darf auf die gesamte anwendung zugreifen.)

die url die von dem skript aufgerufen wird soll nur voll-admin-zugriff unterliegen. wenn das skript die url mit parametern aufruft, dann wird über einen phasenlistener eine action ausgeführt. wenn die url über die navigation von einem voll-admin aufgerufen wird dann (wohlgemerkt ohne parameter) dann gibt der voll-admin auf dem formular der seite die benötigten parameter ein und es wird beim abschicken des formulars die selbe action aufgerufen, wie im phasenlistener (wenn die url mit parametern aufgerufen wird).

das problem ist, dass wenn da nun ein sicherheitsmechanismus (momentan ein filter) drüber kommt, wird ein direktaufruf der url unterbunden da diese nur für eingeloggte voll-admins zugänglich ist.

momentan wird durch den sicherheitsfilter ein redirect auf die loginseite gemacht wenn man versucht eine geschützte url aufzurufen...sprich wenn das skript läuft wird die action nie aufgerufen weil der sicherheitsfilter greift.

ich weiß leider so gut wie nichts über dieses skript und weiß auch nicht wie ich das problem sonst schildern soll.
das mit der session hab ich nur erwähnt weil in dem sicherheitsfilter geschaut wird ob ein user-objekt in der session liegt welches den benutzer als light-admin oder voll-admin identifiziert und anhand dessen den seitenaufruf erlaubt oder eine redirct zur login-seite macht.

tut mir leid wenn es unverständlich ist, aber mit sicherheit hatte ich bisher noch nicht viel zu tun ganz zu schweigen von einem skript das sich bisher immer "durchgemogelt" hat.

jelly

 

[SlaterB]

nun ja, umständlich erklärt, aber wohl doch langsam klar,

bisher war die Aktion ungeschützt und das Skript kam mit seinem Aufruf durch,
nun wird die Seite geschützt und nur eingeloggte User kommen weiter,

bei normalen Usern über Browser funktioniert dies, da diese sich zuvor eingeloggt haben und diese Information gemerkt wird,
das Skript steht aber vor verschlossenen Türen

------------------

zwei-drei Möglichkeiten:
1.
das Skript verhält sich wie ein normaler Browser (benutzt z.B. Cookies) und führt nun ebenso wie normale User vorher einen Login durch,

wird schwierig wenn du das Skript nicht ändern kannst, das wäre ein tiefgreifende Änderung,
wird umso schwieriger wenn du von Cookies, Session und Sicherheitsmechanismen allgemein wenig Ahnung hast

2.
das Skript arbeitet von der Struktur her wie bisher,
sendet aber einen zusätzlichen Paramerter 'ichBinSkriptLassMichDurch=true' mit, der vom Filter berücksichtigt wird,
gefährlich, wenn mal jemand anders auch auf die Idee kommt und dies auch tut,

andererseits auch nicht gefährlicher, als wenn jemand ein Passwort aufschnappt,
also solange man das so geheimhält, wie man Passwörter geheimhält, solange könnte das wohl gehen

wäre immer noch eine kleine Änderung des Skriptes

2.b.
das Skript bleibt völlig wie es ist,
und der Filter versucht anhand anderer Kriterien, das Skript von normalen Request zu unterscheiden,

z.B. die benutzte IP-Adresse/ Port anschauen, den benutzten Rechner, Browser usw.,
alles mögliche, was im Request an Informationen vorhanden ist,

auch wieder mit der Gefahr, dass jemand anders diese Informationen kopiert/ vortäuscht oder zufällig auch hat,