Introduction

With applications utilizing J2EE security more and more for features such as custom menus or personalization, having a development environment that supports J2EE security is becoming increasingly important. Because J2EE security abstracts the underlying security implementation, developers can test their J2EE applications with flat files, local operating systems, or a test LDAP server, while the production system can run with sophisticated LDAP registries.

WebSphere® application developers typically use the local operating system for their development security implementation, adding users and groups, and altering security policies through the Start => Settings menu option. However, when a development machine using Windows® belongs to a Windows domain, which is likely, setting up security can become greatly complicated. Since the version of WebSphere Application Server installed in a test environment is the same full version used in production, security in both test and production operate the same way, including searching the entire domain for the user before searching the local registry. In a development environment, where developers start and stop servers often, it is not uncommon for delays to occur while waiting for a server to start up so that a user can be verified, potentially hampering productivity. Similarly, on other operating systems, LAN administrators generally like to maintain control over security settings, leaving the developer with little flexibility.

Luckily, the local operating system is not the only security option. Another method of implementing security for testing purposes is with a file-based Custom Registry.

WebSphere Application Server V5 comes with a FileRegistrySample that can be installed without any additional coding, following a simple file format that's sufficient for most J2EE security development efforts. The FileRegistrySample uses two files: one for users, one for groups. Since developers usually only need a few sample users for test purposes, these files are easy to maintain. Not only can developers maintain these files in their WebSphere Studio workspace, they can also share it in a team environment.

Using the FileRegistrySample is a simple solution that provides J2EE developers an alternative to implementing complex security in a test environment. The FileRegistrySample is best when the application being tested uses simple J2EE security, meaning it uses the declarative role model or method calls such as isUserInRole(). If need be, developers can implement a more robust registry in an XML format, using the FileRegistrySample as an example. If the application uses more sophisticated security options, such as utilizing LDAP attributes, having an available LDAP Server in development would be worth considering.

This article will walk you through setting up the FileRegistrySample in WebSphere Studio Application Developer. We will import an EAR file with two JSPs, each one mapped to a different role. We will then setup our application server to use the FileRegistrySample, and then test it with the application. We will also review some basic J2EE security.

This article assumes a basic understanding of J2EE security, WebSphere Application Server, and WebSphere Studio Application Developer. A copy of WebSphere Studio Application Developer, Version 5, is required to explicitly follow the steps outlined throughout.

For information on writing custom registries, see Resources.

Back to top

Import Sample EAR

To begin, import the test application from Download:

1. Extract the zip file into the C:\ directory. This will create a sub-directory called security on your machine.
2. Open WebSphere Studio Application Developer and enter C:\Security\workspace in the dialog as shown in Figure 1. (If you use another workspace directory, make a note of it so you can configure FileRegistrySample later.)
   Figure 1. Open workspace
   
   
3. When the workspace opens, go to the J2EE Perspective. From the main toolbar, select File => Import.
4. Select EAR File then Next (See Figure 2).
   Figure 2: Import EAR file
   
   
5. On the next screen (Figure 3), specify the EAR File by browsing to or entering C:\Security\SecurityApp.ear.
6. For Project name enter SecurityApp.
7. Select Finish.

Back to top

Walk through the application

SecurityApp is a very simple application. It has two JSPs, each one mapped to a corresponding role:

Open the Web Deployment Descriptor to take a look at the roles:

1. Go to the J2EE Navigator view.
2. Expand SecurityWebApp and double-click Web Deployment Descriptor (Figure 4).
   Figure 4. Open Web Deployment Descriptor
   
   
3. The Web Deployment Descriptor editor opens up in a tabbed window (Figure 5). Select the Security tab.
   Figure 5. Security tab for Web Deployment Descriptor
   
   
