Apply declarative role-based security to EJBs and Web components

Step 1. Create Web Application to secure

Create new Chapter5EAR Enterprise Application with Chapter5Web Web Module.

Create 3 JSPs in Web Application:

Create Web Application to secure

Step 2. Restrict access to Web pages via declarative security

In this step you implement Web declarative security to restrict access to the JSPs created in Step 1.

In the Security page of the Web deployment descriptor editor, you can add or remove the names of each defined security role.

To work in the Security page, complete the following steps:

  1. Open the Chapter5Web Web project in the Project Explorer.

  2. Double-click the Web project's Deployment Descriptor file in the Project Explorer. The Web deployment descriptor editor opens.

  3. Click the Security tab to open the Security page.

  4. The Security page has the following two sections:

    • Security Roles - lists and lets you add or remove the security roles defined for this Web application as well as provide a description of each role.

    • Security Constraints - lets you add or remove security constraints for specific security roles as well as add descriptions of each security constraint. In addition, you can add or remove Web resources and their HTTP methods, define the security roles who are authorized to access the Web resources, and specify user data constraints on user data: (None, Integral, or Confidential.)

      None means that the application requires no transport guarantees.

      Integral means data cannot be changed in transit between client and server.

      Confidential means data content cannot be observed while it is in transit.

      These data contraints usually require the use of SSL.

  5. In the Security Roles section at the top of the page, new security roles need to be added for each role that might access a resource in the Web application. Click Add. In the dialog box that appears, type EMPLOYEE_ROLE in the Name field and click Finish.

    Repeat the same for MANAGER_ROLE.

    Security Roles

    WEB-INF/web.xml:

    
    <web-app>
    	...
    	<security-role>
    		<role-name>EMPLOYEE_ROLE</role-name>
    	</security-role>
    	<security-role>
    		<role-name>MANAGER_ROLE</role-name>
    	</security-role>
    </web-app>
    								
    								

  6. Collapse Security Roles and expand Security Constraints. From this screen you perform three separate steps: add the constraint, add the Web resource collections, and add the authorization roles.

    In the Security Constraints section, click Add below the Security Constraint list. Each security constraint will define a set of resources and which roles can access them. Type Confidential in the Constraint name field and click Next.

    Constraint name

  7. Enter Confidential Resources in the Resource name field.

  8. You need to select the HTTP methods to secure. Select GET.

  9. A URI pattern is added to match the resources that you want to secure. Click Add, type /confidential.jsp in the field, and click OK. When entering your own URIs, be sure to include a slash (/) at the start of each URI. The URIs can be simple, such as /index.html, or use patterns, such as /index.*.

    Security Constraint

  10. Click the Finish button.

    WEB-INF/web.xml:

    
    <web-app>
    	...
    	<security-constraint>
    		<display-name>Confidential</display-name>
    		<web-resource-collection>
    			<web-resource-name>Confidential Resources</web-resource-name>
    			<url-pattern>/confidential.jsp</url-pattern>
    			<http-method>GET</http-method>
    		</web-resource-collection>
    	</security-constraint>
    	...
    </web-app>
    								
    								

  11. At the Security tab, select the new Confidential on the left, under Security Constraints. On the right next to Authorized Roles, click Add...

    At the Define Authorization Constraint pop-up select MANAGER_ROLE, and click Finish.

    Define Authorization Constraint

  12. Click the Finish button.

    Confidential

  13. Add the security constraint to limit access to the authenticated.jsp page.

    Add new constraint:

    • Constraint name - Authenticated

    • Resource name - Authenticated Resources

    • HTTP Methods - GET

    • Pattern - /authenticated.jsp

    Authenticated

  14. At the Security tab, select the new Authenticated on the left, under Security Constraints. On the right next to Authorized Roles, click Add...

    At the Define Authorization Constraint pop-up select EMPLOYEE_ROLE and MANAGER_ROLE, and click Finish.

    Define Authorization Constraint

    WEB-INF/web.xml:

    
    <web-app>
    	...
    	<security-constraint>
    		<display-name>Confidential</display-name>
    		<web-resource-collection>
    			<web-resource-name>
    				Confidential Resources
    			</web-resource-name>
    			<url-pattern>/confidential.jsp</url-pattern>
    			<http-method>GET</http-method>
    		</web-resource-collection>
    		<auth-constraint>
    			<description></description>
    			<role-name>MANAGER_ROLE</role-name>
    		</auth-constraint>
    	</security-constraint>
    	<security-constraint>
    		<display-name>Authenticated</display-name>
    		<web-resource-collection>
    			<web-resource-name>
    				Authenticated Resources
    			</web-resource-name>
    			<url-pattern>/authenticated.jsp</url-pattern>
    			<http-method>GET</http-method>
    		</web-resource-collection>
    		<auth-constraint>
    			<description></description>
    			<role-name>EMPLOYEE_ROLE</role-name>
    			<role-name>MANAGER_ROLE</role-name>
    		</auth-constraint>
    	</security-constraint>
    	...
    </web-app>
    								
    								

