WS-I Specifications

IBM and Microsoft have developed an initial set of Web services security specifications ( Table 15.3 and ScreenShot) that will initially be built into the .NET architecture but have been turned over to the OASIS working group. These sets of specifications will include a message security model (WS-Security) that will be the foundation for other WS-I specifications.

These specifications are evolving and continue to change over time. As each comes closer to its public final release date, the security aspects of your Web service may require some changes.

WS-Security

This specification provides a general-purpose means for joining messages with security tokens. WS-Security supports multiple security-token formats and can be used independently or in conjunction to accommodate an assortment of security models and encryption technologies. This could be useful in situations where a requestor may require proof of identity and assurance that the party has a particular business certification.

WS-Security leverages the XML encryption specification along with security tokens to keep portions of SOAP messages confidential. The encryption features can also support encryption technologies, processes, and operations by multiple parties.

WS-Policy

WS-Policy specifies how senders and receivers can state their requirements and capabilities regarding policies they require to conduct business in an electronic format. This specification is highly extensible and will support identification of service attributes, including encoding formats, privacy attributes, security token requirements, and supported algorithms. WS-Policy defines a generic SOAP policy format that supports more than simply security policies. With this feature, you can also define service policies and attach them to SOAP messages.

WS-Trust

In a connected world, many users of services are built in a manner that is not hardware-independent and require identity information embedded in their code. It is unreasonable to expect all apps to have equal capability to secure personal information and maintain message and data integrity. The Web site paradigm has been a failure in this regard. Several examples are use of cookies and multiple Web site registrations. Even when it does work as advertised, the consumer is ignorant of how the information is collected, shared, stored, or used.

This specification describes the model for establishing trust relationships, both direct and through brokers (third parties and intermediaries), using security-token issuance services. Security tokens are transferred through WS-Security to ensure their confidentiality and integrity. The specification also describes how one to many existing trust mechanisms can be used in conjunction with this trust model. The model can be further extended to support delegation and impersonation by principals. Delegation is an extension of impersonation but with the ability to include additional levels of traceability.

WS-Privacy

Personal information becomes public in many ways, including, but not limited to, sharing of customer data through disclosure agreements and partnerships, unsecured personal information stored on the Internet, and lack of dynamic engagement protocols. WS-Privacy allows organizations to state their privacy policies and require that incoming requests make claims about the initiator's adherence to these policies. Organizations can state and indicate conformance to privacy polices by using a combination of WS-Security, WS-Policy, and WS-Trust.

WS-Privacy also describes how WS-Trust mechanisms can be used to evaluate privacy claims for organizational practice as well as user preferences. This specification will become extremely important in the not-too-distant future, as many governments pass laws to protect sharing of personal information without the owner's knowledge or permission.

WS-SecureConversation

This specification describes how services can exchange assertions about security attributes. WS-SecureConversation extends the concepts of security token mechanisms defined by WS-Security and WS-Trust. It also describes how to establish session keys and per-message keys. A service implementing this specification could implement support for creating security tokens that use either symmetric (shared-secret) key algorithm or asymmetric (public/private) algorithms.

Unlike SSL, which secures the transport, secure conversations operate at the SOAP messaging layer. Messages can travel over an assortment of transports and through various intermediaries. WS-SecureConversation can be used in conjunction with other messaging frameworks and may be combined with transport-level security and WS-Security implementations.

WS-Federation

Federations are based on defining and managing trust relationships between service providers. A trust policy is usually introduced to specify and identify the type of trust being brokered. Trust relationships in a Web services scenario will use WS-Security, WS-Policy, WS-Trust, and WS-SecureConversation specifications.

Federations are important in a Web services business-transaction scenario. In a nonelectronic business transaction, the first event is the establishment of a relationship. When one establishes a relationship with another party in real life, the first thing built up is trust. After trust is established, then usually comes some form of convenience in not having to prove oneself each time. Finally, a history of prior positive interactions is formed. Because one service cannot go out on a blind date with another service, an electronic equivalent is required.

