Beispiel: IBM WebSphere-spezifische User-Registry

Inhalt:

• Es gibt zwei Rollen in dieser Anwendung, "administrator" und "student" (ist in Teilen noch aus dem letzten Semester, wo wir eine Lehrveranstaltungsbelegung programmierten)
• Die Benutzer werden in zwei Datenbanktabellen "ADMINISTRATOR" und "STUDENT" abgelegt, die jeweils über die Spalten ID, NAME, LOGIN und PASSWORT verfügen.
• Auf die Tabelle "STUDENT" greift eine gleichnamige EJB zu, für die Validierung des Logins wird sie durch direkten SQL-Zugriff gelesen.
• Eine Session-Bean im EJB-Projekt enthält Methoden auf die nur Studenten bzw. Administratoren zugreifen dürfen.
• Zum Test dienen eine Webanwendung und ein Application-Client. Bei beiden muss der User sich anmelden, die Anmeldeinformationen werden bis zum EJB-Projekt weitergeben.

Anlegen der Application

Anlegen des EJB-Projekts

Es wird eine EntityBean "Student" im Package de.fhw.swtvertiefung.knauf.security mit den Feldern ID (java.lang.Integer), NAME, LOGIN und PASSWORT (jeweils java.lang.String) erzeugt.
Anschließend ein Datenbankmapping für die Bean erzeugen lassen (Rechtsklick auf Deployment Deskriptor):

Es wird ein Top-Down-Mapping für eine Datenbank namens "KnaufDB" erzeugt.

Eine simple Session-Bean "Secured" mit Remote Interface wird erzeugt.
Wir verpassen ihr drei Methoden forAdminOnly(), forStudentOnly() und forBoth(), die keine weitere Implementierung haben.

Implementierung der UserRegistry

Nachdem wir das Datenbankschema angelegt haben, können wir diesem Schema eine nicht-Bean-Tabelle "ADMINISTRATOR" zufügen. Dazu Rechtsklick auf das Projekt und "New" -> "Other..." -> "Data" -> "Table Definition" wählen.

Wir geben als Tabellenname "Administrator" an, bei "Database/schema" klicken wir auf "Browse..." und klicken uns zur Schema-Definition durch.

Wir fügen die Spalten zu. ID ist vom Typ INTEGER, die anderen drei sind VARCHAR der Länge 255. Name und Passwort lassen NULL-Werte zu, nur LOGIN nicht.

Im nächsten Schritt wählen wir ID als Primary-Key-Spalte aus.

Foreign Keys haben wir nicht.

Damit haben wir die Datenbanktabelle erzeugt.

Jetzt die Implementation der UserRegistry, de.fhw.swtvertiefung.knauf.security.userregistry.KnaufUserRegistry, sowie die beiden Hilfsklassen de.fhw.swtvertiefung.knauf.security.userregistry.Administrator und de.fhw.swtvertiefung.knauf.security.userregistry.Student zufügen.

Aktivieren der Sicherheit

WASX7209I: Mit Prozess "server1" auf Knoten NodeKnauf2 über SOAP-Connector verbunden. 
Typ des Prozesses: UnManagedProcess
Uninstall filetransfer -cell CellKnauf2 -node NodeKnauf2 -server server1
Operation FAILED!
   com.ibm.ws.scripting.ScriptingException: WASX7280E: Es ist keine Anwendung mit dem Namen "filetransfer" vorhanden. 

Universal Test Client aktivieren

#------------------------------------------------------------------------------
# SOAP Client Security Enablement
#
# - security enabled status  ( false[default], true  )
#------------------------------------------------------------------------------
com.ibm.SOAP.securityEnabled=false

com.ibm.SOAP.loginUserid=
com.ibm.SOAP.loginPassword= 

com.ibm.SOAP.securityEnabled=true
com.ibm.SOAP.loginUserid=TEST
com.ibm.SOAP.loginPassword=TEST

Sicherheit im EJB-Projekt