Step 3. Specify the Authentication method

Specify the Authentication method in the Login section of Pages tab. We will use "BASIC", which prompts you using the standard browser.

BASIC

Listing below shows the source tags defining the authentication mechanism (WEB-INF/web.xml):


<web-app>
	...
	<login-config>
		<auth-method>BASIC</auth-method>
	</login-config>
	...
</web-app>

					

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.

Step 4. Secure the Enterprise Application

Security roles have been defined in the Web module. For an enterprise application, you can roll up all the security roles that are defined in the application's modules. You can then combine and remove redundant or unnecessary security roles.

A security role is a logical grouping of principals. Access to operations (such as EJB methods) or web resources is controlled by granting access to a role. The Gather option rolls up all security roles defined in modules that are included in the application.

To gather security roles:

  1. In the Project Explorer view of the J2EE perspective, right-click the Deployment Descriptor for Chapter5EAR enterprise application project and select Open With > Deployment Descriptor Editor to open the Application Deployment Descriptor editor.

  2. On the Security page of the editor, click Gather button. Any security roles that are defined in the enterprise application's modules are added to the enterprise application. The security roles are not removed from the modules.

    Gather

You can use the Application Deployment Descriptor editor to replace redundant or unnecessary security roles with preferred roles.

In some application development situations, you might encounter redundant roles that are serving the same purpose throughout the enterprise application or in the modules. In this case, you can use a wizard to replace the redundant roles throughout the enterprise application and modules with the security roles that you want to keep.

For example, you have a security role Boss that is defined in the enterprise application. The Boss security role is serving the same purpose as another security role called Manager that is gathered from the EJB module. To remove the redundancy, you can replace all usages of the role Manager with the role Boss. After the Manager role is replaced by Boss, the Manager role is removed from the application and is deleted. The Manager role is also removed from the EJB module where it was gathered from and replaced with the Boss role in the module.

Step 5. Bind Application Server Security

Next task is for the application deployer to map the roles to the security implementation of the application server that the application is going to run on.

Mapping Roles to Users and Groups

We need to define the mapping between the roles used within the J2EE application, and the users and groups that exist in the security implementation currently being used by the server. One of the key benefits of J2EE's use of roles is that this information can be provided at deployment time and can be changed by a deployment tool without changing a single line of code in the application. This allows the application to be easily tested with different security implementations, moved between application servers, or mapped to different users and groups, all without code changes.