4. In the Security dialog that displays, the Security Roles sub-tab is used to define our J2EE Roles (Figure 6). For our sample, the roles have already been created. It's important to remember that "role" is an abstract concept; it will be mapped to a corresponding profile of, for example, a group in an underlying security implementation. To the JSP, a role represents a group whose members are allowed to view that JSP, mapped together by a security constraint. To the underlying security, a role can map to a group directly or a group can map to multiple roles. A security implementation, such as Tivoli® Access Manager, may also decide to treat roles as application objects. Deciding how to map roles to groups and how to assign roles to resources takes careful planning, and should be done early in the design phase of an application. Determining roles based on use cases and interface design will contribute to the success and effectiveness of a J2EE security implementation.
   Figure 6. Roles
   
   
5. So far, we have done nothing outside the J2EE specification. If you look at the XML source for our deployment descriptor, you will see that creating roles will just update our deployment descriptor as per the J2EE Specification. Select the Source tab in Figure 7 and look for XML tags shown in the source code in Listing 1.
   Figure 7.Web XML source
   
   
   Listing 1
   

   <security-role> <description></description> <role-name>Role1</role-name> </security-role> <security-role> <description></description> <role-name>Role2</role-name> </security-role>

   
   
6. Switch back to the Security tab (Figure 5).
7. In the Security dialog that displays, select the Security Constraints sub-tab (Figure 8). A security constraint is very similar to an Access Control List (ACL). It matches a user or group to a particular resource, and to permissions the user or group may perform on the resource. For example, Tivoli Access Manager uses an ACL to allow Group A to have write access to File 1. A security constraint does this same thing within your J2EE application, but using roles: it can say that Role 1 has HTTP GET and POST permission to JSP 1. Using roles keeps our J2EE security layer separate from the actual implementation.
8. Select the first SecurityConstraint, as shown in Figure 8.
   Figure 8. Security Constraint
   
   
9. In the Web Resource Collections section, on the right side of the editor (Figure 9), we can define a security constraint to map to multiple permissions to multiple resources. Select resource1 and click Edit.
   Figure 9. Edit resource collection
   
   
10. In the Web Resource Collections dialog, you can select the HTTP methods that will be allowed, plus the URL patterns for the resource. In Figure 10, Role1 is allowed to have GET and POST permissions on the resource mapped to the URL Pattern /resource1.jsp.
    Figure 10. Web resource collections
    
    
11. Click Cancel.
12. In the Authorized Roles section, on the right side of the editor (Figure 9), we can define the roles attached to the security constraint. This is still all under the J2EE spec.
13. If you look back at the source for our Web Deployment Descriptor, you should find the tags shown in Listing 1, which shows how the security constraint acts as a logical ACL, protecting the physical resource using the logical role. Security Constraint 2 is very similar, matching /resource2.jsp to Role2 in the same manner.
    Listing 2
    

    <security-constraint> <web-resource-collection> <web-resource-name>resource1</web-resource-name> <description></description> <url-pattern> /resource1.jsp</url-pattern> <http-method> GET</http-method> <http-method> POST</http-method> </web-resource-collection> <auth-constraint> <description></description> <role-name>Role1</role-name> </auth-constraint> </security-constraint>

    
    
14. Finally, go to the Pages tab of the Web Deployment Descriptor, as shown in Figure 11.
    Figure 11. Pages tab
    
    
15. Specify the Authentication method in the Login section (Figure 12). We will use "Basic", which prompts you using the standard browser. Listing 3 shows the source tags defining the authentication mechanism. For information on other authentication mechanisms, refer to the WebSphere V5.0 Security Handbook in Resources.
    Figure 12. Basic Authentication
    
    
    Listing 3
    

    <login-config> "<auth-method>BASIC</auth-method> </login-config>

    
    
16. Close the Web Deployment Descriptor editor.

    
    Everything we have done so far is fully J2EE compliant. The J2EE specification, however, does not address how a role maps to an underlying security implementation, which is fine, since we want it to be flexible. To do this, WebSphere uses separate XMI files, called bindings files, with the Enterprise Application Deployment Descriptor editor. This editor maintains both the compliant application.xml and the WebSphere binding file with clearly marked sections to let you know which underlying file it belongs to.

