Introduction

In the current SCA Assembly Model Specification document (see the Resources section), QoS is not part of the main specification and is defined only in an appendix. It lists the standard SCA policy elements and attributes for three domains : security, transaction and reliable messaging.

WebSphere Process Server, coupled with WebSphere Integration Developer, provides an implementation of these domains. When wiring SCA components packaged into an SCA module, you can specify QoS qualifiers. These qualifiers provide a quality of service to the SCA components but also to the clients of these components. You can define the qualifiers at three levels :

• References
• Interfaces
• Implementation

For an overview of the different SCA elements and these three levels, see Building SOA solutions with the Service Component Architecture -- Part 1.

Depending on the qualifier, the definition may not be available at a particular level. Security qualifiers can only be defined at these two levels :

• Interfaces: at this level, you define the security permission of the SCA component. It enables you to define a J2EE role, so only clients associated with this role are authorized to invoke the component.
• Implementation: at this level, you define the security identity of the SCA component. It enables you to define the component identity, in a similar way to how you define the delegation policy (called also Run-As mode mapping) for an Enterprise Java Bean (EJB). It allows all methods of a component to be run as a member of a specific security role.

All the qualifiers are defined in specific sections of the Service Component Definition Language (SCDL) file that defines the interface, implementation, and the qualities of service requirements of an SCA component.

Now we'll show you how to define the security qualifiers on SCA components with the help of a simple example developed with WebSphere Integration Developer. The WebSphere Integration Developer version used in this article is 6.0.1.

Back to top

About the sample application

You won't walk through the sample step by step from scratch since we want to focus on the security implementation of an SCA component. The sample we will use comes from the article Building SOA solutions with the Service Component Architecture -- Part 1.

You will import a project interchange file into WebSphere Integration Developer, containing a prebuilt sample that is composed of an SCA module with one SCA component, the Java implementation of this component, and a JSP test page calling it. A form-based login page is also included to permit logging in to the sample.

Figure 1 shows the composition of the CreditApprovalSCAModule SCA module, containing the CreditApproval SCA component, and a stand-alone reference since CreditApproval is called by a JSP (a non-SCA component.)

Back to top

Importing the sample

First you need to download the sample and import it into your WebSphere Integration Developer workspace.

1. Download the project interchange file included with this article on your hard drive. A project interchange file is a compressed archive that contains all the source projects including the SCA modules.

2. Open WebSphere Integration Developer to a blank workspace and close the Welcome screen. The workbench should be open to the Business Integration perspective.

3. To import the project interchange file, right-click the Business Integration view and select Import.

4. Select Project Interchange, and then Next.

5. Browse to the file you have downloaded, then click Select All and Finish. If in the Problems tab you see errors, rebuild the project by clicking on the Project menu, then click Build Automatically to deselect it, and then click Build All.

6. Expand the CreditApprovalSCAModule module (Figure 2).

   
   Figure 2. CreditApprovalSCAModule expanded
   
   

7. Notice the CreditApproval interface and the CreditApprovalImpl Java implementation for the CreditApproval SCA component.

Back to top

Defining the security roles

Next we'll define the security roles for Security roles are named sets of users that will have access to secure resources (like a servlet, JSP, EJB or SCA component) and methods. In the sample, the resources we want to secure are the JSP that calls the SCA component, and the SCA component itself. The roles are mapped to real users and groups at application deployment time, during a process called security role mapping.

For our example, the security roles are already defined in the project interchange file you imported.

We will often use the J2EE perspective for ease of use. With some product licenses, this perspective might not be available. If you don't see this perspective, you can add the Navigator view to the Business Integration perspective, but you cannot use the deployment descriptor editors.

1. From the Window menu, select Preferences.

2. Expand Workbench and click on Capabilities.

3. Check Advanced J2EE, then click OK.

4. From the Window menu, select Open Perspective - Other...

5. Select J2EE, click OK.

6. On the Project Explorer view, expand Dynamic Web Projects, the CreditApprovalClient project, and WebContent (Figure 3).

   
   Figure 3. CreditApprovalClient content
   
   

   The Web project contains the JSP that calls the SCA component (creditApprovalClient.jsp), and the form-based login page (login.html).

7. Double-click the deployment descriptor of the CreditApprovalClient Web project, and examine the contents of the Security tab (Figure 4).

   Three roles are defined (manager, nonManager and delegate). There is also an access security constraint on the JSP. All users that are mapped to one of these roles are authorized to access the JSP.

   
   Figure 4. Security tab
   
   

Back to top

Defining the security permission on the SCA component

Next we will define the security permission for the CreditApproval SCA component. Only users with the manager role will be authorized to access the SCA component.

1. Return to the Business Integration perspective.

2. Double-click the CreditApprovalSCAModule module.

3. Click the CreditApproval component.

4. Go to the Properties view, click Details and switch to the Qualifiers tab.

   The Interfaces entry is selected. You can apply all interface qualifiers to three levels of a component :

   • For all of its interfaces
   • For an individual interface
   • For an individual operation of an interface

   The qualifier of the operation overrides the qualifier of the interface, and the qualifier of the interface overrides the qualifiers of all the interfaces for a component. Here, we have only one operation and interface, so you can define the qualifier at any level.

