Login für User, der im Hintergrund Schedules ausführt

[beta20]

Hallo zusammen,

ich verwende Apache Shiro für die Security.
Das funktioniert soweit ganz gut, wenn sich ein User per Web anmeldet. Der User gibt seine Loginname und Passwort ein -> ist eingeloggt.

Nun habe ich aber auch ein User, der im Hintergrund Schedules ausführen soll, der sich allerdings nicht via Web GUI authentifiziert.
Auch dieser soll sich aber einloggen bzw. authentifizieren. Die Idee ist hier statisch oder aus der Datenbank einen User zu definieren, der als dieser User dienen soll.

In der Datenbank speichere ich die Passwörter natürlich verschlüsselt ab (SHA512).

Der Login mittels Shiro funktioniert u.a. so:

UsernamePasswordToken token = new UsernamePasswordToken( username, password );
Subject currentUser = SecurityUtils.getSubject();
currentUser.login(token);

-> Der Parameter "password" ist bei new UsernamePasswordToken( username, password ) nicht verschlüsselt. Das ist der String, den der User in der GUI zum Einloggen eingibt.

Mein Problem ist nun:
1) Ich hole mir einen User aus der Datenbank
2) Habe das Passwort aber nur verschlüsselt. Aber ich benötige es entschlüsselt, um das auszuführen: new UsernamePasswordToken( username, password ).

Wie könnte ich das am Besten lösen? SHA512 kann ich ja nicht entschlüsseln.
Ich könnte mir vorstellen, dass ich neben den verschlüsselten Passwort noch einen Token in der Datenbank speichere?
Die Frage wäre dann aber wie ich diesen verschlüssele bzw. entschlüssle.

Danke für die Hilfe.

 

[Dukel]

Wenn ein Programm Schedules laufen lassen soll dann geht das als Dienst oder im OS Scheduler. Diesen kann man jeweils als dieser Nutzer laufen lassen, der alles machen darf, was er muss.

 

[beta20]

Ich meine keine Windows Scheduler o.ä.
Ich meine einen EJB Scheduler...
Ich habe eine Tabelle, in der ich meine Jobs vorhalte, die zu einem bestimmten Datum starten sollen...
Der User startet jede Minute den Scheduler an und prüft, ob in der Datenbank auszuführene Jobs sind. Falls ja, plant er diese eben im EJB Scheduler ein.

sonst gebe ich dir Recht, dass das ein OS Schedule machen kann...

 

[kneitzel]

Aber wi brauchst du da eine Authentifizierung? Das läuft dann doch in deinem Server, d.h. du hast da vollen Zugriff auf alles. Oder was übersehe ich hier jetzt?

Du hast ja in der Regel die Autorisierung im Frontend Bereich. Im Backend hast du die ja nicht mehr wirklich und macht ja auch keinen Sinn, denn du hast ja auf alles Zugriff ....

 

[mrBrown]

Bei dir läuft doch alles in nem EE-Container? Warum dann nicht einfach auf JEE Security API setzen, was uU @RunAs, was zumindest in die Richtung dessen gehen könnte, was du suchst.

In der Datenbank speichere ich die Passwörter natürlich verschlüsselt ab (SHA512).

BTW: Die Passwörter sind damit nicht verschlüsselt, sondern gehasht, und statt SHA-512 sollte man besser einen extra dafür entwickelten Algorithmus nutzen.

 

[beta20]

Aber wi brauchst du da eine Authentifizierung? Das läuft dann doch in deinem Server, d.h. du hast da vollen Zugriff auf alles. Oder was übersehe ich hier jetzt?

Du hast ja in der Regel die Autorisierung im Frontend Bereich. Im Backend hast du die ja nicht mehr wirklich und macht ja auch keinen Sinn, denn du hast ja auf alles Zugriff ....

Ich habe in verschiedenen Methode eine Prüfung, ob ein User die Berechtigung hat.

Bspw. ob ein User Angebote schreiben darf:
Hierzu benötige ich ein Objekt Subject (=currentUser).