17. Open the EAR Deployment Descriptor from the J2EE Navigator View (Figure 13) by expanding SecurityApp => EAR Deployment Descriptor.
    Figure 13. EAR Deployment Descriptor
    
    
18. In the EAR Deployment Descriptor, select the Security tab, as shown in Figure 14.
    Figure 14. Security tab
    
    
19. On the left side, you will see that our roles are defined just like our web.xml. WebSphere Studio Application Developer easily gathers roles from sub modules when you select the Gather button, as shown in Figure 15, adding them to the application.xml.
20. You can also select the Source tab (Figure 14) to examine the source representing the gathered roles (Listing 4).
    Figure 15. Gather security role
    
    
    Listing 4
    

    <security-role> <description></description> <role-name>Role1</role-name> </security-role> <security-role> <description></description> <role-name>Role2</role-name> </security-role>

    
    
21. To bind a role to physical users and/or groups, select the role, as shown in Figure 16.
    Figure 16. Select Role 1
    
    
22. As you can see in Figure 17, roles can be mapped to specific users and/or groups, as well as to Everyone or to just authenticated users. For our test we will map Role1 to Group1. This mapping is specified under a section called WebSphere Bindings, which means that something abstract about the J2EE Deployment Descriptor is to be associated with something real behind it. This is a consistent concept throughout the EAR, WEB, and EJB Deployment Descriptor editors. In this case, we will be bind the abstract role to the real group. (WebSphere Bindings are also referred to as WebSphere Extensions, meaning functionality beyond the J2EE Specification.)
    Figure 17. Blind Role to Groups
    
    
23. Because we have updated a binding, we need to look at the binding source, rather than the application.xml source. We can open the binding file for the EAR by expanding SecurityApp => META-INF, as shown in Figure 18, and examine the tags in the source shown in Listing 5.
    Figure 18. Binding file
    
    
    
    

    <?xml version="1.0" encoding="UTF-8"?>> <applicationbnd:ApplicationBindingxmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:applicationbnd="applicationbnd.xmi" xmlns:common="common.xmi" xmlns:application="application.xmi"xmi:id="ApplicationBinding_1042838113181"> <authorizationTable xmi:id="AuthorizationTable_1042838113191"> <authorizations xmi:id="RoleAssignment_1042838113191"> <role href="META-INF/application.xml#SecurityRole_1042838113191"/> <groups xmi:id="Group_1042838113952"name="Group1"/> </authorizations> <authorizations xmi:id="RoleAssignment_1042838113952"> <role href="META-INF/application.xml#SecurityRole_1042838113952"/> <groups xmi:id="Group_1042838113962"name="Group2"/> </authorizations> </authorizationTable> <application href="META-INF/application.xml#Application_ID"/> </applicationbnd:ApplicationBinding>

    
    
24. The key point here is that the authorizations section maps the role defined in application.xml to the group name. The xmi:id (hashed representation of the role) in the role tag serves as a link to the role back to application.xml and assigns it a group. In this case, Role1 is mapped to Group1 and Role2 is mapped to Group2.
25. Close the files.

Back to top

Import user and group file

Now that we have walked through this simple example and gone over some J2EE security basics, we can now setup the file registry.

1. The WebSphere FileRegistrySample requires two files (both of which are included in the zip file in the Download section): one that maintains users, and another that maintains groups. Import these files into your workspace using the File => Import command. When the import wizard displays, select File system => Next, as illustrated in Figure 19.
   Figure 19. Import wizard - file system
   
   
2. On the next screen, Figure 20, navigate to or specify the directory containing the downloadable zip file, such as C:\Security.
3. On the right side, check users.prop and groups.prop.
4. For Folder, specify SecurityAppWeb, and select create selected folders only.
   Figure 20. Import security files
   
   
5. Let's examine the two files before setting up our file registry. Open the users.prop file first. From the J2EE Navigator view, expand SecurityAppWeb and open users.prop (Figure 21).
   Figure 21. users.prop
   
   
