Let’s begin by defining some core security services that are fundamental to end-to-end application security across multitier applications. They are:
Authentication. Verifies that principals (human users, registered system entities, and components) are who they claim to be. The result of authentication is a set of credentials, which describes the attributes (for example, identity, role, group, and clearance) that may be associated with the authenticated principal. Authorization. Grants permission for principals to access resources, providing
the basis for access control, which enforces restrictions of access to prevent unauthorized use. Access controls ensure that only authorized principals may modify resources and that resource contents are disclosed only to authorized principals.
Cryptography. Provides cryptographic algorithms and protocols for protecting data and messages from disclosure or modification. Encryption provides confi- dentiality by encoding data into an unintelligible form with a reversible algo- rithm, which allows the holder of the decryption key(s) to decode the encrypted data. A digital signature provides integrity by applying cryptography to ensure that data is authentic and has not been modified during storage or transmission. Accountability. Ensures that principals are accountable for their actions. Security auditing provides a record of security-relevant events and permits the monitor- ing of a principal’s actions in a system. Nonrepudiation provides irrefutable proof of data origin or receipt.
Security administration. Defines the security policy maintenance life cycle embodied in user profiles, authentication, authorization, and accountability mechanisms as well as other data relevant to the security framework.
All security services must be trustworthyand provided with adequate assurance. That is, there must be confidence that security services have been implemented cor- rectly, reliably, and without relying on the secrecy of proprietary mechanisms. We will discuss the concept of building trustworthy security architectures in Chapter 12.
Moreover, all of the critical security services must be provided on an end-to-end basis. Each Web Services transaction must be traceable from its origin through to its fulfillment, maintaining consistent security across processing tiers and domains. This is no simple feat when one considers the potential diversity of applications, systems, and business processes involved in a typical Web Services transaction—and when you consider that these distributed systems may be managed in very different ways.
Access to enterprise Web Services search and discovery mechanisms, such as UDDI, also needs to be managed. While much of the Web Service information listed in a Web Services directory is appropriate for all the applications or developers in the enterprise, it is also important to provide a robust security mechanism for user authentication and authorization. This facility is used to limit the set of users who may either access or update Web Services directory entries, and can be managed at a central point.
Web Services security must be flexible enough to identify all participants in a trans- action based on a variety of authentication mechanisms. Web Services security must also be able to establish a user security contextat each processing tier. (A user security context is the combination of a user’s identity and security-relevant attributes.) Sophis- ticated authorization policies using the security context will be needed. The Web Ser- vices security facility must perform auditing so that an accurate record of the steps that occurred to fulfill a request and the identities of the responsible parties is maintained. Finally, in order to achieve end-to-end security, the Web Services security must pass the security context between domains or tiers, thereby establishing a consistent secu- rity context for the entire transaction. Without this consistent security context, there is no way to attribute actions to the right individual later. Passing the user security con- text also eliminates the need for a user to reauthenticate each time his or her request crosses from one tier to another. Thus, an additional benefit of the seamless integration of security with Web Services is to provide single sign-on (SSO), even across organiza- tions using different security technologies.
Web Services require the ability to use different authentication mechanisms, establish a security context, implement sophisticated authorization policies, and attribute actions to the proper individuals. Consistent security must be maintained across processing tiers and domains in the Web Services world. Flexible ways to create, pass, and establish security contexts are needed for end-to-end security in a Web Services environment.
Providing Security for Web Services
Given the diverse nature of these distributed environments, it is not surprising that Web Services security efforts to date have taken a “patchwork” approach. This patch- work may include a range of existing, standalone Web security mechanisms, together with operating system security (domain logins), communications security (SSL), appli- cations environment security (J2EE, COM+, .NET, or CORBA), and SSO (Netegrity SiteMinder, IBM/Tivoli Policy Director, or others) solutions. Even electronic mail sys- tems can support Web Services. The problem is that each of these solutions has evolved to solve a specific problem within a single tier or domain. While there have been attempts to extend these solutions beyond their original scope, the results have not been very rewarding.
Historically, ad hoc solutions have evolved informally to handle multitiered secu- rity. This is especially true in going from one processing tier to another. For instance, user identities can be passed from a Web Server to a business application as HTTP header variables. This is generally done without encryption “in the clear,” based on a trust relationship between the Web server and the business application. Once at the application, programmatic security is used for authorization. It is up to the application developer to decide on the authorization policy that must be enforced and to imple- ment it correctly. Infrastructure-provided security services are not generally used. Informal solutions such as these tend to weaken overall system security by making it discretionary and leaving the strength of the implementation up to the skill of the application programmer, who typically isn’t experienced implementing security.
How have Web Services affected this security picture? First, interactions are more complex and take place between more diverse environments. When interactions were
limited to browsers alone, they required only a transfer of data, and there were still many security problems. Widespread use of Web Services means that direct invocation of services can be performed over HTTP. Web Services are used to invoke distributed procedure calls. Moreover, these requests can come from different domains, from users and servers we know relatively little about.
Although this book concentrates mainly on the delivery of Web Services via HTTP, they could be delivered by other protocols as well, because Web Services are based on XML-based documents. For example, email or message systems can transport Web Services requests and responses. These options make Web Services an even more flex- ible way of delivering processing capabilities.
Finally, in traditional Web interactions, the actual user is at the other end of a virtual connection. While HTTP itself is stateless, Web SSO systems go to great lengths to cre- ate and maintain the notion of a session that maintains a secure connection between the user and Web server. In such sessions, users are available to authenticate them- selves using passwords, certificates, or other mechanisms. However, with Web Ser- vices, the originator of the request may not be available for authentication on an interactive basis. For instance, the originator may choose to authenticate the request by signing it. The system must be flexible enough to use identity derived in different ways to make access control decisions.
The following diagram (Figure 1.2) illustrates new and existing security mecha- nisms for securing Web Services at different security tiers. For instance, where access to the Web Service is through a Web Server, Secure Sockets Layer (SSL) and Web SSO can be used. At the application level, Security Assertion Markup Language (SAML) can be used to support authentication and authorization across domains. Finally, access to a mainframe is needed to complete the request, and a mainframe authentication system is in place.
Existing security solutions have tended to concentrate only on one tier because they evolved to solve a single-tier security problem. As the processing model has changed to incorporate Web Services, so has the nature of the security problem. While new solu- tions have been devised to address the Web Services model, existing security solutions have not been replaced as system implementers have tried to leverage existing invest- ments. The challenge lies in weaving together this patchwork of standalone solutions into an integrated, end-to-end security solution.
Figure 1.2 Example of Web Service security implementation. Perimeter Security
HTTP daemon/ Web Server Web Single Sign-on
SSL
Lower Layer Protocols
Mid-Tier Security J2EE/CORBA .NET/COM+ Application Security S/MIME SOAP/WS-Security/SAML
Back Office Security
Mainframe DBMS Security
ACF2/RACF/Top Secret DSIG