Implementation Scenarios

Many of the security specifications discussed in this chapter can be applied to your security needs. Let us briefly discuss some scenarios that use in a business context some of the specifications covered.

Many organizations have specific business policies that must be enforced. A Web service may mandate that consumers have a certain rating with a specific auditing company. Policies that Web services use can be validated in a standardized manner, which has the advantage of simplifying the Web services process.

For example, the Flute Bank wire transfer Web service takes the approach shown in Figure 15.8. This scenario defines security token use. The bank's Web service interacts with other banks to transfer money on behalf of its customers. The service must validate that the receiving bank is certified by the government banking authority. This authority could go to the other bank, present its identity security token gathered from the Security Token Service, and request a security token from the other bank confirming that it is a government-certified bank. The government banking authority could then contact Flute Bank and provide both security tokens.

Figure 15.8: Bank wire transfer process

Flute Bank could codify its business policy into a service policy and shift proof of policy conformance from a backend process to a front-loaded process handled by the government banking authority. The service policy could also identify restrictions on what information each bank could store, to ensure compliance with the bank's privacy policy.

Flute Bank also allows wire transfer requests to be initiated through cellular phones and other forms of wireless communication. Mobile devices typically have limitations on the types of cryptography they implement. This is primarily a result of limited memory, storage, and computational capabilities. Many wireless service providers provide gateways that act on behalf of the wireless device (Figure 15.9).

Figure 15.9: Mobile access through gateways

Wireless network operators and their gateways may use SOAP to provide the intermediary functionality for their wireless devices to communicate with Web services. The wireless devices themselves may include unique encryption algorithms. The wireless gateway can alter and/or supplement the security tokens and the message protection. This security model is also valid when the wireless device is roaming on a foreign network.

Many Web services will also use a federation model. Let us say that Annika, a customer of Flute Bank, wants to use a currency Web service at the First & Last Bank of Tunapuna (a company with which Flute maintains a relationship). The currency Web service allows only requests with a security token issued by Flute Bank. Annika's security token can be used only with identity claims. In this situation, Annika can access only the currency Web service, if the First & Last Bank of Tunapuna is willing to permit security federation with Flute Bank.

As Figure 15.10 shows, Annika presents her Flute Bank security token to the First & Last Bank of Tunapuna's security token service and receives a security token. Annika then presents the new token to the currency service. The federated model may use public-key security tokens to facilitate security federations. Each service could additionally specify for its policy that it may accept Kerberos security tokens from its Key Distribution Center (KDC).

Figure 15.10: Security federations

Web service security may also support delegated operations. Another Flute Bank customer, Kelon, uses the investments Web service to manage his portfolio. He wants to allow his investment adviser, Demesha, and his wife, Victoria, to access his holdings. Demesha does not do portfolio analysis and management directly and instead uses an application service provider. Whenever Demesha observes market activity with a particular stock, she places buy/sell recommendations that are broadcast to each of her clients.

Kelon provides both Victoria and Demesha with a security token that allows both of them to access his portfolio (Figure 15.11). The security token contains claims that limit Demesha's ability to analyze the parts of his portfolio that do not contain stocks. This security token also allows Demesha to create successive security tokens, as long as the portfolio analysis service can prove it has a privacy certification from the third-party trust service.

Figure 15.11: Delegation of trust

The trust service provider may audit each of the services on a periodic basis, so that any security token issued by the service asserts the privacy certification. When the portfolio analysis service accesses Kelon's portfolio, it can confirm proof of possession of its privacy certification and its assertion to access and schedule a trade, based on the security tokens from Kelon through Demesha to itself.

Hopefully, you have learned how to apply many of the standards we have discussed so far to design and/or implement a secure Web services infrastructure. Let us step into the final discussion point, on identity management.