6. There are two users configured in the users.prop file: User1 and User2. (Listing 6) The file follows a very simple format, as shown in Listing 7.
   Listing 6
   

   user1:password:123:567,987:User1 user2:password:345:789:User2

   
   
   Listing 7
   

   <user name>:<password>:<unique user identifier>:<identifiers of groups user belongs to commas separated>:<Display Name>

   
   
7. Now, open the groups.prop file in the same manner (Figure 22). Listing 8 shows the three groups configured, and Listing 9 illustrates the simple file format. Notice that group identifiers defined in groups.prop are used in the users.prop file.
   Figure 22. Open groups.prop
   
   
   Listing 8
   

   group1:567:user1:Group1 group2:789:user2:Group2 admin:987:user1:Admin

   
   
   Listing 9
   

   <group-name>:<group identifier>: <users that belong to the group comma separated>:<display name>

   
   

Remember that this file format is provided as a sample for how to build a Custom Registry, but there is no reason we can't use it as a development alternative to the local operating system for security. If you prefer, you can create your own file registry.

Also, be aware that these files must remain in sync; if you add a user to a group, both files will need to be updated.

It's important to note that using flat files for security is not a recommended practice. We are using it here since we are dealing exclusively with a development scenario. In contrast, a production environment should be using significantly more robust security solutions, such as an LDAP registry or Tivoli Access Manager. For more information on security production suggestions, or on creating your own development file registry, see the WebSphere V5.0 Security WebSphere Handbook in the Resources section.

Back to top

Create and configure server

We will now create our server and enable the administrative client. After doing so, we will go in through the WebSphere Application Server V5 admin console to finish up the configuration.

We can configure our test application server by using either the admin console or the WebSphere Studio editors, the latter of which actually comprise a subset of the former. The WebSphere Studio editors contain a majority of the configuration options a developer needs, while the admin console contains extra settings that are not necessarily prevalent to developers, such as clustering servers. The one or two features not configurable through WebSphere Studio are those which are typically handled by the operating system. Security is one of these, which is why we need to go to the admin console to set the custom file registry to be our security implementation.

To create the server and view the security information:

1. Switch to the Server perspective by clicking on the Perspective button in the upper left corner of the window (Figure 23).
   Figure 23. Open server perspective
   
   
2. A drop down menu will display with several perspective choices. Select Server (or select Other => Server if Server is not displayed).
3. In the Server Configuration view, right click on the Servers folder (Figure 24).
   Figure 24. Server configuration
   
   
4. Select New => Server => Server Configuration. This will open the New Server wizard (Figure 25).
5. Enter the following data:
   • Server name: WAS5
   • Folder: Servers
   • Server type: expand WebSphere version 5 and select Test Environment
   • Leave all other values as default values.
   
   Figure 25. New server
   
   
6. Open the Server Configuration editor by going back to the Server Configuration view (Figure 26), expand Servers and double click WAS5.
   Figure 26. Open server configuration
   
   
7. Select the Security tab on the Server Configuration editor (Figure 27) and review the different security options (Figure 28).
   Figure 27. Security tab
   
   
8. The Enable security check box will automatically configure your test server to use the local operating system for security (Figure 28). This could also be accomplished using the admin console.
   Figure 28. Security section
   
   
9. As mentioned earlier, we cannot setup the custom registry from any WebSphere Studio Application Developer editor, but we can do this using the admin console. By default, the admin console is disabled on test servers created within WebSphere Studio. However, the admin console can be can easily enabled by going to the Configuration tab within the Server Configuration editor (Figure 29).
   Figure 29. Configuration tab
   
   
10. Check Enable administrative console (Figure 30).
11. Save and close the configuration file.
    Figure 30. Enable Admin console
    
    

Back to top

Setup custom registry

We are now ready to configure our custom registry, to have it use the FileRegistrySample, and to enable global security and have it use the custom registry.

1. We need to start our server and open the admin console, which is a Web application running inside WebSphere Application Server. To do this, go to the Servers view.
2. Right click the WAS5 server and select Start (Figure 31). Control should now switch to the console.
   Figure 31. Start server
   
   
