Chapter 7. Using Web services 185
Security requirements
To internally expose an EIS to an organization, we need the following service
features, which we call the
communication level:
???? Identification
: the party accessing the resource is able to identify itself to the
system.
???? Authentication: a procedure to verify the identity of the accessing party.
???? Authorization: a set of transactions that the authenticated party is allowed to
perform.
???? Integrity: the information is not changed on its way.
???? Confidentiality: nobody is able to read the information about its way.
The partner communication can be more sensitive, so we need to achieve a
deeper level security, which we call
absolute proof level:
???? Auditing: all transactions are recorded so that problems can be analyzed after
the fact.
???? Non-repudiation: both parties are able to provide legal proof to a third party
that the sender did send the information and that the receiver received the
identical information.
Security solutions
There are two possible solutions for the Web services to obtain communication
level security:
???? A secure transport layer as HTTPS
???? WS-Security, a standard specification to address the first level of security for
Web services that was finalized on March 2004.
An interesting benefit of the WS-Security technology is the ability to work at
message level, providing more flexibility. Despite the fact that WS-Security is
inherently better than the HTTPS solution, the recent finalization of the
specification makes it difficult to find consolidated implementations. Because this
technology is still so new and not always supported by all partners in an
interaction, it can cause problems for the interoperability which is the most
important feature of Web services technology. We suggest that, at this time, it is
better to use HTTPS. However, you might want to learn more about WS-Security,
because it will soon become a widespread standard.
The absolute proof level was identified, and there are some overcoming
standards that will address it. Today, it is only possible to look for a custom
solution.
186 Managing Information Access to an EIS Using J2EE and Services Oriented Architecture
Security at work
In an HTTPS link, there are two parties that need to be configured: the client and
the server. When a process works as a client of external HTTPS Web service, it
needs the mediation of the Web Services Gateway which acts as a HTTPS
client. You can find details on how to configure the Web Services Gateway
security binding in the WebSphere Infocenter:
http://publib.boulder.ibm.com/infocenter/ws51help/topic/
com.ibm.websphere.nd.doc/info/ae/ae/twsg_security_wss_gwbind.html
To understand the information in this section, you need a good knowledge of
J2EE security and of how WebSphere security works. For a list of more
reference material, see 7.6, “Further information” on page 195.
The first step to secure a Web service is to enable WebSphere global security. In
WebSphere Studio Application Developer Integration Edition, you can achieve
global security through the server configuration editor by following these steps:
1. In the Servers view, double-click the server instance.
2. Select the Security tab.
3. Select Enable security check box.
4. Insert an administrative user for Server ID, Server Password, and Confirmed
password (Figure 7-8). If you are in a domain, remember to use the domain
prefix (for example, DOMAINAdmin).
Figure 7-8 Server configuration editor: Security options tab
Chapter 7. Using Web services 187
To protect access to the Web service, you need to configure J2EE security. You
need to create a security role with the correct rights to interact with Web services.
In WebSphere Studio Application Developer Integration Edition:
1. Look for the J2EE Hierarchy view. It is in the Business Integration perspective
or in the J2EE perspective)
2. Expand the Web Modules branch and look for the Web project where your
Web services are deployed. In the case of a BPEL process, the default Web
project name follows the convention of service project name followed by the
Web suffix.
3. Double-click the Web project to open the Web module deploy descriptor.
4. Select the Security tab.
5. Click Add to add a security role. Give the role a name (for example,
WebServicesClient).
6. On the top of the panel, there are two tabs: Security Roles and Security
Constraints. Select Security Constraints (Figure 7-9 on page 188).
Note: The user that runs WebSphere Studio Application Developer Integration
Edition needs the privileges called Act as part of the operating system and log
on as a service.
188 Managing Information Access to an EIS Using J2EE and Services Oriented Architecture
Figure 7-9 Web module deployment descriptor editor: Security tab
7. In the Security Constraints panel, there are two columns. In the left column
under the Security Constraints section, click Add.
8. In the Web Resource Collections section, select the new item, then click Edit.
9. A new dialog box opens. In name field, enter services, and in the HTTP
Methods box, select GET and POST. Click Add.
10.In the URL Patterns box a new item appears. Click the new URL pattern to
edit it and enter /services/*. Then, click OK to close the dialog box. This
URL pattern includes all the Web services available for the Web module. It is
possible change the pattern to create a selective rule.
11.Look for the Authorized Role section. You might need scroll down the window.
Click Edit to open a dialog box that lets you select the role involved in the
security constraint. Select WebServicesClient and click OK to close the
dialog box.
12.Look for the User Data Constraint section. You might need scroll down the
window. In the Type field select Confidential.
13.Save the deployment descriptor and close the editor.
Chapter 7. Using Web services 189
The previous steps defined a role which has the right to access Web services.
Now, you need to define who can play the WebServicesClient role. Notice that
the following configuration should be changed during deployment procedures to
meet the security policy of the target environment.
1. In the J2EE hierarchy view, find the EAR file that contains the Web services
module and double select it.
2. Select the Security tab (see Figure 7-10).
Figure 7-10 EAR Deployment Descriptor Editor: Security tab
3. Click Gather... to gather the security roles defined in the modules owned by
the EAR project.
4. When the WebServicesClient role has appeared, select it and select All
authenticated users under the WebSphere Bindings section. With this
selection, all valid users in the WebSphere registry are authorized to use the
Web service.
5. Save the deployment descriptor and close the editor.
Now, the Web services are secured using the HTTPS protocol, and the users are
authenticated against the WebSphere registry.
7.5.3 Transactions
One of the most important concepts in information technology is the transaction
concept. Broadly speaking, the transaction concept is the basic capability of a
system to execute a set of operations in an assured and safe manner.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.