Benutzung eines Login Modules zur Authentifizierung unter JBoss 5.0

Transkript

1 Benutzung eines Login Modules zur Authentifizierung unter JBoss 5.0 Erstellung der Datenbank Tabellen Als Login Module soll das in der JBoss Installation bereits vorhandene DatabaseServerLoginModule verwendet werden. Dieses kann auf mehrere Datenbanktabellen zugreifen, die sowieso zur Persistenz von Entity Beans dienen. Das heißt, Entity Bean Einträge sollen zur Authentifizierung dienen. Auf Entity Beans kann in dieser Phase des Zugriffs auf den Application Server jedoch noch nicht direkt zugegriffen werden, da der Benutzer ja noch nicht authentifiziert ist. Daher muss ein direkter Zugriff auf die entsprechenden Datenbanktabellen geschehen. Grundsätzlich benötigt man dazu zwei Tabellen. Die Namen sind beliebig. Sie kennzeichnen die Benutzer und die mit ihnen verknüpften Rollen. Nennen wir sie hier Benutzer und Rolle. Hier soll ein Benutzer genau eine Rolle haben. Dann müssen Benutzer und Rolle (minimal) die folgenden Felder enthalten: Benutzer: Feldname Typ Bedeutung id bigint Primärschlüssel loginname varchar(20) Login-Name password varchar(20) Passwort role_id bigint Fremdschlüssel zu Rolle (aus der Beziehung generiert) Rolle: Feldname Typ Bedeutung rid bigint Primärschlüssel rname varchar(20) Rollen-Name Der Rollen-Name entspricht den Security-Rollen in den Security-Annotationen der Session Beans

2 Definition einer JBoss Security Domain Wir ändern dazu die Datei login-config.xml im Unterverzeichnis server/default/conf des JBoss-Installationsverzeichnisses. Hier fügen wir ein: <!-- Security domain for Reiseshop-System --> <application-policy name = "ReiseshopSecurity"> <authentication> <login-module code = "org.jboss.security.auth.spi.databaseserverloginmodule" flag = "required"> <module-option name = "unauthenticatedidentity"> gast </module-option> <module-option name = "dsjndiname"> java:/defaultds </module-option> <module-option name = "principalsquery"> SELECT PASSWORD FROM BENUTZER WHERE LOGINNAME=? </module-option> <module-option name = "rolesquery"> SELECT R.RNAME, 'Roles' FROM ROLLE AS R, BENUTZER AS B WHERE B.LOGINNAME=? AND R.RID = B.ROLE_ID </module-option> </login-module> </authentication> </application-policy> Die SQL Select-Befehle sind an die Gegebenheiten Ihrer Entity Beans und der daraus erzeugten Tabellen anzupassen. Der Name der application-policy ist natürlich frei wählbar. Der Datenbank JNDI-Name sollte wie gezeigt bleiben, damit die Tabellen in unserer Default-Datenbank gesucht werden

3 Einrichtung der Datenbank Die Datenbank muss in der richtigen Form existieren. Es muss unbedingt wenigstens ein Benutzer mit seiner Rolle (und deren Verknüpfung) eingetragen sein. Das heißt, es muss ein Benutzer mit einem Passwort und mit einer Rollenzugehörigkeit vorhanden sein, zu Anfang sinnvollerweise Loginname admin mit Passwort admin und Rolle admin. Das Eintragen kann mit dem Hypersonic-Utility HSQL Database Manager am bewerkstelligt werden. Eine andere Möglichkeit besteht darin, das Skript in einer Datei mit dem Namen import.sql in dem Verzeichnis ejbmodule des EJB-Projektes anzulegen. Bei jedem Publish- (Deploy-) Vorgang wird dieses Skript ausgeführt (manchmal kommt es dabei zu einem Stack-Trace, der nach meiner Erfahrung jedoch keinen nachteiligen Effekt hat). Als Rollen kann man die drei notwendigen, z.b. admin, gast und kunde von Hand eintragen und dann unverändert lassen. Eine Datei mit entsprechendem SQL- Skript ist bei mehrmaligem Neuanlegen der Tabellen nützlich: insert into rolle (rid, rname) values (1, 'admin'); insert into rolle (rid, rname) values (2, 'gast'); insert into rolle (rid, rname) values (3, 'kunde'); insert into benutzer (id, loginname, password, role_id) values(1, 'admin', 'admin', 1); insert into benutzer (id, loginname, password, role_id) values(2, 'gast', 'gast', 2); commit; Auch hier ist das Skript natürlich an die Gegebenheiten Ihrer Datenbank anzugleichen