3. Wait for the "Open for e-business message", then go back to the Servers view.
4. Right click the WAS5 server again, then select Run Administrative Client. This will bring up the browser and display the login screen of the admin console. (If not, open a browser and go to http://localhost:9090/admin.)
5. Since security is not enabled, you are prompted for only a user ID, but the user ID must be the one you are currently logged in with for the operating system. Once we enable our security to use the custom registry, you will need to use one of the user IDs defined in the users file. In the meantime, enter your current user ID, and select OK (Figure 32).
   Figure 32.
   
   
6. Next, from the Navigation menu of the admin console, expand Security => User Registries =>Custom (Figure 33). This will take you to the User Registry screen (Figure 34).
   Figure 33. Custom User Registry
   
   
7. In the User Registry window (Figure 34), we need to enter data that implements the user registry interface we are using, in our case the FileRegistrySample. Since we are using the FileRegistrySample, we need to make sure we enter a valid user ID from the users.prop file; we will use User1. The server will need this ID as well. Since this is being used as a development aid, we need not worry about protecting the admin console, however, you can assign one of the administrative roles if you desire. Enter the following information:
   • Server User ID: user1
   • Server User Password: password
   • Custom Registry Classname: com.ibm.websphere.security.FileRegistrySample
8. Select Apply.
9. Click on Custom Properties.
   Figure 34. Configure Custom User Registry
   
   
10. Since FileRegistrySample uses two property files, users.prop and groups.prop, we need to tell it where these files are located. On the Custom Properties window, press New, then Enter, then enter the following data (Figure 35):
    • Name: usersFile
    • Value: c:/Security/workspace/SecurityAppWeb/users.prop
    Keep in mind that if you used a different WebSphere Studio directory for your workspace, you need to use that workspace directory instead of c:/security/workspace. (In a team environment, you can configure an environment variable called workspace.)
    Figure 35. Set usersFile property
    
    
11. Click OK.
12. Click New again, then enter the following data (Figure 36):
    • Name: groupsFile
    • Value: c:/Security/workspace/SecurityAppWeb/groups.prop
    
    Figure 36. Set groupsFile
    
    
13. Click OK. The users and groups properties should now be properly configured, as shown in Figure 37.
    Figure 37. Custom properties
    
    
14. With the custom registry successfully configured, we now need to enable our Global Security. From the navigation menu bar, select Security => Global Security (Figure 38).
    Figure 38. Global security link
    
    
15. In the Global Security window (Figure 39), check the Enabled box to enable Global Security. De-select Enforce Java 2 Security; Java 2 Security enforces policy files to protect different resources, but such strict requirements are not necessary for our development implementation.
16. For Active User Registry, select Custom from the list.
17. Leave the default values for the remaining fields.
18. Press OK.
    Figure 39. Global security
    
    
19. Now that all necessary changes have been made, we need to persist our changes by saving the configuration. Click on Save on the top menu, or on the Save link in the Message(s) dialog (Figure 40), if displayed.
20. Click the Savein the Save window (Figure 41) to make the configuration change final.
    Figure 40. Save link
    
    
    Figure 41. Press save.
    
    
21. Finally, select Logouton the top menu bar (Figure 42).
22. Close the browser.
    Figure 42. Logout
    
    
23. Stop the server. In the Server view, right click on WAS5 and select Stop (Figure 43).
    Figure 43. Stop server
    
    

Back to top

Deploy and test application

We are now ready to deploy and test the application. We will add our application to the server configuration, start the server and access each resource with User1 and User2. We will also look at the admin console login screen and see that it has changed to use a secure login form. We will be using a browser, but because we are using Basic Authentication, we will need to disassociate the browser with the user by closing then opening the browser. (The WebSphere Studio browser caches the user for Basic Authentication, even if it is closed down, so it is recommended that you use Miscrosoft® Internet Explorer or Netscape® Navigator to run this test successfully.)

1. To add our application to the server, go to the Server Configuration view by expanding Servers => WAS5 => Add => SecurityApp. Your view should look similar to Figure 44.
   Figure 44. Deploy application
   
   
2. Return to the Server view, right-click the Server, which is WAS5 in Figure 45, and select Start.
   Figure 45. Start server
   
   
3. Once the server is started, open a Web browser (such as Internet Explorer or Netscape) and enter the following URL: http://localhost:9080/SecurityAppWeb/resource1.jsp.
4. The browser should present the basic authentication prompt, as shown in Figure 46. Enter:
   • User Name: user1
   • Password: password
   
   Figure 46. User1 login
   
   
5. If you remember, User1 is allowed to see resource1, but not resource2. For this first URL, then, you should get the message shown in Figure 47.
   Figure 47. User 1 on resource 1
   
   
6. Now, enter the following URL into the same browser: http://localhost:9080/SecurityAppWeb/resource2.jsp. You should get a "403: AuthorizationFailed" error, as shown in Figure 48.
   Figure 48. User 1 on Resource 2
   
   
7. Close the browser.
8. Open a new browser and enter the following URL: http://localhost:9080/SecurityAppWeb/resource2.jsp (Figure 49).
9. This time, login with:
   • User Name: user2
   • Password: password
   
   Figure 49. User 2 login
   
   
10. Since User 2 is trying to access resource2, success will be displayed with the message in Figure 50.
    Figure 50. User 2 on resource 2
    
    
11. In the same browser, enter the following URL: http://localhost:9080/SecurityAppWeb/resource1.jsp.
12. Since User 2 is not allowed to see resource1, we should get the error message shown in Figure 51.
    Figure 51. User 2 on Resource 1
    
    

    We now have J2EE Security working using a simple file based registry.

    One side effect of using a file based registry is that admin console users are also subject to the file registry. For one final test, go back to the Servers view, right click WAS5 and run the administrative client again. This time, the login form for the admin console will ask for the user ID and the password (Figure 52). To get in, enter:

    • User Name: user1
    • Password: password
    
    Figure 52. Secure admin login
    
    

Back to top

Conclusion

In this article we learned that the local operating system is not the only option for developers to test their J2EE Applications inside WebSphere Studio, since developers can instead use resources such as a file based registry or an LDAP server (even in development). We reviewed some basic J2EE security, went over Web and application deployment descriptor editor options for security, and described how to map them to the underlying security implementation. Finally, we configured and tested the FileRegistrySample, deployed the application, and tested our security.

As with many J2EE features, the underlying mechanism for implementation is abstracted out; this is one of the many benefits of J2EE. Developers should be able to test a feature without the full weight of the underlying production system. Security is no different. Developers have options in setting up their test security to meet their development needs without compromising the requirement for a secure environment.

Back to top

Download

Name	Size	Download method
FileRegistry.zip	0.1 MB	FTP|HTTP

Information about download methods

About the author

Roland Barcia is a senior software consultant for IBM Software Services for WebSphere in the New York/New Jersey Metro area. You can contact Roland at barcia@us.ibm.com.

Rate this article

Comments

Back to top

Table of contents

• Introduction
• Import Sample EAR
• Walk through the application
• Import user and group file
• Create and configure server
• Setup custom registry
• Deploy and test application
• Conclusion
• Download
• About the author
• Comments

Next steps from IBM

Rational Application Developer features provide the comprehensive Integrated Development Environment (IDE) used to develop J2EE applications requiring Servlets and JavaServer Pages (JSPs).

---

• Try: Try the free Rational Application Developer, which helps developers quickly design, develop, test, analyze, and deploy high-quality Java, Javaserver pages, and J2EE applications.
• Article: Learn how you can deliver accurate, higher-quality J2EE apps with Rational Application Developer, open source JUnit and JUnitEE test frameworks.
• Tutorial: Build a Facebook application using PHP, the Spring framework, and J2EE.
• Demo: This demo shows how to use the new Java EE 5 Java Persistence API (JPA) framework.
• Buy: Rational Application Developer

Dig deeper into WebSphere on developerWorks

Discover knowledge paths

Skill-building guides for WebSphere, Linux, open source, cloud, Java, business analytics, and more.

Special offers