Test J2EE Security Applications in WebSphere Studio V5

http://www-900.ibm.com/developerWorks/cn/wsdd/techjournal/0303_barcia/barcia.shtml

© Copyright International Business Machines Corporation 2003. All Rights Reserved.

introduction

As the application is increasingly utilizing J2EE security to implement certain features (such as custom menus or personalization), it has become more important. Since J2EE security summarizes basic security implementations, developers can use flat files, local operating systems, or test LDAP servers to test their J2EE applications, while the production system can run in the case of using advanced LDAP registry.

WebSphere application developers typically use local operating systems to develop security implementations, increasing users and groups and changing security policies via start => settings menu options. But if you use Windows development machines belong to a Windows domain - this situation is very likely, setting security will become very complicated. Since the WebSphere Application Server version installed in the test environment is the same as the full version of the production environment, the safety of tests and production is operated in the same way, including searching for users throughout the domain before searching for the local registry. In the development environment, developers often start and deactivate the server, which occurs when the server is launched to verify the user, which potentially hinders production efficiency. Similarly, on other operating systems, local area network administrators usually like to maintain control for security settings, only for developers to keep small flexibility.

Fortunately, the local operating system is not the only security option. Another safety implementation method for testing purposes is to use file-based custom registry.

WebSphere Application Server V5 has a FileRegistrySample, which can be installed without additional code, follow a simple file format, which can be used for most J2EE security development work. FileRegistrySample uses two files: one for users, one for groups. Since developers only require a few sample users for testing, these files are easy to maintain. Developers can not only maintain these files in WebSphere Studio works, but also share them in a team environment.

Using FileRegistrySample is a simple way to provide an alternative to J2EE developers with complex security in test environments. When the test application uses simple J2EE security, it is the best choice to use the method that describes the method or iSuserinrole (). If necessary, developers can use FileRegistrySample as an example, and implement a more robust registry with XML format. If the application uses a more complex security option, for example, using the LDAP property, it will be worth considering in the development of an available LDAP server.

This article will guide you to complete FileRegistrySample in WebSphere Studio Application Developer. We will import EAR files with 2 JSP pages, and each page is mapped to different roles. The application server is then installed to use FileRegistrySample, and then test it with the application. We will also review some basic J2EE security.

This article assumes that the reader has the 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 grading steps from beginning to end. To learn about the information about writing a registration center, see Resources.

Import example EAR

First, import the test application from the download section:

Unzip the compressed file to the C: / directory. This will create a subdirectory named Security on your machine. Open WebSphere Studio Application Developer and enter C: / Security / Workspace in the dialog shown in Figure 1. (If you use another workspace directory, please write down the directory to configure FileRegistrySample.)

Figure 1. Open work space

When the working space is turned on, go to the J2EE perspective. Select File => Import from the main toolbar. After selecting the EAR file, click Next (see Figure 2).

Figure 2: Import EAR file

In the next screen (Figure 3), specify the EAR file, by browsing or entering C: /Security/securityApp.ear. Enter securityApp for Project Name. Select Finish.

Figure 3. Security application

Browse the app

SecurityApp is a very simple application. It comes with 2 JSP pages, mapping to the corresponding role per page:

JSP role resource1.jsp role 1Resource2.jsp role 2

Open Web Deployment Descriptor View Roles:

Go to J2EE Navigator view. Expand SecurityWebApp and double-click Web Deployment Descriptor (Figure 4).

Figure 4. Open Web Deployment Descriptor

The Web Deployment Descriptor editor is open in a tab window (Figure 5). Select the Security tab.

Figure 5. Security tab for Web Deployment Descriptor

In the displayed security dialog, the Security Roles subtab is used to define our J2EE role (Figure 6). For our example, the role has been created. Keep in mind that this is very important, "role" is an abstract concept; it will map to the corresponding profile, such as a summary of a group of a found security implementation. For the JSP page, the role represents a group, allowing the members to view the JSP page, map with a security constraint. For basic security, the role can be mapped directly to a group, or groups can map to multiple roles. Security implementation (for example, Tivoli_Access Manager) can also decide to process roles as an application object. Decide how to map roles to groups and how to assign roles to resources to carefully plan, and should be completed early in the application design phase. The use occasion and interface design determines the success and effectiveness of J2EE security implementation.

Figure 6. Role

So far, we have been working under the J2EE specification. If you look at the XML source code for our deployment descriptor, you will find that the creation role will update our deployment descriptor, just like the J2EE specification. The Source tab is selected in Figure 7 and lookup XML tags in the source code of Listing 1. Figure 7.Web XML source code

Listing 1.

role1 role2