4 Sicherheitseinstellungen im Web-Deployment-Deskriptor In dem Deployment-Deskriptor web.xml der Web-Anwendung müssen jetzt die folgenden Änderungen vorgenommen werden: Security Constraint Zunächst muss ein Security Constraint mit einer Web Resource Collection angelegt werden, die den Zugriff auf bestimmte Pfade und Requesttypen des Webservers steuert. Fügen Sie den Text an das Ende der bisherigen web.xml Datei vor den <ejb-ref>-einträgen an. Hier ein Beispiel: <security-constraint> <display-name> ReiseshopSecurityConstraint </display-name> <web-resource-collection> <web-resource-name>sicherresource</web-resource-name> <url-pattern>/*</url-pattern> <http-method>get</http-method> <http-method>post</http-method> </web-resource-collection> <auth-constraint> <description></description> <role-name>admin</role-name> <role-name>kunde</role-name> <role-name>gast</role-name> </auth-constraint> </security-constraint> - 4 -

5 Die Namen <display-name> und <web-resource-name> sind frei wählbar. In der Web Resource Collection werden die betroffenen Requesttypen (üblich sind GET und POST) sowie den Pfad (hier /*, also alles unter dem Wurzelverzeichnis) der betroffenen Webressourcen (z.b. JSP-Seiten und URL-Pfade) eingestellt. Z.B. kann man so auch getrennte Sicherheitsbereiche für Administratoren und Kunden definieren. Unter <auth-constraint> werden die Rollen definiert, die Zugang zu den zu schützenden Ressourcen haben. Diese Rollen müssen mit den Tabelleneinträgen in der Role Tabelle übereinstimmen. Login Konfiguration Hier gibt man die Authentifizierungs-Methode (hier Form-based) und die Namen der Login-JSP und der JSP, die im fehlgeschlagenen Loginfall aufgerufen wird, an (hinter den obigen Text einfügen): <login-config> <auth-method>form</auth-method> <form-login-config> <form-login-page>/logon.jsp</form-login-page> <form-error-page>/logonerror.jsp</form-error-page> </form-login-config> </login-config> Die erforderlichen Dateien (logon.jsp und logonerror.jsp) finden Sie in dem Beispiel für ein Web-Projekt (CustomerWeb.war) auf der Internetseite der Lehrveranstaltung unter Praktikums-Aufgaben. In logon.jsp dürfen die Bezeichner j_security_check, j_username und j_password nicht verändert werden, da sie von dem Web-Server, der die formbasierte Authentifizierung durchführt, so erwartet. Dahinter werden noch die vorgesehenen Rollen definiert: <security-role> <role-name>admin</role-name> </security-role> <security-role> <role-name>kunde</role-name> </security-role> <security-role> <role-name>gast</role-name> </security-role> Security Domain - 5 -

6 Nun muss noch die oben definierte Security Domain dem Web-Projekt zugeordnet werden. Dazu müssen wir die Datei jboss-web.xml in das WEB-INF Verzeichnis hinzufügen mit dem Inhalt: <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE jboss-web PUBLIC "-//JBoss//DTD Web Application 2.4//EN" " <jboss-web> <security-domain>java:/jaas/reiseshopsecurity</securitydomain> </jboss-web> Hierbei entspricht ReiseshopSecurity dem application-policy name in loginconfig.xml, den wir zu Anfang definiert haben

7 Security-Informationen in der Web- Schicht nutzen Nach der Servlet 2.4 Spezifikation gibt es 3 Methoden, um die Security- Informationen des Benutzers zuzugreifen. Alle sind in dem HttpServletRequest interface definiert: String user = request.getremoteuser() Liefert den Login-Namen des Benutzers. Boolean isuserinrole(string rolename) Liefert boolschen Wert, ob dem authentifizierte Benutzer die entsprechende Rolle zugeteilt wurde. Beispiel: if (request.isuserinrole("admin")) { // the user is in the manager role //... java.security.principal getuserprincipal() Liefert den Namen des Benutzers, wie er im zugewiesenen Principal Objekt abgelegt ist. Dazu muss getname() des java.security.principal Objektes aufgerufen warden: Principal principal=request.getuserprincipal(); String username=principal.getname(); - 7 -

8 Session Beans bzw. ihre Methoden absichern Für jede zu schützende Session Bean muss die dafür zuständige Security Domain angegeben werden. Das ist eine JBoss-spezifische Erweiterung (Annotation org.jboss.annotation.security.securitydomain). Die notwendigen Rollen werden mit der angegeben. Mehrere Rollen können als Array von Strings angegeben "kunde"). import javax.annotation.security.rolesallowed; @RolesAllowed("admin") // Auch mehrere "kunde") public class KundeSessionBean implements KundeSessionRemote {... Hier gilt der Schutz global für alle Methoden der Session Bean. Durch Annotationen direkt vor einzelnen Methoden kann dieser Default überschrieben werden. Eine weitere mögliche Annotation um die Klasse oder die Methode ganz frei zu geben

9 Test Client authentifizieren Wenn die Security scharf geschaltet ist, müssen auch normale Application Clients und die Test Clients sich authentifizieren. Das klappt auch für JUnit Testfälle, wenn man (am besten) mit der JUnit Version 4 arbeitet. Eclipse bietet dann sofort an, die entsprechende JUnit-Library in den Build-Pfad aufzunehmen, dem man zustimmen sollte. Mit aktivierter Security muss man nun einige besondere Vorkehrungen treffen, damit Login-Name (Principal) und Passwort (Credential) an das Login-Modul richtig übergeben werden. Leider funktioniert die einfachere Version von JBoss 4.2.x mit der JndiLoginInitialContextFactory bei JBoss 5.0 nicht mehr, so dass wir uns an der Lösung von Herrn Knauf orientieren.... Properties props = new Properties(); props.setproperty(context.initial_context_factory, "org.jnp.interfaces.namingcontextfactory"); props.setproperty(context.url_pkg_prefixes, "org.jboss.naming.client"); props.setproperty(context.provider_url, "jnp://localhost:1099"); props.setproperty("j2ee.clientname", "ReiseshopTestClient"); Context ctx = new InitialContext(props); //Login initialisieren (Knauf Security Version): SecurityClientCallbackHandler callbackhandler = new SecurityClientCallbackHandler(); LoginContext logincontext = new LoginContext("ReiseshopClientSecurity", callbackhandler); logincontext.login(); try { session = (ReiseSessionRemote) ctx.lookup("reisesessionbean"); catch (Exception ex) { System.out.println("Exception bei LookUp"); ex.printstacktrace();

10 SecurityClientCallbackHandler Login-Name und Passwort werden über einen SecurityClientCallbackHandler übergegeben. Sein Code sieht etwa wie folgt aus: import java.io.ioexception; import javax.security.auth.callback.callback; import javax.security.auth.callback.callbackhandler; import javax.security.auth.callback.namecallback; import javax.security.auth.callback.passwordcallback; import javax.security.auth.callback.unsupportedcallbackexception; public class SecurityClientCallbackHandler implements CallbackHandler { public void handle(callback[] callbacks) throws IOException, UnsupportedCallbackException { // Über alle übergebenen Callbacks iterieren: for (int intindexcallback = 0; intindexcallback < callbacks.length; intindexcallback++) { // NameCallback: Login übergeben. if (callbacks[intindexcallback] instanceof NameCallback) { NameCallback namecallback = (NameCallback) callbacks[intindexcallback]; namecallback.setname( "admin" ); // PasswordCallback: Login übergeben. else if (callbacks[intindexcallback] instanceof PasswordCallback) { PasswordCallback passwordcallback = (PasswordCallback) callbacks[intindexcallback]; passwordcallback.setpassword ("admin".tochararray() ); else { throw new UnsupportedCallbackException( callbacks[intindexcallback], "Nicht unterstützer Callback!"); Hier wurden Login-Name und Passwort fest verdrahtet eingetragen. Gegebenenfalls kann man die Werte auch einlesen

11 auth.conf Weiterhin muss in dem META-INF Verzeichnis des Application Client eine Datei mit dem Namen auth.conf mit dem folgenden Inhalt angelegt werden: ReiseshopClientSecurity { // jboss LoginModule org.jboss.security.clientloginmodule required ; ; Der Name (hier ReiseshopClientSecurity) kann frei gewählt werden

12 Starten des Clients Zum Starten muss eine Run-Konfiguration angelegt werden. Im hier gezeigten Fall ist sie für den JUnit-Test:

13 Wichtig ist, als Argument den Pfad zu der Datei auth.conf zu übergeben: Dann müsste alles funktionieren