3R's in second-generation Web service paradigm
Before discussing what an access control list (ACL) is, how to set it up, and how to control its contents and entries, let's take a quick look at the second-generation Web service paradigm. Part 2 of this series describes the bidirectional processes between each application player in the paradigm:
- Broker
- Provider
- Client
This article explains it a bit further, showing how each player reads, writes, and/or executes (runs) a process in the paradigm. Figure 1 below is an illustration of a second-generation Web services paradigm.
Figure 1. Second-generation Web services paradigm
The paradigm shows how the application provider initiates the process of writing the application broker a request to find a Web service in the broker's repository, directory, or registry, such as the Universal Description, Discovery, and Integration (UDDI) of IBM®. If the broker successfully executes the request and discovers the Web service, it writes an alert to the client to confirm the discovery was successful. After receiving the alert, the client reads it. If broker cannot find the Web service, it sends an alert to the client that the discovery attempt failed.
After reading the broker's alert on successful discovery, the client writes a message to the provider that it is attempting to bind the Web service. The provider reads it and then determines whether additional Web services are needed to complete the tasks of the originating Web service application. If so, the provider communicates with the client regarding what the next actions are that it should execute.
Almost at the same time, this provider writes to the broker a request to publish a Web service in the UDDI repository of IBM. If the broker successfully executes the request, the provider reads an alert from the broker confirming the successful publication of the Web service. Otherwise, the broker sends an alert that its attempt to publish failed.
While you can set file permissions for each player in the paradigm, the read (r), write (w), and execute (x) permission model is insufficient in a heterogeneous world of SOA of Web services, non-Web services, and Enterprise Application Integration (EAI) applications. To work around the limitations of the model, take a look at the ACLs. They are one of the Web services features that should be tested before a service is made public, as briefly discussed Part 2 of this series.
So what are ACLs? They come in two types on Linux and other Unix-related systems: access and default. Both are based on the 2003 edition of the IEEE Standard 1003.1 -- 2001 POSIX ® (see Resources). For both, the same set of permissions is available for each of the three user classes:
- User
- Group
- Other
Time limits can be set or modified to specify what days and hours the authorized users and groups can access certain files and directories.
With access ACLs, the administrators can gain more flexibility and better control over which users and groups can read, write, and execute files and directories. Savvy (and authorized) developers should log in as root to build, modify, archive, and restore ACLs.
Default ACLs are only applied to directories. An ACL defines the permissions that a newly created file or directory inherits from its parent directory. In this instance, default implies inheritance of permissions from a higher level directory or for its lower level counterpart. This means when you create a new directory inside a directory that already has a default ACL, the new directory inherits the default ACL both as its access ACL and its default ACL.
A developer in cooperation with an administrator can change user and group permissions in an ACL to test Web services in a heterogeneous SOA. Before releasing Web services to the public, the developers can specify or recommend how to change permissions to run them in a production environment. Each user or group permission is an ACL entry.
You must consider the maximum number of ACL entries a file system can hold for each Web service. For instance, IBM journaled file system (JFS) can have over 8,000, while EXT2 and EXT3 are limited to 32 entries and XFS can have up to 25 entries. In addition to basic user and group entries, an ACL includes extended entries:
- Named user
- Named group
- Mask
Figure 2 below is an example of a very simple ACL.
Figure 2. Masked entries
As you saw, the second and third lines are masked entries. The first masked entry is a named user entry with a different set of permissions.
System performance tends to be lower with multiple ACL entries, thus impacting the uptime availability guarantees in a SLA. To reduce the risk of performance slowdown, you should not use them on files in root, boot, usr and var partitions, or even the swap partitions. You should also test how well the system is performing in a non-production environment to ensure an ACL is properly executed with varying user and group permission entries.
You must ensure each player has the authorization to communicate in both directions. You cannot allow an unauthorized user to successfully access a control that only the administrators are authorized to use or even send an alert falsely verifying that the process was a success when it was not. You must consider an ACL for multiple users with varying permissions to a component of a Web service, or to the same or similar component of multiple Web services.
Keep in mind that multiple Web services rarely execute themselves. It takes high-level services in the SOA to orchestrate the execution of multiple services. EAI applications can execute themselves sometimes as the orchestra conductor of Web services (and non-Web services). For these reasons, consider a hierarchy of ACLs with the conductor at the root of the hierarchy.
Consider two clients in an ACL. Each has a set of permissions to write the broker a request to discover a Web service and read an alert from the broker on the discovery status. Client A is permitted to write a request to find the Web service in a certain category (such as travel), while Client B is allowed to write such a request in two or three categories (education, hotel reservation, and car rental, for example) but not the category assigned to client A. Clients A and B are also permitted to read an alert from the broker on the status of the Web service discovery attempt.
Assume you have two different UDDIs in the same ACL. Broker A is permitted to send standard alerts of one category (for example, brief description of the successful or failed discovery attempt) to Client A. Broker B is allowed to send digitally signed alerts of a different category (for example, verbose description) to Client B.
Likewise, Provider A has permission to send a request to Broker A to publish a Web service in certain categories and Broker B in other categories. Provider A communicates with Client A in one way and Client B in another way on what actions it should execute after receiving the request to bind the discovered Web Services.
Multiple ACL-based Web services
However, this ACL-based Web service is a small part of the much bigger SOA picture. As shown in Figure 3, one Web service can interact with other Web services (represented by small triangle objects), non-Web services (represented by small circles) and EAI applications (represented by small squares). As you will notice, small triangles, squares, and circles come in different colors, each of which has a meaning.
For instance, a small orange triangle pointing to the orange triangle with a heavy border line as the target object means the originating Web service in a short run is interacting with the long-running target service or application. It can also point to an EAI application that in turn interacts with a non-Web service or another EAI application. Just follow the arrows in the illustration to get a simple picture.
Figure 3. SOA architecture of ACL-based services and applications
The SLA should specify for each Web service the maximum number of ACL entries with uptime availability associated with interruption thresholds discussed in "Integrate Web services into EAI with a SLA guarantee". The maximum to be specified varies from one Web service to another depending on the type of permissions granted to users and groups in an ACL. As shown in Table 1, this variation should be listed in the SLA.
Table 1. SLA specification example
| Maximum entries | Uptime availability | Interruption threshold |
| 30 | 96.1% | 97.3% |
| 28 | 96.5% | 97.7% |
| 25 | 98.5% | 97.9% |
To maximize the effectiveness of ACLs while minimizing the number of entries, Web services and all other objects in the SOA should be firewalled. The administrator should have the flexibility to control traffic flows coming into and out of the firewalls without adversely impacting the SLA uptime guarantees.
Developers should address the issues of setting up, modifying, and controlling ACLs to multiple Web services in a heterogeneous SOA to achieve the acceptable levels of uptime availability in a SLA. They include the issues of specifying the maximum number of ACL entries for each Web service with SLA guarantees of uptime availability associated with interruption thresholds. The higher the system performance, the better the guarantee SLA gives on securing multiple services with ACLs.
- Get information on how to use SLAs in a Web services context from the other papers in this series:
- "Guarantee your Web service with a SLA" (developerWorks, April 2002)
- "Guarantee second-generation Web services applications with a SLA" (developerWorks, August 2004)
- "Integrate Web services into EAI with a SLA guarantee" (developerWorks, October 2004)
- "Firewall Web services with a SLA guarantee" (developerWorks, December 2004)
- "Localize Web services with a SLA guarantee" (developerWorks, January 2005)
- "Mitigate risk for vulnerability with a SLA guarantee" (developerWorks, January 2005)
- Learn more about PushToTest to test and monitor Web services.
- Read Judith M. Myerson's The Complete Book of Middleware, which focuses on the essential principles and priorities of system design and emphasizes the new requirements brought forward by the rise of e-commerce and distributed integrated systems.
- Get the business insight and the technical know-how to ensure successful systems integration by reading Enterprise Systems Integration, Second Edition.
- Publish your Web service or application in the IBM UDDI Version 2 registry, which features a graphical user interface and conformant APIs for public use. The IBM UDDI Version 3 beta registry is also available for testing.
- Find out more about POSIX ACLs and the USENIX 2003 Annual Technical Conference, FREENIX Track Proceedings.
- Explore and learn more about "Complex datatypes in SOAP-based Web services" when you build them from existing Java™ code (developerWorks, May 2001).
- Go into the nuts and bolts of developing a service-level agreement in this IBM Redbook for Domino administrators.
- Visit the Developer Bookstore for a comprehensive listing of technical books, including hundreds of Web services titles.
- Want more? The developerWorks SOA and Web services zone hosts hundreds of informative articles and introductory, intermediate, and advanced tutorials on how to develop Web services applications.
Judith M. Myerson is a systems architect and engineer. Her areas of interest include middleware technologies, enterprise-wide systems, database technologies, application development, network management, security, and project management. You can contact her at jmyerson@bellatlantic.net.
Table of contents
Next steps from IBM
WebSphere Portal can help your small and midsize business achieve better website security, along with faster time to value with easily deployable and customizable example Web sites.
- Try: Download a free trial version of IBM WebSphere Portal Express V6.1, which offers collaboration, document management, and secure Web content management.
- Article: This article provides an overview of the WebSphere Portal security architecture, including internet security, and secure connections between clients.
- Tutorial: This tutorial take you through the steps to develop and test your first portlet WebSphere Portal Test Environment.
- Demo: These demos show Web 2.0 features available today within WebSphere Portal, as well as several features planned for the future.
- Buy: IBM WebSphere Portal Express
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