To map the role, take the following steps:

  1. In the Security page of the Chapter5EAR deployment descriptor, the WebSphere Bindings section allows you to map the roles to users and groups used by the security implementation that the server is using. Each of the defined roles is listed in the top-left corner of the page. After you select each role, you have three options of how to bind the role:

    • Everyone - Literally everyone is mapped to this role. Any user can get access to the resource that is associated with the role.

    • All authenticated users - Any user that is authenticated against the user registry can get access to the resource that is associated with the role.

    • Users/Groups - Only the users or users from the groups mapped to the role can access the resource that is associated with the role.

  2. Under Security select the EMPLOYEE_ROLE role and then under WebSphere Bindings, select the Users/Groups check box.

    Under WebSphere Bindings, expand Groups, and then select Add....

    NOTE: Ensure that you are under Groups and not under Users. Add group name: employee.

    Click Finish.

    employee

  3. Under Security select the MANAGER_ROLE role and then under WebSphere Bindings, select the Users/Groups check box.

    Under WebSphere Bindings, expand Groups, and then select Add....

    NOTE: Ensure that you are under Groups and not under Users. Add group name: manager.

    Click Finish.

    manager

  4. Save the file (Ctrl + S) and close the editor.

    application.xml:

    
    <application>
    	...
    	<security-role id="SecurityRole_1179493440666">
    		<role-name>EMPLOYEE_ROLE</role-name>
    	</security-role>
    	<security-role id="SecurityRole_1179494053439">
    		<role-name>MANAGER_ROLE</role-name>
    	</security-role>
    </application>
    								
    								

    ibm-application-bnd.xmi:

    
    <?xml version="1.0" encoding="UTF-8"?>
    <applicationbnd:ApplicationBinding ...>
      <authorizationTable xmi:id="AuthorizationTable_1179403226886">
        <authorizations xmi:id="RoleAssignment_1179493440666">
          <role href="META-INF/application.xml#SecurityRole_1179493440666"/>
          <groups xmi:id="Group_1179493440666" name="employee"/>
        </authorizations>
        <authorizations xmi:id="RoleAssignment_1179494053439">
          <role href="META-INF/application.xml#SecurityRole_1179494053439"/>
          <groups xmi:id="Group_1179494053439" name="manager"/>
        </authorizations>
      </authorizationTable>
      <application href="META-INF/application.xml#Application_ID"/>
    </applicationbnd:ApplicationBinding>
    								
    								

Step 6. Create 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.

On the disk C:\ create 2 files for users and groups.

There are two users configured in the users.prop file: Volha and Mikalai, see the listing below:

volha:vpasswd:123:567,987:Volha
mikalai:mpasswd:345:789:Mikalai
					

The file follows a very simple format, as shown below:


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

Now, create the groups.prop file. Listing below shows the three groups configured:

manager:567:volha:Manager
employee:789:mikalai:Employee
admin:987:volha:Admin
					

Listing below illustrates the simple file format. Notice that group identifiers defined in groups.prop are used in the users.prop file:


<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.

Step 7. Enable WebSphere 6.0 Security

  1. Start the server and open administrative console.

  2. Enter any user ID in the User ID field and click Log in.

  3. In the left pane, expand Security and select Global Security.

  4. In the User Registries section on the right, select the Custom link.

  5. Enter a user ID (volha) in the Server user ID field. Enter a password (vpasswd) in the Server user password field.

    Custom registry class name - com.ibm.websphere.security.FileRegistrySample

    Global Security

  6. Select Apply.

  7. Click on Custom properties.

    Since our example 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 the following data:

    Name: usersFile

    Value: c:/users.prop

    users

  8. Click Apply and then OK.

  9. On the Custom Properties window, press New again, then enter the following data:

    Name: groupsFile

    Value: c:/groups.prop

    groups

  10. Click Apply, OK and save the changes.

    Custom properties

  11. On the Global Security page select 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.

    Ensure that the Active user registry is set to Custom user registry. Click Apply.

    Global Security

  12. Save the changes and logout.

Step 8. Configure Rational Application Developer 6.0 so that it can connect to the secure server

Server config in Rational Application Developer 6.0