5. Click the Add button to display the qualities of service that are available.

6. Select Security permission and click OK.

7. Select the Security permission qualifier, and in the Role field enter manager (Figure 5).

   
   Figure 5. Qualifiers tab
   
   

8. Save and close the module.

Back to top

Defining the security role mapping

Next we need to map users to the manager nonManager and delegate roles we have defined. We define this mapping in the deployment descriptor of the enterprise application. Our file contains predefined mappings, so you need to replace the user codes with your own user codes.

1. Return to the J2EE perspective.

2. In the Project Explorer view, expand Enterprise Applications and the CreditApprovalSCAModuleApp application.

3. Double-click the CreditApprovalSCAModuleApp deployment descriptor, and switch to the Security tab.

4. Select the manager role (Figure 6).

   
   Figure 6. Enterprise application security tab
   
   

5. Select the bcp user, click on the Edit... button, and replace the value with a valid user of your operating system.

6. In the same way, modify the db2admin user mapped to the nonManager role, and the bruno user mapped to the delegate role.

7. Save and close the editor.

Back to top

Setting global security on the WebSphere Process Server

We will use the WebSphere Process Server Test Environment to test the sample. You need to set security with the administration console, and modify some default parameters set during the Test Environment installation. In this sample, we will configure the security for use with the Local OS user registry. Of course, you can also use a custom registry or LDAP.

1. Switch to the J2EE perspective.

2. On the Servers tab, right-click on the WebSphere Process Server and select Start.

3. When the server starts, right-click on it and select Run administrative console.

Modifying the J2C Authentication data

During the installation of the test environment, some J2C Authentication data entries were created with a default user. You need to change them to one of your valid users, especially for the alias used by SCA to login to a secured SIBus.

1. Log in, expand the Security entry and select Global security.

2. In the Authentication entry, expand Jaas Configuration and click J2C Authentication data.

3. You have to change all the aliases containing the wid user and replace them with your user (Figure 7).

   
   Figure 7. J2C Authentication data entries
   
   

Setting the global security

1. After modifying all the entries, return to the Global security panel.

2. Check the Enable global security property, unselect the Enforce Java 2 security property, and click OK.

3. On the Local OS user registry panel, enter a valid user and password, and then click OK.

4. Save your changes, logout from the Adminstration console and stop the server.

Modifying the server configuration

1. On the Servers tab, double-click on the server.

2. Expand Security, check Security is enabled on this server and enter a valid user and password.

3. On the Server connection type and admin port panel, select SOAP to ensure that the server starts correctly (Figure 8).

   
   Figure 8. Server configuration
   
   

4. Save and close the editor.

Back to top

Testing the security permission

1. Right-click on the server and select Start.

2. When the server starts, right-click on it and select Add and remove projects....

3. From the list, select the CreditApprovalSCAModuleApp application, and click the Add button. Click Finish and wait until deployment completes.

4. Expand Dynamic Web Projects, CreditApprovalClient, and Webcontent.

5. Right-click creditApprovalClient.jsp and select Run - Run on Server...

6. Select WebSphere Process Server and click Finish.

7. The login page displays. Enter the user code with the manager role and its password (Figure 9).

   
   Figure 9. Login page
   
   

8. On the next page, enter a value in the First Name and Last Name fields, enter 1 in the Customer Id field, and click the SubmitCreditApp button.

9. Since the SCA component is authorized for users with the manager role, the page displays the credit result (Figure 10).

   
   Figure 10. Result page
   
   

10. Now that you're connected, close the browser, restart the server and run creditApprovalClient.jsp by signing in this time with the nonManager user.

11. For this user, access to the SCA component is not authorized and so an error message displays.

    In the sample, the exception thrown by the SCA service runtime is caught by the JSP, and the exception message is displayed on the page (Figure 11).

    
    Figure 11. Access not authorized
    
    

12. Close the Web browser and stop the server.

Back to top

Defining the security identity

The security identity of a SCA component is similar to the EJB run-as delegation policy. Normally the implementation code of the SCA component is executed with the caller identity. In our sample, the caller is the JSP page. If you look at the result page (Figure 10), you notice that we display the Run-As user, that is the user executing the Java implementation code of the SCA component (CreditApprovalImpl.java).

But you can modify this default behaviour and delegate all methods of the component to run as a member of a specific security role. You define this specific role at the implementation level of the SCA component.

After that, during the deployment, you have to assign a real user that is a member of the specified security role.

To get the Run-As user code in the Java implementation, we use the JAAS Subject and the public credentials created when a user authenticates to WebSphere Process Server. Listing 1 shows the Java code used to retrieve the Run-As user.

				try {
	WSCredentialImpl pubCred = null;
	Subject sujetWS = WSSubject.getRunAsSubject();
	Set set = sujetWS.getPublicCredentials();
	if (!set.isEmpty()) {
			pubCred = (WSCredentialImpl) set.iterator().next();
	}
	creditRating.setString("customerId", creditApplication
				.getString("customerId")
				+ " Run-As user : " + pubCred.getSecurityName());
} catch (Exception e) {
}

