We’ll now see how authorization for eBusiness can be conducted.
■■ ePortal wants to ensure that eBuyer is entitled to use the services it has requested.
eBuyer’s signature on the message will authenticate it as the creator of the SOAP message. Message signatures must be handled explicitly by an application level func- tion. The application must include code to parse the SOAP message, identify the sig- nature, verify the signature, and verify that the signer is an entity authorized to send SOAP messages to ePortal. In addition to the signing code, this requires that eBusiness be part of some PKI so that it can be certain that the certificate is valid and hasn’t been revoked. It must also verify that the signer of ePortal’s certificate is trusted to vouch for ePortal’s public key. Lastly, the application must either maintain a list for itself of ePor- tal’s privileges or use some authorization engine to render the final decision as to whether eBuyer is entitled to issue this message.
eBusiness wants to ensure that the initiator is entitled to request the services on the information. eBusiness must extract the SAML assertion from the SOAP header. The assertion includes information about the initiator’s authentication at ePortal or its attributes at ePortal. The specific contents are determined by negotiations between ePortal and eBusiness. The assertion itself may be signed. In which case, the signature on the assertion and the certificate of the signer need to be verified. If the assertion is an authentication assertion, we will assume that the authorization decision is based on the initiator’s identity. If there are attributes, then the authorization will be based on the initiator’s attributes. As with verifying ePortal’s authorization, Joe’s authorization will be performed by application layer software. This software will determine whether Joe’s attributes in ePortal need to be converted to attributes meaningful to eBusiness. We know that as a gold customer in ePortal, Joe will need a purchasing limit of $50,000. Finally, with the help of some authorization engine, the application will decide if Joe is authorized to make the purchase.
Summary
Web Services are new, and there are very few solid guidelines concerning security. Best practice has not been determined. The other complicating factor is that there are so many different ways Web Services can be implemented that it is difficult to identify common patterns to use to formulate guidelines for security. What we’ve tried to do is explain how to analyze specific Web Services security needs and determine how to address those needs.
In this chapter, we’ve identified three critical aspects of securing Web Services: authentication, message protection, and authorization. We discussed specific require- ments for each, solutions that can address the requirements, factors affecting the choice of a solution, and the proposed security solution for ePortal and eBusiness.
In many cases, we decided to utilize document-oriented solutions. This was because they are tailored to XML documents and offer the most flexibility. However, a connec- tion-oriented technique such as SSL is widely implemented and can be utilized easily. It should be given very serious consideration before another approach is adopted.
While we analyzed technical solutions, the reader should be aware that under- standing business practice is critical to securing Web Services. The service provider and the service subscriber must agree on the relationship of various entities to the Web Services transaction, how each entity can be authenticated, how needed security infor- mation is passed between the two, the meanings of any digital signatures, if any, and other relationships.
The next two chapters on .NET and J2EE describe how to use some specific tech- nologies to implement the measures discussed in this chapter.
157
Middleware technologies are the software foundation of modern enterprise computing systems, which process the requests coming through Web Services gateways. Under- standing the middleware security mechanisms that are available to you is the first step toward achieving end-to-end security for applications exposed as Web Services. This chapter covers the security mechanisms in the mainstream middleware technologies: Common Object Request Broker Architecture (CORBA), Component Object Model (COM+), .NET, and Java 2 Platform, Enterprise Edition (J2EE). If you are already famil- iar with middleware security, just skim through and move on to the next chapter.
We recommend that you read the entire chapter to understand the security mecha- nisms of other technologies. However, if you only use one technology, such as J2EE, or combine only a few distinct yet similar technologies, such as COM+ and .NET, feel free to skip the other technologies in this chapter—but focus on understanding the security of what you have. You should have a general understanding of the fundamentals of computer security before you tackle this chapter. For a good introduction to this sub- ject, we suggest: Amoroso (1994), Golmann (1999), and Russel (1991).
We will start with the main concepts of distributed system security and introduce you to necessary and common terms. This should give you a good basis with which to approach the security of any middleware technology, as well as what you need to iden- tify the similarities and differences between the security mechanisms of CORBA, COM+, .NET, and J2EE. Describing all the features of each of these modern and com- plex technologies would take multiple volumes. To avoid overwhelming you with huge amounts of information, we focus on the material essential for understanding the rest of