Jan. 13, 2011, 2:09 a.m.
posted by apollo
Two basic mechanisms are used to guard against security risks: signing and encrypting messages for data integrity and confidentiality, and checking associated ticket and token information for authentication and authorization. These mechanisms are often used in combination because a broad variety of risks must be taken into account.
As illustrated in Figure, WS-Security headers can be added to SOAP messages before they are sent to the service provider. The headers can include authentication, authorization, encryption, and signature so that the provider can validate the credentials of the requester before executing the service. Invalid credentials typically result in the return of an error message to the requester. The requester typically adds the authentication and authorization information in the form of tokens. Thus, there's a need to share and coordinate security information, such as tokens, between requester and provider or across a chain of requesters, providers, and possibly SOAP intermediaries.
Security headers are added to SOAP messages.
<wsse:Security xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/12/secext"> <wsse:UsernameToken> <wsse:Username>Ericn</wsse:Username> <wsse:Password>8Bcnu6</wsse:Password> </wsse:UsernameToken> </wsse:Security>
The example shows the WS-Security namespace wsse and the use of the clear text user name/password authentication feature. The inclusion of WS-Security headers in a SOAP message ensures that the user name/password shown in this example is available for processing by intermediaries as well as at the ultimate destination of the message. Further information on these topics is provided later in this chapter.
If the service provider requires a Kerberos token, the WS-SecurityPolicy declaration associated with the provider's WSDL might look like this:
<SecurityToken wsp:Requirement=Kerberos <TokenType>... </TokenType> <TokenIssuer> ... </TokenIssuer> </SecurityToken>
As shown in Figure, a key pair (or other encryption mechanism) can be used to encrypt a message before transmission and decrypt it after it's received but before it's processed by the application. Encryption means sending information in code, much like the military does to protect confidential information during wartime. To snoop on an encrypted transmission, someone would have to be able to break the code. Encryption is often used to protect authentication and authorization data (such as a password), even if the data in the SOAP body isn't encrypted.
Encryption protects messages from snooping.
The encryption information can be sent in a WS-Security header so that a provider knows what encryption algorithm was used to encrypt the message. As with authentication, several standards exist for encryption. Some of the common ones include Secure Shell (SSH) and RSA, named for its inventors, Ron Rivest, Adi Shamir, and Leonard Adelman. RSA developed and first implemented the concepts behind public key cryptography (also called PCKS), which allows services to communicate securely by using a private key and by the exchange of a public key. The private key, which isn't shared, is used in the encryption algorithm, while the public key, which can be shared, is used to decrypt the message. In Web services specifications, the XML Key Management Specification (XKMS) can be used to manage the distribution of public and private keys to enable this style of secure communication.
These basic types of security technologies are also often used in combination with other extended technologies, such as reliable messaging and transactions, to improve the security of an overall system. Transaction processing technologies require additional messages for coordinating transaction protocols, and these often require security to prevent their disruption.
Web services management is often very concerned with security. In addition to securing the management infrastructure itself from unauthorized use (i.e., to prevent anyone from gaining administrative control over the Web services deployment), it's important to be able to monitor and manage the security infrastructure. Web services management tools typically implement some level of security functionality using SOAP intermediaries or SOAP interceptors.
Identity management for Web services is similar to identity management for any IT system in that the subject (whether a person, machine, program, or abstraction such as a process flow) is given a unique or unambiguous name within the security domain whose validity can be checked. The identity of a Web service requester is sometimes critical for a provider to establish trust because whether or not the requester is allowed to access the provider's service (or any other service, data resource, or device managed by the provider's service) depends upon the identity of the requester.
Identity management is complex for Web services, just like it is for the Web, because Web services can span departments and enterprises. Typically, identity management is performed locally, departmentally, or within an enterprise by ensuring that each employee's user name is unique on the network. Employees are responsible for keeping their passwords private because passwords are used to authenticate the user's identity and to determine the applications, directories, and data the user is allowed to access.
Identity management may need to be performed within a broader scope, such as the Microsoft Active Directory or a corporate-wide LDAP solution. When an identity has to be uniquely managed across the Internet and across enterprises, the level of administration difficulty increases, as does the need for trust. Various initiatives, such as those sponsored by the Liberty Alliance, are focused on establishing mechanisms for identity management for the Internet.
Authentication is the process through which an authority verifies a subject's identity, based on some set of proof such as a password or personal identification number (PIN). The authentication process creates a principal, which is an object that represents the authenticated subject, such as a credential or token that the subject can use later. On the Web, the subject is typically a user, but for Web services, it can be a machine, program, or other abstract entity represented by the Web service requester. Web services typically use some form of the user name/password mechanism for basic authentication, but stronger forms such as signatures also may be used.
Authentication can be described as the process of confirming that you (or your proxy service requester) are who you say you are. On the Web, this is most often seen as a popup user name/password box, which is called forms-based authentication, which uses a cookie returned on subsequent invocations. Only you know the correct user name and password, so you are authenticating yourself as someone who is allowed to access the Web site. The Web site will have to set up and manage a directory of authorized user name/password combinations so that it can verify the information you submit.
Web services requesters can include authentication information using user name/password information in SOAP headers that the service provider can check against its directory of authorized user name/password combinations. The user ID and password can also be sent via HTTP (no SOAP header required). The provider typically carries out a further refinement of this model to support specific checks for authorization to access specific services or specific data resources. Sometimes requesters are assigned certain roles that can be used as indexes into authorization informationmeaning authorization is sometimes carried out according to specific roles such as administrator, clerk, or manager, but again, this is typically managed by the provider and may not appear in the SOAP header (and certainly not in the WS-Security header if it appears at all).
Authentication is needed in Web services to verify the identities of the service provider and service requestor. In some cases, mutual authentication may be needed (that is, the provider must authenticate the requester and vice versa).
A digital signature signs a message digest using a public/private key pair. A hash algorithm creates the message digest, and the encryption algorithm signs the digest (with the private key). The receiver decrypts the signature using the public key, recomputes the message digest, and compares the two. If the message has been altered, the results won't match, and the provider knows the message has been tampered with. As in other encryptions, symmetric or asymmetric key algorithms can be used to compute the signature, although for signing the user of asymmetric keys is more typical.