Switch back to the Security tab (Figure 5). In the displayed security dialog box, select the Security Constraints subtab (Figure 8). Security constraints are very similar to access control lists (Access Control List, ACL). It matches users or groups to specific resources and permissions for users or groups. For example, Tivoli Access Manager uses ACL to allow group A to have write permissions on file 1. Security constraints implement the same feature in your J2EE application, but use roles: You can say that role 1 has HTTP GET and POST permissions on the JSP page 1. Use the role to make our J2EE security layer separated from the actual implementation. Select the first securityConstraint, as shown in Figure 8.

Figure 8. Security constraint

At the Web Resource Collection section, on the right side of the editor (Figure 9), we can define a security constraint to map multiple permissions for multiple resources. Select Resource1 and click Edit.

Figure 9. Editing resource collection

In the Web Resource Collection dialog, you can select Allowed HTTP methods to add URL patterns for resources. In Figure 10, Role1 allows resources to map to URL mode /Resource1.jsp to have GET and POST permissions.

Figure 10. Web resource collection

Click Cancel. In the Authorized Roles section, on the right side of the editor (Figure 9), we can define the roles connected to security constraints. This is still in the J2EE specification. If you review our Web Deployment Descriptor source code, you should discover the tag shown in Listing 1, which describes how to work like a logical ACL and use logical roles to protect physical resources. Safety Constraint 2 is very similar to the same manner to match Role2.

Listing 2.

resource1 /resource1.jsp get post role1 Finally, go to Web Deployment Descriptor's Pages tab, as shown in Figure 11.

Figure 11. Pages tab

Specify the authentication method (Figure 12) in the login section. We will use "Basic", which prompts you to use standard browsers. Listing 3 illustrates the source mark defining the authentication mechanism. For information on other authentication mechanisms, see WebSphere V5.0 Security Handbook in the reference.

Figure 12. Basic certification

Listing 3.

Basic

Turn off the Web Deployment Descriptor editor.

All the work we are currently followed by J2EE specifications. However, the J2EE specification does not specify how the role maps to the basic security implementation, because we want it to be flexible. To do this, WebSphere uses an Enterprise Application Deployment Descriptor editor using an Enterprise Application Deployment Descriptor editor. This editor maintains the use of clear annotations to make you understand which basic file it belongs to the specified Application.xml and WebSphere bind files.

Open Ear Deployment Descriptor from J2EE Navigator View by expanding securityApp => EAR Deployment Descriptor (Figure 13).

Figure 13. EAR Deployment Descriptor

In Ear Deployment Descriptor, select the Security tab, as shown in Figure 14.

Figure 14. Security tab

On the left, you will see that our role is as defined as web.xml. When you select the Gather button, as shown in Figure 15, WebSphere Studio Application Developer is easy to collect roles from the submodules, add them to Application.xml. You can also select the Source tab (Figure 14) to check the source code for the collected roles (Listing 4). Figure 15. Collecting security roles

Listing 4.

role1 role2

To bind the role to the physical user and / or group, select the role as shown in Figure 16.

Figure 16. Select role 1

As shown in FIG. 17, the role can be mapped to a particular user and / or group, which can also be mapped to all users or only mapped to authentication users. For this test, we map role1 to group1. The mapping is specified under the paragraph named WebSphere Bindings, which means that abstract content about J2EE Deployment Descriptor must be associated with the corresponding real object. This is a consistent concept that runs through the Ear, Web and EJB Deployment Descriptor Editor. In this case, we bind abstract roles to the actual group. (WebSphere Bindings is also known as WebSphere Extensions, indicating that its feature exceeds the J2EE specification.)

Figure 17. Bind the role to the group

Because we have updated a binding, we need to view the binding source code, not the Application.xml source code. We can open the bind files for EAR by extending securityApp => Meta-INF, as shown in Figure 18, and check the markers of the source code displayed in Listing 5.

Figure 18. Binding file

Listing 5.

> This is a key point where the authentication segment maps the role defined in Application.xml to the group name. The XMI: ID in the role tag (the aquary representation) is used as a link to the APPLICATION.XML as the role and assigns a group. In this case, Role1 is mapped to group1, and Role2 is mapped to group2. Close the file.

Import users and group files

Since we have already browsed this simple example and understand some J2EE security foundations, we can install the file registration center now.

WebSphere FileRegistrySample requires two files (all in the compressed files of the download section): a maintenance user, another maintenance group. Use the file => import command to import these files into your workspace. When the import wizard is displayed, select File System => NEXT, as shown in Figure 19.

Figure 19. Import Wizard - File System

In the next screen, in Figure 20, browse or specify a directory containing the compressed files that can be downloaded here, such as C: / Security. On the right, select Users.prop and Groups.prop. Specify SECURITYAPPWEB for Folder and select Create Selected Folders ONLY. Figure 20. Import security file

Check these two files before installing the file registry. First open the users.prop file. From J2EE Navigator view, expand SecurityAppWeb and open Users.prop (Figure 21).

