Security

Security requirements for automation solutions are nothing new to the world of IT. Similarly, service-oriented applications need to be outfitted to handle many of the traditional security demands of protecting information and ensuring that access to logic is only granted to those permitted.

However, the SOAP messaging communications framework, upon which contemporary SOA is built, emphasizes particular aspects of security that need to be accommodated by a security framework designed specifically for Web services.

Sidebar 7 1 Sidebar

A list of security specifications that may be used as part of SOA. For more information regarding these specifications, visit: www.specifications.ws.

• WS-Security
• WS-SecurityPolicy
• WS-Trust
• WS-SecureConversation
• WS-Federation
• Extensible Access Control Markup Language (XACML)
• Extensible Rights Markup Language (XrML)
• XML Key Management (XKMS)
• XML-Signature
• XML-Encryption
• Security Assertion Markup Language (SAML)
• .NET Passport
• Secure Sockets Layer (SSL)
• WS-I Basic Security Profile

A family of security extensions parented by the WS-Security specification comprise such a framework, further broadened by a series of supplementary specifications with specialized feature sets. Sidebar 7.1 provides a list of current security-related specifications. While we clearly cannot discuss concepts for all of them, it is worth spending some time looking at the basic functions performed by the following three core specifications:

• WS-Security
• XML-Signature
• XML-Encryption

Additionally, we'll briefly explore the fundamental concepts behind single sign-on, a form of centralized security that complements these WS-Security extensions.

Before we begin, it is worth noting that this section organizes security concepts as they pertain to and support the following five common security requirements: identification, authentication, authorization, confidentiality, and integrity.

Note

For an overview of the core language elements from the WS-Security, XML-Encryption, and XML-Signature languages, see the WS-Security language basics section in Chapter 17.

In Plain English

Toward the end of a working day, Jim leaves the car wash early. He has an appointment with someone selling a used power washer that we are interested in buying. Before he can meet this person, Jim must stop by the bank to withdraw a fair amount of money for the potential purchase (the seller has stated that this must be a cash sale). I also ask Jim to do me a favor and pick up a package that's waiting for me at a postal outlet near the bank.

Jim agrees and proceeds on his errand trip. Upon entering the bank, Jim must fill out a withdrawal slip on which he is asked to identify himself by writing his full name. Jim then comes face-to-face with a bank teller who, upon seeing that he wants to make a withdrawal, requests that he produce a bank card and one piece of photo ID.

Jim shows the teller his business account card and his driver's license, which the teller subsequently verifies. After it is confirmed that Jim is who he stated he was on the withdrawal slip, the teller asks Jim to enter his bank card pass code. This further ensures that he is an individual allowed to make this type of withdrawal.

With the money in hand, Jim proceeds to the postal outlet. There he presents the notification card I received in the mail indicating that a parcel is being held for me. Jim states his name (and therefore does not claim to be the same person whose name is on the notification card) and also states that he is here to pick up the parcel for someone else. The employee at the postal outlet asks Jim for ID, so he pulls out his driver's license again. Upon reviewing the information on the driver's license and the notification card, the employee informs Jim that he cannot pick up this package.

Jim's experience at the bank required that he go through three levels of clearance: identification (withdrawal slip), authentication (bank card and photo ID), and authorization (pass code and bank record). While no security was really applied to the identification part of this process, it did kick off the remaining two security phases for which Jim satisfied requirements (and for which reason he subsequently received the requested money).

At the post office, though, Jim did not pass the authorization stage. Only individuals that share the last name or reside at the same address of the person identified on the notification card are allowed to pick up deliveries on their behalf. Jim's claimed identity was authenticated by the driver's license, but because Jim is not a relative of mine and does not live at the same address as I do, he did not meet the requirement that would have authorized him to pick up the parcel.

 

7.6.1. Identification, authentication, and authorization

For a service requestor to access a secured service provider, it must first provide information that expresses its origin or owner. This is referred to as making a claim (Figure 7.27). Claims are represented by identification information stored in the SOAP header. WS-Security establishes a standardized header block that stores this information, at which point it is referred to as a token.

Figure 7.27. An identity is a claim made regarding the origin of a message.

Authentication requires that a message being delivered to a recipient prove that the message is in fact from the sender that it claims to be (Figure 7.28). In other words, the service must provide proof that its claimed identity is true.

Figure 7.28. Authentication means proving an identity.

Once authenticated, the recipient of a message may need to determine what the requestor is allowed to do. This is called authorization (Figure 7.29).

Figure 7.29. Authorization means determining to what extent authentication applies.

 

7.6.2. Single sign-on

A challenge facing the enablement of authentication and authorization within SOA is propagating the authentication and authorization information for a service requestor across multiple services behind the initial service provider. Because services are autonomous and independent from each other, a mechanism is required to persist the security context established after a requestor has been authenticated. Otherwise, the requestor would need to re-authenticate itself with every subsequent request.

The concept of single sign-on addresses this issue. The use of a single sign-on technology allows a service requestor to be authenticated once and then have its security context information shared with other services that the requestor may then access without further authentication.

There are three primary extensions that support the implementation of the single sign-on concept:

• SAML (Security Assertion Markup Language)
• .NET Passport
• XACML (XML Access Control Markup Language)

As an example of a single sign-on technology that supports centralized authentication and authorization, let's briefly discuss some fundamental concepts provided by SAML.