Im EJB-Projekt wollen wir einige Methoden der Session-Bean "Secured" absichern, so dass nur Benutzer in spezifierten Rollen die Methoden aufrufen dürfen.
Dazu in den Deployment-Deskriptor von SecurityEJB wechseln und auf der Karteikarte "Assembly" zuerst die "Security Roles" zufügen.
Die erste Rolle soll "administratorejb" heißen (den Namen können wir völlig frei wählen, das Mapping auf echte Server-Gruppen/-Benutzer geschieht erst später.

Eine zweite Rolle "studentejb" zufügen.

Unter "Method Permissions" werden jetzt die Zugriffsrechte für diese Rollen vergeben. Wir fügen eine neue Methode Permission zu und wählen im ersten Schritt die Rolle "administratorejb" aus.

Wir wählen die zu sichernde Bean aus, also "Secured".

Jetzt die Methoden forAdminOnly und forBoth auswählen, für die diese Zugriffsberechtigung gilt.

Das gleiche wiederholen für die Rolle "studentejb", die Zugriff auf forStudentOnly und forBoth bekommt.
Das Ergebnis sollte so aussehen:

Leider können wir das nicht im UTC testen da die Bean über keine Local Interfaces verfügt.

Sicherheit im Web-Projekt

Vorbereitung: Das Web-Projekt muss das EJB-Projekt referenzieren, eine EJB-Referenz auf die Bean "Secured" muss angelegt werden.
Bevor wir hier die Sicherheit definieren legen wir zuerst drei JSP-Seiten an. "index.jsp" soll unsere zugriffs-gesicherte Seite sein, "login.jsp" ist unser Login-Formular, und "errorpage.jsp" die Fehlerseite bei Login-Fehlern.
"login.jsp" wird immer dann aufgerufen wenn ein noch nicht am Server authentifizierter User auf eine gesicherte Seite zugreifen will.
Sie verwendet Form-Based Login, d.h. ein HTML-Formular wird zum User geschickt. Damit WebSphere die Informationen aus diesem Anmeldeformular auswerten kann müssen Ziel-URL, Submit-Button sowie die Feldnamen für Login und Passwort wie folgt aussehen:

<form method="post" ACTION="j_security_check">
   Login: <input type="text" name="j_username" /> <br>
   Passwort: <input type="password" name="j_password" /> <br>
   <input type="submit" name="login" value="Login">
</form> 

"index.jsp" ruft zum Test die drei gesicherten Methoden der Secured-Bean auf. Außerdem gibt es dort einen Logout-Button. Der muss in einem Formular stecken das so aussieht:

<FORM METHOD=POST ACTION="ibm_security_logout" NAME="logout">
   Für sauberen Logout hier klicken: <br>
   <input type="submit" name="logout" value="Logout">
   <INPUT TYPE="HIDDEN" name="logoutExitPage" VALUE="login.jsp">
</FORM> 

"logoutExitPage" gibt an auf welche Seite der User nach erfolgreichem Logout geleitet werden soll.

"errorpage.jsp" ist eine ganz normale Fehlerseite, ohne Besonderheiten.

Jetzt können wir uns der Security widmen. Im Web-Deployment-Deskriptor auf der Karteikarte "Security" zwei Security Roles "administratorweb" und "studentweb" zufügen.


Unter "Security Constraints" werden Regeln definiert, welche Ressourcen von der Sicherheit betroffen sind. Dazu eine neue zufügen und ihr einen aussagekräftigen Namen geben.

Im nächsten Schritt einen Resourcen-Namen (frei wählbar), die zu sichernden HTTP-Methoden und ein URL-Pattern ("/*") eingeben.


Jetzt müssen wir festlegen für welche Rollen diese Security Constraint gilt. Dazu auf der gleichen Karteikarte die "Authorized Roles" festlegen (eine neue "Authorization Constraint" zugefügt).


Das Ergebnis sollte so aussehen:


Im letzten Schritt aktivieren wir den Form Based Login. Auf der Karteikarte "Pages" unter "Login" wählen wir als "Authentication Method" "FORM", und geben die Login- und Fehler-Seiten unserer Anwendung an entsprechender Stelle an.

Sicherheit im Application Client-Projekt

Vorbereitung: Das Application Client-Projekt muss das EJB-Projekt referenzieren, eine EJB-Referenz auf die Bean "Secured" muss angelegt werden. Die Main Class muss auf de.fhw.swtvertiefung.knauf.security.SecurityClient geändert werden.
In Sachen Security gibt es hier nichts zu konfigurieren, da der Application Client ja prinzipiell nicht im Server-Context läuft. Sobald wir die Anwendung allerdings starten und auf eine gesicherte Methode der Bean zugreifen blendet die Web-Sphere-Client-Schicht automatisch einen Login-Dialog ein !

Sicherheit in der Enterprise Application

Im Deployment Deskriptor der Enterprise Application schließlich legen wir fest welche der Rollen in den Teilprojekten auf welche Nutzer oder Gruppen im Server gemappt werden.
Auf der Karteikarte "Security" auf "Gather..." klicken, dies sucht die in allen Deployment-Deskriptoren definierten Rollen zusammen (es sollten hier jetzt vier Stück auftauchen). Jede der Rollen muss ausgewählt werden. Unter "WebSphere Bindings" wird die Checkbox "Users/Groups" gesetzt und eine Gruppe zugefügt. Für "administratorweb" und "administratorejb" heißt die Gruppe "administrator" (unter diesem Namen wird sie von der UserRegistry zurückgegeben.

Für "studentweb" und "studentejb" heißt die Gruppe "student".
Das Ergebnis sieht so aus:



Jetzt endlich dürfen wir auf den Server deployen und können bei Application Client bzw. WebClient feststellen wie sich Logins als Student bzw. Adminstrator auf die Methodenaufrufe der SecuredBean auswirken.
Ich habe die Erfahrung gemacht dass es nach dem Publish mit geänderten Security-Einstellungen in der Enterprise Application am besten ist den Server neu zu starten !
Der Webclient ist zu erreichen unter

Troubleshooting und Security-Tipps

• Server bleibt im Status "Starting..." hängen:
  Einen Blick in PROFILE\logs\server1\SystemErr.log und PROFILE\logs\server1\SystemOut.log werfen. Normalerweise ist aus der Fehlermeldung erkennbar wo es klemmt.
• Die Admin-Console kann unter dieser URL aufgerufen werden (falls der Aufruf aus dem RAD mal nicht klappt): https://localhost:9043/ibm/console/
• Die Authentifizierung über die UserRegistry verläuft so:
  Serverstart:
  1) initialize wird aufgerufen.
  2) getRealm wird aufgerufen
  3) Der User für den Serverstart wird validiert: checkPassword (login, password) für den Login "TEST"
  4) Die User-ID dieses Users wird geholt: getUniqueUserId (username)
  5) Die Group-IDs zur User-ID werden geholt: getUniqueGroupIds(userid)
  
  Jetzt wird der Deployment-Deskriptor ausgewertet:
  1) Pro Benutzergruppe im Deskriptor der EAR-Anwendung wird die GroupID geholt: getUniqueGroupId(groupid)
  2) Zur Gruppen-ID wird der Gruppen-Name geholt.
  
  Wenn sich ein User an unserer Anwendung anmeldet:
  1) Login wird validiert: checkPassword (login, password)
  2) Die User-ID wird geholt: getUniqueUserId (username)
  3) Die Group-IDs zur User-ID werden geholt: getUniqueGroupIds(userid)
  4) Den Gruppen-Namen zur ID hat der Server schon bei der Initialisierung der EAR-Anwendung geholt, d.h. hier kein weiterer Zugriff auf die UserRegistry, sondern ein Abgleich mit den Daten im Speicher.
  
• User aus UserRegistry können auf Serverollen gemappt werden: AdminConsole -> Systemverwaltung -> Konsoleneinstellungen -> Konsolbenutzer -> hier könnnen wir Benutzer aus der UserRegistry auf Serverrollen mappen. Dadurch ist es möglich, weitere User aus der Tabelle "administrator" dazu zu verwenden um die Admin-Console aufzurufen oder den Server zu starten oder zu stoppen. Falls wir beim Benutzernamen einen User angeben der nicht von unserer UserRegistry validiert werden kann spuckt uns WebSphere eine entsprechende Fehlermeldung aus.
  
• Falls wir die Java2-Sicherheit in der Globalen Sicherheit aktiviert haben müssen Java-Permissions für das Verzeichnis im Profil angegeben werden, in dem wir die Klasse der User-Registry abgelegt haben (im Beispiel also PROFILE\classes). Dazu in der Datei PROFILE\properties\server.policy folgendes einfügen:

  //Profil-Klassen:
  grant codeBase "file:${user.install.root}/classes/-" {
    permission java.security.AllPermission;
  };