Figure 21. Users.prop

Two users are configured in the Users.Prop file: USER1 and USER2. (Listing 5) Failure follows a very simple format, as shown in Listing 6.

Listing 5.

User1: Password: 123: 567,987: User1User2: Password: 345: 789: User2

Listing 6.

: : : :

Now open the groups.prop file in the same way (Figure 22). Listing 7 Displays three groups of configuration, inventory 8 Description Simple file format. Note The group identifies defined in Groups.prop are used for file users.prop.

Figure 22. Open Groups.prop

Listing 7.

Group1: 567: User1: Group1Group2: 789: User2: Group2admin: 987: User1: admin

Listing 8.

: : :

Remember this file format is provided as an example of building a custom registration center, but not, we can't use the development of the local operating system for security. If you want to do this, you can create your own file registry.

At the same time, pay attention to these files must reside in SYNC; if you add users to the group, both files need to be updated.

It is not recommended to use a flat file for security and point out that this is important. We use it here because we specialize in the development plan. Conversely, the production environment should use significantly more robust solutions such as the LDAP registry or Tivoli Access Manager. For more information on safety production recommendations or create your own development file registration, see WebSphere V5.0 Security WebSphere Handbook in the Reference section.

Create and configure the server

Now we create a server and enable the management client. After that, we can complete the configuration work through the WebSphere ApplicationServer V5 management console.

We can configure the test application server by using the Management Console or WebSphere Studio editor, the WebSphere Studio editor actually contains a subset of the management console. The WebSphere Studio editor contains most of the configuration options you need to develop, and the management console contains additional settings that are not necessary for developers, such as cluster servers. One or two functions that cannot be configured through WebSphere Studio are typical features that are processed by the operating system. Safety is one of them, which is why we need to turn to the management console to set the custom file registry as a security implementation. To create a server and view security information:

Switch to the Server perspective by clicking the Perspective button in the upper left corner of the window (Figure 23).

Figure 23. Open Server perspective

A drop-down menu with several perspective selections will be displayed. Select Server (or select Other => Server if the Server is not displayed). In the Server Configuration view, right-click the Servers folder (Figure 24).

Figure 24. Server configuration

Select New => Server => Server Configuration. This will open the New Server Wizard (Figure 25). Enter the following data:

Server Name: WAS5 folder: Servers Server Type: Expand WebSphere Version 5 and select Test Environment to keep all other values ​​for default.

Figure 25. New Server

Returns the Server Configuration Editor (Figure 26) to expand Servers and double-click WAS5.

Figure 26. Open server configuration

Select the Security tab on the Server Configuration Editor (Figure 27) to check different security options (Figure 28).

Figure 27. Security tab

The Enable Security checkbox will automatically configure your test server for security purposes (Figure 28). This can also be implemented by using the management console.

Figure 28. Seg

As mentioned earlier, we cannot install custom registry from any WebSphere Studio Application Developer editor, but you can use the management console to do this. By default, the test server created in WebSphere Studio is disabled. However, the management console can be simply activated through the Configuration tab within the Server Configuration Editor.

Figure 29. Configuration tab

Select Enable Administrative Console (Figure 30). Save and close the configuration file.

Figure 30. Enable management console

Install custom registration center

Now we are ready to configure our custom registration center to use FileRegistrySample, and enable global security to use custom registry.

We need to launch the server and open the management console, which is a web application running within WebSphere Application Server. To achieve this, turn to the Servers view. Right-click the WAS5 server and select START (Figure 31). The control should now be switched to the console.

Figure 31. Starting the server