SAML implements a single sign-on system in which the point of contact for a service requestor can also act as an issuing authority. This permits the underlying logic of that service not only to authenticate and authorize the service requestor, but also to assure the other services that the service requestor has attained this level of clearance.

Other services that the service requestor contacts, therefore, do not need to perform authentication and authorization steps. Instead, upon receiving a request, they simply contact the issuing authority to ask for the authentication and authorization clearance it originally obtained. The issuing authority provides this information in the form of assertions that communicate the security details. (The two types of assertions that contain authentication and authorization information are simply called authentication assertions and authorization assertions.)

In Figure 7.30 we illustrate some of the mechanics behind SAML.

Figure 7.30. A basic message exchange demonstrating single sign-on (in this case, as implemented by SAML).

 

7.6.3. Confidentiality and integrity

Confidentiality is concerned with protecting the privacy of the message contents (Figure 7.31). A message is considered to have remained confidential if no service or agent in its message path not authorized to do so viewed its contents.

Figure 7.31. Confidentiality means that the privacy of the message has been protected throughout its message path.

Integrity ensures that a message has not been altered since its departure from the original sender (Figure 7.32). This guarantees that the state of the message contents remained intact from the time of transmission to the point of delivery.

Figure 7.32. Integrity means ensuring that a message's contents have not changed during transmission.

 

7.6.4. Transport-level security and message-level security

The type of technology used to protect a message determines the extent to which the message remains protected while making its way through its message path. Secure Sockets Layer (SSL), for example, is a very popular means of securing the HTTP channel upon which requests and responses are transmitted. However, within a Web services-based communications framework, it can only protect a message during the transmission between service endpoints. Hence, SSL only affords us transport-level security (Figure 7.33).

Figure 7.33. Transport-level security only protects the message during transit between service endpoints.

If, for example, a service intermediary takes possession of a message, it still may have the ability to alter its contents. To ensure that a message is fully protected along its entire message path, message-level security is required (Figure 7.34). In this case, security measures are applied to the message itself (not to the transport channel on which the message travels). Now, regardless of where the message may travel, the security measures applied go with it.

Figure 7.34. Message-level security guarantees end-to-end message protection.

 

7.6.5. Encryption and digital signatures

Message-level confidentiality for an XML-based messaging format, such as SOAP, can be realized through the use of specifications that comprise the WS-Security framework. In this section we focus on XML-Encryption and XML-Signature, two of the more important WS-Security extensions that provide security controls that ensure the confidentiality and integrity of a message.

XML-Encryption, an encryption technology designed for use with XML, is a cornerstone part of the WS-Security framework. It provides features with which encryption can be applied to an entire message or only to specific parts of the message (such as the password).

To ensure message integrity, a technology is required that is capable of verifying that the message received by a service is authentic in that it has not been altered in any manner since it first was sent. XML-Signature provides features that allow for an XML document to be accompanied by a special algorithm-driven piece of information that represents a digital signature. This signature is tied to the content of the document so that verification of the signature by the receiving service only will succeed if the content has remained unaltered since it first was sent.

Note

Digital signatures also support the concept of non-repudiation, which can prove that a message containing a (usually legally binding) document was sent by a specific requestor and delivered to a specific provider.

As illustrated in Figure 7.35, XML-Encryption can be applied to parts of a SOAP header, as well as the contents of the SOAP body. When signing a document, the XML-Signature can reside in the SOAP header.

Figure 7.35. A digitally signed SOAP message containing encrypted data.

Note

Both encryption and digital signature technologies rely on the use of keys. These are special values used to unlock the algorithm upon which encryption and digital signatures are based. Shared keys are typically used by encryption technologies and require that both the sender and receiver of a message use the same key. Public/private key pairs are commonly used by digital signature technologies, where the message sender signs the document with a key that is different from the one used by the recipient. (One of the keys is public, but the other is private.)

 

7.6.6. Security and SOA

Message-level security can clearly become a core component of service-oriented solutions. Security measures can be layered over any message transmissions to either protect the message content or the message recipient. The WS-Security framework and its accompanying specifications therefore fulfill fundamental QoS requirements that enable enterprises to:

• utilize service-oriented solutions for the processing of sensitive and private data
• restrict service access as required

As shown in Figure 7.36, the security framework provided by WS-Security also makes use of the WS-Policy framework explained earlier (a separate specification called WS-SecurityPolicy provides a series of supporting policy assertions).

Figure 7.36. Security, as it relates to policies, SOAP messages, and Web services.

Case Study

TLS has a message-level security policy that applies to any business documents sent to its B2B solution.

The policy has the following rules:

• Any dollar values residing in documents sent via SOAP messages must be encrypted.
• Any invoice submitted to TLS with a total dollar value of over $30,000 must also be digitally signed.

To comply with this policy, RailCo is required to apply XML-Encryption to the parts of the invoice message sent by the Invoice Submission Service that contain monetary values.

It further embeds a business rule into the Invoice Submission Service's underlying logic that checks for invoice totals that exceed the $30,000 mark. Those that do, have their corresponding SOAP message documents digitally signed using XML-Signature.

SUMMARY OF KEY POINTS

• Security within SOA is a multi-faceted subject matter that encompasses the feature set of numerous specifications. The WS-Security framework governs a subset of these specifications, and establishes a cohesive and composable security architecture.
• The primary aspects of security addressed by these specifications are identification, authentication, authorization, integrity, and confidentiality, as well as non-repudiation.
• Two primary technologies for preserving the integrity and confidentiality of XML documents are XML-Encryption and XML-Signature.