WS-Authorization

This specification describes how Web service access policies are managed. It covers the description of how assertions can be made within security tokens as well as how they will be interpreted by each endpoint. This is important because each security provider may have a different authorization format and language. As an example, a PKI implementation behaves differently from a Kerberos-based implementation. PKI depends on certificates based on public asymmetric keys. The certificate authorities use assertions to validate properties such as identity. This model is different from Kerberos, in that it does not validate key ownership. The WS-Authorization specification may be incorporated into future firewalls (Checkpoint, Cisco) and proxy devices (Alteon, Cisco, F5, Radware) to provide greater flexibility in rules and inspection of messages. This model will also support delegation models for services. Let us look at a scenario that demonstrates delegation models (see also ScreenShot):

1. James and his wife, Mattie, do all their financial services transactions through Flute Bank. They also take advantage of the Flute Bank Investments Web service that allows them to perform portfolio management activities as well as interact with their investment adviser. Currently, James is the only account that can access this service.

2. James would like to give both his wife and investment adviser access to his portfolio and creates a delegation token for each of them
3. James later decides he would like to update the authorization list at Flute Bank to contain both his wife and investment adviser, so he does not have to delegate access each time.
4. Now Mattie has access to the portfolio, she looks at the various securities in the portfolio and discusses her options with her adviser.
5. Mattie decides she wants to dump all stock for companies located on Easter Island and purchase Microsoft stock. She believes that the Windows platform will outpace its competitors over the next several years.
6. The investment adviser agrees with Mattie's assertion and contacts the Flute Bank Investment service to execute the trade.

Screenshot: Married couple interaction

The above example demonstrates how the delegation model works. Listing 15.12 is an example of using WS-Authorization to permit access to the Flute Bank quoting service.Listing 15.12: WS-Security example

<?xml version="1.0" encoding="utf-8"?>
 <env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope"
 xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
 <env:Header>
 <m:path xmlns:m="http://schemas.xmlsoap.org/rp/">
 <m:action>http://flutebank.com/getQuote</m:action>
 <m:to>http://flutebank.com/stocks</m:to>
 <m:id>uuid:84b9f5d0-33fb-4a81-b02b-5b760641c1d6</m:id>
 </m:path>
 <wsse:Security
 xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/04/secext">
 wsse:UsernameToken >
 <wsse:Username>Pinto</wsse:Username>
 </wsse:UsernameToken>
 <ds:Signature>
 <ds:SignedInfo>
 <ds:CanonicalizationMethod Algorithm= "http://www.w3.org/2001/10/xml-exc-
 c14n#"/>
 <ds:SignatureMethod Algorithm= "http://www.w3.org/2000/09/xmldsig#hmac-sha1"/>
 <ds:Reference URI="#MsgBody">
 <ds:DigestMethod Algorithm= "http://www.w3.org/2000/09/xmldsig#sha1"/>
 <ds:DigestValue>Ll1tTl3mAnPU ... </ds:DigestValue>
 </ds:Reference>
 </ds:SignedInfo>
 <ds:SignatureValue>D34adm5gK ... </ds:SignatureValue>
 <ds:KeyInfo>
 <wsse:SecurityTokenReference>
 <wsse:Reference URI="#MyID"/>
 </wsse:SecurityTokenReference>
 </ds:KeyInfo>
 </ds:Signature>
 </wsse:Security>
 </env:Header>
 <env:Body >
 <tru:StockSymbol xmlns:tru="http://flutebank.com/payloads">
 http://www.flutebank.com/service/ws-secure
 HIG
 </tru:StockSymbol>
 </env:Body>
</env:Envelope>