Step 9. Deploy and test application

  1. Once the server is started and the application is deployed, open a Web browser and enter the following URL:

    https://localhost:9443/Chapter5Web/unauthenticated.jsp

    or

    http://localhost:9080/Chapter5Web/unauthenticated.jsp

    Unprotected page

  2. Open the following URL:

    https://localhost:9443/Chapter5Web/authenticated.jsp

    or

    http://localhost:9080/Chapter5Web/authenticated.jsp

    Protected page

    Enter in the dialog:

    User ID: mikalai

    Password: mpasswd

    Protected page

    Close the Web browser.

  3. Open the following URL:

    https://localhost:9443/Chapter5Web/confidential.jsp

    or

    http://localhost:9080/Chapter5Web/confidential.jsp

    Enter in the dialog:

    User ID: mikalai

    Password: mpasswd

    Authorization Failed

    Close the Web browser.

    Open the same URL again.

    Enter in the dialog:

    User ID: volha

    Password: vpasswd

    Authorization succeeded

Adding a security identity (bean level)

Assigning a security identity to a bean is useful when another bean calls that bean. The security identity can be set to use the identity of the caller or the identity of a specific security role.

Bean-level security identity was introduced in the EJB 2.0 specification. It was not a part of the EJB 1.1 specification.

  1. In the Project Explorer view of the J2EE perspective, right-click the Deployment Descriptor for your EJB project and select Open With > Deployment Descriptor Editor to open the deployment descriptor editor.

  2. On the Access page of the editor, click Add in the Security Identity (Bean Level) section.

    Security Identity (Bean Level)

  3. Select one of the following options:

    • Use identity of caller

    • Use identity of specific role (below)

  4. If you selected Use identity of specific role (below), complete the following steps:

    1. In the Role name drop-down list, select the existing security role that you want to require for this bean-level security identity.

    2. In the Role description field, enter a description for the role.

  5. Type a description for the security identity, and click Next.

  6. Select one or more enterprise beans from the list of beans found.

  7. Click Finish.

The security identity is added. To remove the security identity, select it and click the Remove button.

Adding a security identity (method level)

Security identities on the method-level are used when another bean calls that method. The security identity specified for the method is then used. The identity can be set to use the identity of the caller, the identity of the EJB server, or the identity of a specific security role.

Method-level security identities are valid for both EJB 1.x and EJB 2.x enterprise beans in either EJB 1.x or 2.x projects.

To add a security identity (method level) to an enterprise bean:

  1. Switch to the J2EE perspective.

  2. In the Project Explorer view, select the deployment descriptor of the desired EJB module.

  3. Right click on the Deployment Descriptor, and select Open With > Deployment Descriptor Editor from the pop-up menu.

  4. On the Access page of the editor, select the Security Identity (Method Level) section.

  5. Click Add. The Add Security Identity wizard appears.

    Security Identity (Method Level)

  6. Select a run as mode from the following choices:

    • Use identity of caller - With this option, the security service makes no changes to the principal's credential settings.

    • Use identity of EJB server - With this option, the security service alters the principal's credential settings to match the credential settings associated with the EJB server.

    • Use identity assigned to specific role (below) - With this option, a principal that has been assigned to the specified security role is used for the execution of the bean's methods. This association is part of the application binding in which the role is associated with a user ID and password of a user who is granted that role.

  7. If you select Use identity assigned to specific role above, you must select a role name and role description.

  8. Type a description for the new identity in the Security identity description field.

  9. Click Next.

  10. Select one or more enterprise beans from the list of beans found, then click Next.

  11. Select one or more of the method elements for the security identity.

  12. Click Finish.

The security identity is added. To remove the security identity, select it and click the Remove button.

BOOT.BY - Tech Industry News         Free SCBCD 1.3 Study Guide     Free SCDJWS 1.4 Study Guide     SCDJWS 1.4 Quiz     Free IBM Certified Associate Developer Study Guide     Free SCJP 5.0 (Tiger) Study Guide     Free Mock Exam Engine     Free SCWCD 1.4 Study Guide     IBM Test 000-287. Enterprise Application Development with IBM WebSphere Studio, V5.0 Study Guide     Free SCBCD 5.0 Study Guide