Wait for "Open for E-Business Message", then return to the Servers view. Right click on the WAS5 server again, then select the Run Administrative Client. This will call the browser and display the login screen of the management console. (If you do not, open the browser and turn to http: // localhost: 9090 / admin.) Since the security is not enabled, you will get a prompt with only one user ID, but the user ID must be your current use to log in to the operating system. ID. Once we enable security to use custom registry, you will need to use one of the user IDs defined in the user file. Also, enter your current user ID and select OK (Figure 32). Figure 32.

Next, from the Navigation menu of the management console, expand Security => user registries => Custom (Fig. 33). This will take you to the User Registry screen (Figure 34).

Figure 33. Custom User Registration Center

At the User Registry window (Figure 34), we need to enter data to implement the user registration interface we use in the FileRegistrySample example. Since we use FileRegistrySample, we need to make sure to enter a valid user ID from the users.prop file; we will use USER1. The server also needs this ID. Because this is used to develop auxiliary tools, we don't have to worry about the protection of the management console, but if you want, you can assign one of the management roles. Enter the following information:

Server User ID: User1 Server User Password: Password Custom Registry ClassName: com.ibm.Websphere.Security.FileRegistrySamplesample

Select Apply. Click Custom Properties.

Figure 34. Configuring custom user registration centers

Since FileRegistrySample uses two properties files, users.prop, and groups.prop, we need to tell the location of these files. In the Custom Properties window, press NEW, then press Enter, then enter the following data (Figure 35):

Name: UserSfile Value: C: /Security/Workspace/securityAppWeb/Users.prop If you use a different WebSphere Studio directory for your workspace, remember that you need to use this directory instead of C: / security / Workspace. (In a team environment, you can configure the environment variable named Workspace.)

Figure 35. Setting Usersfile properties

Click OK. Click New again, then enter the following data (Figure 36):

Name: Groupsfile value: c: /security/Workspace/securityappweb/groups.prop

Figure 36. Setting Groupsfile

Click OK. Now, users and group properties should be configured correctly, as shown in Figure 37.

Figure 37. Custom attribute

After successfully configuring custom registry, we need to enable global security. Select Security => Global Security from the navigation menu bar.

Figure 38. Global Security Links in the Global Security window (Figure 39), select the enabled box to enable Global Security. Deselect Enforce Java 2 Security; Java 2 Security uses policy files to protect different resources, but such strict restrictions are not required for our development implementation. Select Custom from the list from the list. Keep the default value for the remaining fields. Press OK.

Figure 39. Global security

Since all required changes have been completed, we need to continue the changes by saving configurations. Click the Save above the menu, or if the message dialog is displayed (Figure 40), click the Save link. In the save window (Figure 41), click Save to make a final configuration change.

Figure 40. Save Link

Figure 41. Press the SAVE button.

Finally, select Logout in the upper menu bar (Figure 42). Close the browser.

Figure 42. Logout

Deactivate the server. At the Server view, right-click WAS5 and select STOP (Figure 43).

Figure 43. Disable server

Deploy and test the application

We are now ready to deploy and test your application. We will add an application to the server configuration, start the server and use USER1 and USER2 to access each resource. We will also view the management console login screen and make sure it has changed to the use of security login forms. We will use a browser, but due to the use of basic authentication, we need to separate the browsers and users by turning off the browser first. (WebSphere Studio browser stores users for basic authentication, even if it is closed, it is recommended that you use Miscrosoft_Internet Explorer or Netscape_navigator to successfully run this test.)

To add our app to the server, turn to the Server Configuration view by expanding servers => was5 => add => securityapp. Your view should be similar to Figure 44.

Figure 44. Deployment application

Returns the Server view, right-click Server, as shown in Figure 45, and select START.

Figure 45. Starting the server

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. The browser should present a basic authentication prompt, as shown in Figure 46. enter:

User Name: user1 password: password

Figure 46. User1 login

If you still remember, User1 allows you to view resource1, but you don't allow you to view resource2. For the first URL, you should get the message as shown in Figure 47.

Figure 47. User 1 on Resource 1

Now, enter the following URLs in the same browser: http: // localhost: 9080 / securityappWeb / Resource2.jsp. You should get "403: AuthorizationFailed" error message, as shown in Figure 48.

Figure 48. User 1 on Resource 2

Close the browser. Open a new browser and enter the following URL: http: // localhost: 9080 / securityappWeb / Resource2.jsp (Figure 49). Use the following information to log in: user name: user2 password: Password

Figure 49. User 2 Login

Since User 2 is displayed in trial access to resource2, the success information will be displayed together with the messages in Figure 50.

Figure 50. User 2 on Resource 2

In the same browser, enter the following URL: http: // localhost: 9080 / securityappWeb / Resource1.jsp. Since User 2 does not allow viewing resource1, we should get an error message as shown in Figure 51.

Figure 51. User 2 on Resource 1

Now we use a simple file-based registry to make J2EE security start working.

A side effect using a file-based registration center is that the management console user is also from the file registry. To a final test, return a Servers view, right-click WAS5 and run the management client again. This time, the login form for the management console will require the user ID and password (Figure 52). For enter, enter:

User Name: user1 password: password

Figure 52. Safety management login

Conclude

In this article, we understand that the local operating system is not the only choice for the J2EE application to test the J2EE application within WebSphere Studio, because developers can change resources such as file-based registry or LDAP server (even in the development process) in). We review some basic J2EE security, check the Web and application deployment descriptor editor options for security, and describe how to map them to the basic security implementation. Finally, we configure and tested FileRegistrySample, deploying applications, and tested security.

As with many J2EE functions, the basic mechanism for implementation is abstract; this is one of the benefits of J2EE. Developers should be able to test a feature without requiring all content of the basic production system. Safety is not different. Developers have different options to configure their test security to meet development needs, do not have to reduce requirements for the security environment.

Reference

IBM WebSphere V5.0 Security WebSphere Handbook Series with WebSphere Portal uses custom registry IBM Tivoli Access Manager 3.9 with WebSphere Application Server integration: Complete Security Solution