The first two lines are the start of the SOAP envelope. The m:path tag specifies how this message should be routed according to the WS-Routing specification. The Security tag defines the security information for the intended receiver. The UsernameToken tag specifies a security token associated with the message. In this scenario, it defines the username of the client. The ds:CanonicalizationMethod tag specifies the canonicalization method used as part of the XML signature specification. The ds:Reference URI=#MsbBody element indicates that only the message body is signed. The wsse:SecurityTokenReference tag provides the hint on the location of the security token associated with the digital signature. The Security header provides the ability to attach security-related information targeted toward the end recipient or an intermediary. A SOAP message may have multiple security headers, and an intermediary may create new headers as necessary. The intermediary may read SOAP security headers but should not remove them until they reach their final destination. Where validation of a security token, encryption, or a signature fail, the service can choose to respond with supported formats or not to respond, because the failure may be a cryptographic, replay, or denial-of-service attack. A service that decides to return a message to the sender should use one of the security fault codes shown in Table 15.4.

Table 15.4: WS-Security Faults

Error	Fault
An unsupported algorithm was used.	wsse:UnsupportedAlgorithm
An unsupported token was used.	wsse:UnsupportedSecurityToken
The security token could not be authenticated.	wsse:FailedAuthentication
The signature was invalid.	Wsse:FailedCheck
Error discovered while processing the <Security> header.	Wsse:InvalidSecurity
An invalid security token was used.	wsse:InvalidSecurityToken

WS-Coordination

The WS-Coordination specification addresses the concerns for coordinating distributed app. Coordination is used to support a number of apps where each must reach a consistent agreement on the outcome of distributed transactions. An app using this specification creates a context to other services that register themselves for coordination events. It provides an abstraction layer for services that require transaction processing, workflow, and coordination in distributed heterogeneous environments. A coordination service consists of three components: activation, registration, and coordination. An activation service is responsible for creating a coordination context and is called by the initiating Web service. The context holds the required information to register into an activity and specifies the behavior the calling service should use. The registration service allows a service to register for coordination protocols. The coordination context may use the registration service of either the original Web service or an intermediary trusted coordinator. This allows for an arbitrary collection of services to coordinate their operations seamlessly. A coordination context travels within SOAP messages between participating parties. Listing 15.13 shows a simple coordination context that supports a transaction service.Listing 15.13: Coordination context

<?xml version="1.0" encoding="utf-8"?>
<S:Envelope xmlns:s="http://www.w3.org/2001/12/soap-envelope"
 <S:Header>
 ...
 <wscoor:CoordinationContext
 xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/07/utility"
 xmlns:wscoor="http://schemas.xmlsoap.org/ws/2002/08/wscoor"
 xmlns:myApp="http://www.flutebank.com/myApp">
 <wsu:Expires>2002-08-24T12:02:00.000-06:00</wsu:Expires>
 <wsu:Identifier>http://www.flutebank.com/coor/abcd</wsu:Identifier>
 <wscoor:CoordinationType>
 http://schemas.xmlsoap.org/ws/2002/08/wstx
 </wscoor:CoordinationType>
 <wscoor:RegistrationService>
 <wsu:Address>
 http://www.chiltown.com/coordinationservice/registration
 </wsu:Address>
 <myApp:BetaMark> ... </myApp:BetaMark>
 <myApp:EBDCode> ... </myApp:EBDCode>
 </wscoor:RegistrationService>
 <myApp:IsolationLevel>RepeatableRead</myApp:IsolationLevel>
 </wscoor:CoordinationContext>
 ...
</S:Header>

Coordination messages are typically used in conjunction with WS-Security messages to ensure that messages are neither modified nor forged between destinations. The coordination message also contains an expiration timestamp. By using the WS-Security, you could ensure that the coordination message is not reused or replayed. Digital signatures should also be used to make sure the security header cannot be separated from coordination messages.

Web services must function over a variety of topologies, through intermediaries such as firewalls (e.g., Checkpoint, Cisco), messaging gateways (e.g., Actional, MQSeries, Sonic, Tibco), and load-balancing appliances (e.g., F5 Big IP, CSS 11000, CoyotePoint). These intermediaries provide additional layers of security for a Web services infrastructure but do not address all possible security breaches. The need for additional security specifications is evident. It is important that any new specification extend existing security assets within an organization. The WSI specifications are the first step in defining an all-inclusive security strategy.