Securing a Web Application on Glassfish using JAASDavid Salter, 10th August 2006
This article aims to show how it is possible to easily secure a web application deployed to the Glassfish application server using JAAS authentication. Since this article is focussed on securing a web application and not how to build web applications, there are no explicit details on how to build the test application. Instead of focussing on ant tasks, the article focusses on what changes need to be made to Glassfish and what changes need to be made to web applications to allow JAAS authentication to be used. The sample application developed in this article was developed using NetBeans 5.5 beta 2 and deployed to the Glassfish application server build 48.
Securing a web application with JAAS is basically a 2 stage process. Stage 1 involves configuring the relevant security realms on Glassfish and configuring users. Stage 2 involves making changes to the deployment descriptors of the web application to take the security into account.
Configuring JAAS on Glassfish
For this article, we are going to use file based users within Glassfish. The first stage in enabling this is to create a new security realm. The security realm specifies how authentication is performed and who can be authenticated. To configure a new security realm, log on to the Glassfish Administration Console by browsing to http://localhost:4848/asadmin. Expand the common tasks tree to show Configuration | Security | Realms. You will see that there are 3 realms already configured (admin-realm, file and certificate) as shown in the following screen dump.
To add a new realm, click on the Realms node in the configuration tree. The panel in the right hand side of the browser now lists all the realms in addition to a New button allowing new realms to be created. Clicking the New button causes a new page to be displayed allowing the details for a new realm to be configured as shown in the following screen shot.
Enter the name of the realm as developinjava, leaving the class name as com.sun.enterprise.security.auth.realm.file.FileRealm. Add two additional properties, file and jaas-context taking the values as shown above. These properties specify which file the users for the realm will be stored in - in this case, a file called developinjava-keyfile within the config directory of the Glassfish domain. Finally, press the OK button to create the domain. The list of realms will now be shown in the browser as below: The final stage in configuring Glassfish is to add some users to the realm. Click on the developinjava realm in the right hand side of the browser window (as shown above) to enter the Edit Realm screen as shown below:
Select the Manage Users button and on the resultant page, create a user with the following attributes:
Save this user by pressing the OK button.
That's all there is to configuring a file based JAAS realm within Glassfish. Using the Glassfish administration web console, we created a file based realm specifying a file to hold a list of all the users for the realm. We then created a user for this realm and assigned then to a group. We could have created any number of users and assigned them to any number of groups. For example all users could belong to the group Users, with only a few belonging to the group Administrators.
Configuring the Web Application
One of the main benefits ot JAAS security is that it is not pervasive within the application. By non-pervasive, I mean that the developer does not need to make explicit checks in each web page to see if the user is logged on. The developer can write their application without worrying about security. Security is then assigned to the web application declaratively using the deployment descriptors of the application.
Configuring Logging In
There are several different methods of web based authentication commonly used within web applications. Probably the simplest of these is HTTP Basic authentication. This authentication strategy involves the browser displaying a simple username/password dialog box to the user the first time the user attempts to access a restricted page. Configuring this type of authentication is described in the rest of this article.
To configure Basic authentication, the web.xml file for the web application needs editing to specify the authentication method and the realm to use for authentication. The following section within web.xml defines the HTTP basic authentication against the realm created earlier in this article.
<login-config> <auth-method>BASIC</auth-method> <realm-name>developinjava</realm-name> </login-config> Securing Web Pages
Now that the authentication strategy is specified, we need to add some security constraints to specify what pages are secured and who has access to them. Again, this is done by editing the web.xml file as follows:
<security-constraint> <web-resource-collection> <web-resource-name>Secure Pages</web-resource-name> <url-pattern>/*</url-pattern> <http-method>GET</http-method> <http-method>POST</http-method> </web-resource-collection> <auth-constraint> <role-name>USERS</role-name> </auth-constraint> </security-constraint> This XML specifies that all pages that match the URL pattern /* (i.e. All pages) that are accessed via GET or POST will be secured. Anyone that has a role of USERS will have access to these pages. Note that this role is not the same as the group Users defined in Glassfish earlier. Clearly therefore, there must be a mapping between the security role USERS and the user group Users. For Glassfish, this is specified within the sun-web.xml file within the WEB-INF directory as shown in the following XML.
<security-role-mapping> <role-name>USERS</role-name> <group-name>Users</group-name> </security-role-mapping> Now that all the XML configuration has been performed and Glassfish configured correctly, your web application should be secured against unauthorised access. Accessing a web page within your application should now produce a login dialog similar to the one below.
ConclusionThats all there is to implementing basic HTTP security for a web application in JAAS. In the next article in this series, I'll take security a bit further and discuss JDBC realms and form based authentication.
You can discuss this article here.
|
|