Defining the security identity at the implementation level

1. In the Business Integration perspective, double-click the CreditApprovalSCAModule module.

2. Click on the CreditApproval component.

3. Go to the Properties view, click Impementation, and switch to the Qualifiers tab.

4. Click the Add button to display the qualities of service available.

5. Select Security identity and click OK.

6. Select the Security identity qualifier, and in the Privilege field enter delegate (Figure 12).

   
   Figure 12. Security identity
   
   

7. Save and close the module.

You use SCDL to define security permission and identity. SCDL definitions are stored across several files, but the security elements are stored with the interface and the implementation definition in a file called CreditApplication.component

To examine the content of this file (Figure 13), in the Business Integration perspective, from the Window menu, select Show View - Physical Resources. Expand CreditApprovalSCAModule.

Assigning a user to the security identity

Users can only be mapped to the security identity at deployment time, using the Administration console. For that, with the current version, you have to deploy the application from an ear file.

1. Switch to the J2EE perspective.

2. From the File menu, select Export.... Select EAR file and click the Next button.

3. Select the CreditApprovalSCAModuleApp EAR project and a destination file. Click Finish.

4. On the Servers tab, start the WebSphere Process Server.

5. Right-click on the WebSphere Process Server and select Run administrative console.

6. Log in, and in the Applications entry, select Enterprise Applications.

7. Select CreditApprovalSCAModuleApp and click Stop.

8. Select CreditApprovalSCAModuleApp and click Uninstall. Click OK.

9. Click Install, then click the Browse button. Select the ear file you saved before and click Next, and again Next.

10. Click Step 7: Map RunAs roles to users.

11. Check the delegate role, and enter the user code and password mapped to the delegate role. Click Apply (Figure 14).

    
    Figure 14. Map RunAs roles to users
    
    

12. Click Next, then Next and Finish.

13. Save to the master configuration. If there are save conflicts, select fOverwrite for all items .

14. From the Applications menu, select SCA modules.

15. Select CreditApprovalSCAModule and click Start.

Back to top

Testing the security identity

1. In the J2EE perspective, expand Dynamic Web Projects, CreditApprovalClient, Webcontent.

2. Right-click creditApprovalClient.jsp and select Run - Run on Server...

3. Select the WebSphere Process Server and click on Finish.

4. The login page displays. Enter the user code with the manager role and its password.

5. On the next page, enter a value in the First Name and Last Name fields, enter 1 in the Customer Id field, and click the button

6. The page displays the user with the delegate role as the Run-As user (Figure 15). Notice that you can choose, for the security identity, a role not authorized to access the SCA component.

   
   Figure 15. RunAs Result page
   
   

Back to top

Conclusion

Quality of Service is an important feature for SCA, and security is part of the available QoS qualifiers. This article has introduced the two security qualifiers of the SCA components (the security permission and the security identity) and has explored how you can define and use these qualifiers with WebSphere Integration Developer 6.0.1.

Back to top

Acknowledgments

I would like to thank Jeff Brent and Kevin Griffith for their technical review of this document.

Back to top

Download

Description	Name	Size	Download method
Sample SCA application	creditapproval.zip	29KB	FTP|HTTP

Information about download methods

Resources

Learn

• "Service Component Architecture" (developerWorks, November 2005) lists the SCA specification and related material.
  
  
• "Building SOA solutions with the Service Component Architecture -- Part 1" (developerWorks, October 2005) gives you an introduction to SCA and a walk through an example built with WebSphere Integration Developer.
  
  
• "Building SOA solutions with the Service Component Architecture -- Part 2" (developerWorks, December 2005) examines references and wires in the context of assembling SCA components with WebSphere Integration Developer and has a good introduction to QoS qualifiers.
  
  
• "Get started with WebSphere Integration Developer" (developerWorks, December 2005) helps you to develop a sample application that uses a service-oriented architecture.
  
  

Get products and technologies

• Build your next development project with IBM trial software, available for download directly from developerWorks.
  
  

About the author

Bruno Charpentier is a Software Engineer at IBM's ISSW Paris Lab. He has been focusing on business integration within WebSphere Business Integration Server Foundation and WebSphere Process Server, WebSphere security and DB2. He helps European customers integrate IBM products and technologies.

Comments

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• About the sample application
• Importing the sample
• Defining the security roles
• Defining the security permission on the SCA component
• Defining the security role mapping
• Setting global security on the WebSphere Process Server
• Testing the security permission
• Defining the security identity
• Testing the security identity
• Conclusion
• Acknowledgments
• Download
• Resources
• About the author
• Comments

Next steps from IBM

• Try: WebSphere Integration Developer (in the SOA Sandbox: Connect)
• Demo: Process automation, adoption pattern
• Webcast: Develop innovative applications efficiently using the right application foundation in today's economy
• Briefing: WebSphere flexible business processes
• Buy: WebSphere Integration Developer (in the SOA Sandbox: Connect)

My developerWorks community

Dig deeper into WebSphere on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers