PHP Login: Best Practice?

[andwaw]

Hallo zusammen,

ich habe in den letzten Wochen eine Applikation entwickelt die auf einer AS400 inklusive Zend Server läuft. Jetzt ist mir aber folgendes Problem aufgefallen. Wenn die Benutzer sich mit einem AS400-User anmelden und irgendwann das Passwort abläuft bekommen diese ein Problem. Sie arbeiten auch nie mit der AS400, sondern nur mit diesem Programm. Von Unternehmensseite war gefordert zum anmelden AS400-User zu nehmen. Ist das überhabt die sinnvollste Lösung? Sind davon losgelöste Zugangsdaten in einer separaten Tabelle mit einem Benutzer, der die Datenbankoperationen durchführen darf nicht besser? Was wäre hier die eleganteste Lösung?

- Kann ich beim Verbindungsversuch (db2_connect) schon irgendwie erkennen ob das Passwort abgelaufen ist?
- Wie ändere ich dann das Passwort? CHGPWD hat ja keine Parameter.


Gruß Andreas

[Fuerchau]

Da hilft nur ein regelmäßiger DSPUSRPRF in eine Outfile.
Da steht dann drin, wann das Kennwort abläuft (Anzahl Tage).
Dem User teilst du das mit und erstellst einen Dialog für die Änderung des Kennwortes (verschlüsselt).
Per SQL-CALL rufst du dann eine Prozedur oder per ProgrammCall ein Programm auf, dass unter *OWNER QSECOFR (oder anderen *SECOFR) läuft, dass dann einen CHGUSRPRF durchführt.

Vergisst der User das Ändern oder das Kennwort ist bereits abgelaufen kann man dies dann auch über eine interne andere Anmeldung an einem *SECOFR-Profil machen.

[Anton Gombkötö]

wie kommen die Daten dann auf das System?
Oder anders gefragt: wem gehören die Daten auf dem System? Wenn das ohnehin immer der gleiche Benutzer ist und *PUBLIC Zugriff *ALL hat, dann bringt das AS/400-Benutzerprofil gar nichts.
Ein echtes Benutzerprofil zu besitzen, ist schon was! Damit kann man sich nicht nur eventuell in einer 5250-Session anmelden, man kann unter Umständen auch auf Freigaben zugreifen usw. usw., was die Unternehmensleitung, so sie es denn wüsste, in Wirklichkeit wahrscheinlich noch viel weniger will.

Also wenn man die System-Berechtigungsprüfung ohnehin nicht braucht, ist man wesentlich sicherer unterwegs, wenn der Benutzer kein richtiges AS/400-Benutzerprofil hat. Da würde ich dann die Benutzer-Prüfung in der Applikation abfackeln.
Dann kann der Benutzer nur in der Applikation arbeiten, die AS/400 kennt ihn nicht.

Wenn die Rechte aber auf den Objekten definiert und für alle anders sind, dann ist wieder zu raten, den echten Benutzer zu verwenden.

Auf dem System i gibt es meiner Meinung nach keine generelle best practice - hier werden Massanzüge geschneidert und die anderen Teile der Garderobe müssen darauf natürlich auch Rücksicht nehmen. D.h. die häufigste Antwort auf viele derartige Fragen ist: Es kommt drauf an. :-)

[andreaspr@aon.at]

... und es gibt auch die Möglichkeit einer Validation-List (CRTVLDL) die in der Apache Konfig für eine authentifizierung verwendet werden kann.
Da könnt ihr auch User (und Passwörter hinterlegen) ADDVLDLE.
Hängt natürlich von euren Security Richtlinien ab.

lg Andreas

[andwaw]

@ Anton Gombkötö
Ja die Benutzer haben für eine Bibliothek reine Leseberechtigung und für zwei Tabellen eine Schreibberechtigung.

@Fuerchau

Soweit eine sehr gute Idee, meine Frage ist hier jetzt allerdings. Wenn das Passwort abgelaufen ist, muss ich ja trotzdem ermitteln ob das Ursprungspasswort richtig ist. Mein Plan einen SBMJOB CHKPWD mit dem entsprechenden Benutzer funktioniert nicht, weil das PHP Toolkit irgendwie keinen Fehler ausgeben möchte(zur Erklärung: Wenn das Passwort stimmt passiert nichts und bei einem Fehler kommt eine Meldung ins Joblog). Fällt sonst jemandem was ein?

[Fuerchau]

Hierfür kannst du ggf. API's verwenden.
Wiederum ein kleines CLP, dass du intern über eine andere Anmeldung als *SECOFR laufen lassen kannst.
Dieses CLP verwendet die API's:
IBM i API example: Using profile handles

Damit kannst du die Gültigkeit des aktuellen Kennwortes prüfen.
Wenn du ein Handle erhältst stimmt das Kennwort.
Vergesse den QSYRLSPH aber nicht.

Hier gibts noch ein API (Change User Password (QSYCHGPW) API):
http://pic.dhe.ibm.com/infocenter/is...61%70%69%22%20

Vielleicht reicht das ja, da hier das alte kennwort mit übergeben werden muss.

[MR-BN]

Es ist doch bestimmt nicht im Sinne des Erfinders, wenn alle Benutzer des PHP-Progamms auch als USER auf der i5 hinterlegt werden.
wir sind da einen anderen Weg gegangen. Die Anmeldung wird über eine Tabelle überprüft und die Zugriff auf die i5 über einen im PHP-Programm hinterlegten Benutzer ausgeführt.

[Fuerchau]

Wenn es denn nun der Wunsch des Kunden ist .

[andwaw]

Nur zum Verständnis. Mit dem Programm arbeiten später etwa 5 Leute und das auch nur innerhalb eines Intranets und diese iSeries ist wirklich sehr stark reguliert. Ich als Entwickler muss mir alle paar Minuten irgendwelche Objekte oder IFS Ordner freigeben lassen, weil ich da nichts darf

[Fuerchau]

Nunja, dann schreibe das CLP mit den benötigten Funktionen, lass dir das dann abzeichnen und den Eigner des Programmes dann auf QSECOFR und die Laufzeit auf *OWNER setzen.

Testen kannst du das ja mit einem gültigen Profil.

Wenn es sich nur um die Kennwortänderung handelt, kannst du das ja auch mit deinem Programmierprofil bzw. internem App-Profil aufrufen.

Bei deaktiviertem Profil benötigst du ja das CHGUSRPRF und somit *SECADM.
Aber für solche Fälle gibts ja für den Endanwender auch Methoden für die Reaktivierung (Mail usw.).