if ( currentUser.isPermitted( "angebote:erstellen" ) ) {

Demnach benötige ich ja auch im Backend einen User, der sich aber eben über oben genannte Methode einloggen muss, damit das Subject - Objekt gefüllt wird.

Oder sehe ich etwas falsch?

 

[LimDul]

Ein technischer Job, der im Backend direkt vom Scheduler gestartet wird erzeugt ein User-Objekt, was alle Rechte hat. - oder arbeitet auf einer Ebene wo keine Rechteprüfung mehr läuft, weil die vorgelagerten Schichten stattfindet.

 

[beta20]

erzeugt ein User-Objekt, was alle Rechte hat.

Und wie erzeuge ich diesen User (Subject von Apache Shiro) ?

 

[LimDul]

Understanding Subjects in Apache Shiro | Apache Shiro

Deep dive into Apache Shiro's Subject API - the security-specific view of an application user representing authentication state, principals, and authorization capabilities.

shiro.apache.org

Da steht:

Some ‘special cases’ when this can be useful:
(...)
Daemon/background process work - when a daemon or background process executes, it might need to execute as a particular user.

Doku lesen hilft bei sowas ungemein 🙂

 

[kneitzel]

@LimDul hat das ja schon recht schön geklärt. Aber ich melde mich auch noch einmal zu Wort, da ich da versehentlich auch ein falsches Wording benutzt hatte.

Wichtige Unterscheidung:
Authentifizierung: Ein User meldet sich an. Dazu nutzt er irgend eine Methode, über die er bestätigen kann, dass er dieser user ist.
==> Diese Authentifizierung muss nicht statt finden, wenn Du das System kontrollierst. Du hast ja Zugriff auf das Backend direkt und kannst, so du es brauchst, dir einen entsprechenden User erzeugen. Eine Authentifizierung findet nicht statt, denn jetzt bist Du zwei in eins: Einmal derjenige der etwas behauptet und gleichzeitig derjenige, der es glaubt. Du wirst Dir selbst ja vertrauen. (Anders als daher gelaufenen Usern - den glaubst Du erst, wenn sie es bewiesen haben...)
==> Autorisierung: Was darf ein User / Gruppe / Mandant? Oft braucht man das nicht, weil Du schreibst ja den Code und der soll ablaufen. Da braucht man dann keine Autorisierung, denn du bist autorisiert, alles zu machen.
ABER: Das ist ein Sicherheitsproblem. Und das kann kritisch gesehen werden. Mir fällt da direkt ein Mandantenfähiges System ein und das soll immer getrennt sein. Du wirst auch im Backend sehr genau Mandanten prüfen. Ohne "user" keine Daten! Und ein Job muss unter einem Mandanten laufen.

Das einfach nur als wichtige Trennung. Und ich habe beim Schreiben nicht zu genau draufgeachtet und zu schnell geschrieben. Freudscher Verschreiber - da ich auch an Autorisierung mit gedacht habe, hat sich das da eingeschlichen. Daher das noch einmal ausführlicher.

Ansonsten gilt wie schon oben geschrieben: @LimDul hat das ja soweit geklärt meine ich, oder?

 

[beta20]

Understanding Subjects in Apache Shiro | Apache Shiro

Deep dive into Apache Shiro's Subject API - the security-specific view of an application user representing authentication state, principals, and authorization capabilities.

shiro.apache.org

Da steht:

Doku lesen hilft bei sowas ungemein 🙂

Danke euch!

Mhm, also ich habe das mal versucht:

Factory<SecurityManager> factory = new IniSecurityManagerFactory("classpath:shiro-web.ini");
SecurityManager securityManager = factory.getInstance();
SecurityUtils.setSecurityManager(securityManager);
           
Subject subject = new Subject.Builder().buildSubject();

Wenn ich mir im Debug Mode das nun anschaue, dann hat Subject - Object keine Berechtigungen... Also "authenticated" = false
Wenn ich also mit dem Subject Funktionen aufrufe, bei denen die Berechtigung geprüft wird, dann schlägt das fehl (da eben nicht berechtigt)

Vielleicht habe ich aber auch einfach ein Logikfehler bei mir...:
Ich habe die Prüfung der Berechtigungen innerhalb meiner Service Klasse implementiert.
Zudem habe ich in den Controller Klassen für das Webfrontend die Berechtigungsprüfung implementiert. Eigentlich ist das ja doppelt gemoppelt.

Ich hatte die Prüfung in der Service Klasse mehr oder weniger eher nur dadurch eingebaut, falls ich später mal Webservices habe, die diese Funktionen konsumieren. Aber die Prüfung der Berechtigung könnte ich dann ebenfalls in den Webservices machen.

Dann könnte ich die Berechtigung komplett aus den Service Klassen nehmen?

 

[mrBrown]

Wenn ich mir im Debug Mode das nun anschaue, dann hat Subject - Object keine Berechtigungen... Also "authenticated" = false
Wenn ich also mit dem Subject Funktionen aufrufe, bei denen die Berechtigung geprüft wird, dann schlägt das fehl (da eben nicht berechtigt)

Du erstellst doch ein "leeres" Subject, da würde ich eigentlich erwarten, dass es keinerlei Berechtigungen hat.

Ich habe die Prüfung der Berechtigungen innerhalb meiner Service Klasse implementiert.
Zudem habe ich in den Controller Klassen für das Webfrontend die Berechtigungsprüfung implementiert. Eigentlich ist das ja doppelt gemoppelt.

Ich hatte die Prüfung in der Service Klasse mehr oder weniger eher nur dadurch eingebaut, falls ich später mal Webservices habe, die diese Funktionen konsumieren. Aber die Prüfung der Berechtigung könnte ich dann ebenfalls in den Webservices machen.

Dann könnte ich die Berechtigung komplett aus den Service Klassen nehmen?

Mit Prüfung in den Services fährt man bei komplexen Dingen meist besser, man hat die Autorisierung nicht von den eigentlichen Aktionen getrennt, sondern beides zusammen, und hat mehr Möglichkeiten, wenn nicht alles direkt über die Web-Schnittstelle kommt.

Die Doppelung der Autorisierung macht aber schnell Probleme, daher würde ich eher die im Controller entfernen.

 

[mihe7]

Wichtige Unterscheidung:
Authentifizierung: Ein User meldet sich an. Dazu nutzt er irgend eine Methode, über die er bestätigen kann, dass er dieser user ist.

Das ist Authentisierung. Authentifizierung ist die Überprüfung durch das System 🙂

 

[beta20]

Du erstellst doch ein "leeres" Subject, da würde ich eigentlich erwarten, dass es keinerlei Berechtigungen hat.

Ja, so sieht es auch aus....
Die Frage ist nun aber wie ich mich dann doch "einlogge" bzw. dem Subject die entsprechenden Berechtigungen gebe. Finde dazu leider keine setPermission Methode o.ä..

Ich kann jetzt natürlich ein bestehender User verwenden und "hart" in den Code reinschreiben.Wenn sich das PW ändert, muss ich natürlich den Code anpassen, neu deployen etc. - ist natürlich alles andere als toll.

Subject subject = new Subject.Builder().buildSubject();
UsernamePasswordToken token = new UsernamePasswordToken("test@domain.de", "mypassword");
currentUserShiro.login(token);

Das Problem ist zudem, dass ich dann hier das Passwort in Klartext reinschreibe (also nicht gehasht) bzw. wenn ich einen User aus der Datenbank lade, habe ich nur das gehashte Passwort, womit new UsernamePasswordToken("test@domain.de", "mypassword"); nicht umgehen kann, weil es das PW in Klartext benötigt (also "mypassword", welches sonst eben im Webfrontend eingegeben wird).

Mit Prüfung in den Services fährt man bei komplexen Dingen meist besser, man hat die Autorisierung nicht von den eigentlichen Aktionen getrennt, sondern beides zusammen, und hat mehr Möglichkeiten, wenn nicht alles direkt über die Web-Schnittstelle kommt.

Die Doppelung der Autorisierung macht aber schnell Probleme, daher würde ich eher die im Controller entfernen.

ok, danke - werde ich dann so umsetzen...

 

[kneitzel]

Wenn Du einmal das Subject hast, dann setzt Du da keine rechte mehr.

Aber Du hast doch den Link bekommen wo es erläutert wurde incl. dem Beispiel:

Object userIdentity = //a long ID or String username, or whatever the "myRealm" requires
String realmName = "myRealm";
PrincipalCollection principals = new SimplePrincipalCollection(userIdentity, realmName);
Subject subject = new Subject.Builder().principals(principals).buildSubject();

Hier erstellst Du also ein Subject für einen User. Und wie du siehst: keinerlei Passwort wird benötigt. Alles, was Du brauchst, ist hier ein principal object mit dem User, den du verwenden möchtest.

Oder habe ich Deine Problematik falsch verstanden? Aber was auf jeden fall wichtig ist: So ein Builder wie Subject.Builder() bietet die Methoden, die Du brauchst um die Eigenschaft des Zielobjekts (hier vom Typ Subject) zu erstellen. Erst wenn Du alles gesetzt hast, dann rufst Du build auf (bzw. buildSubject hier).

 

[beta20]

Danke dir, habs selbst in der Doku gesehen, war aber zu spät hier zu antworten....
Sieht nun so aus, dass es funktioniert 🙂 Vielen Dank

 

[beta20]

Habe nochmal eine Frage dazu...:
Sollte ich nachdem der Scheduler gelaufen ist die Session des Users (Subject) wieder killen?

Ich hatte jetzt den Fall, dass ich nach längerer Inaktivität diese Meldung bekomme:

org.apache.shiro.session.UnknownSessionException: There is no session with id [d32af383-5f26-463f-a2f0-58a0e82c7890]