Secure Web services

The upcoming Web services security schemes should help drive Web services forward

1 2 3 Page 2
Page 2 of 3
<saml:Assertion ...>
  <saml:AuthenticationStatement
    AuthenticationMethod="password"             (By means M)
    AuthenticationInstant="2001-12-03T10:02:00Z">(At time T)
    <saml:Subject>                               (Subject S)
      <saml:NameIdentifier
        SecurityDomain="sun.com"
        Name="Sang" />
      <saml:ConfirmationMethod>
        http://...core-25/sender-vouches
      </saml:ConfirmationMethod>
    </saml:Subject>
  </saml:AuthenticationStatement>
 </saml:Assertion>

In Listing 1, the authentication statement says that a subject called Sang in security domain of sun.com has been authenticated at some time on December 3, 2001. The means of authentication is the entering of username and password.

Attribute statement

An attribute SAML statement indicates that an issuing author asserts that a subject S is associated with attributes A, B, and so on, with corresponding values a, b, and so on. An attribute statement is useful for distributed transactions and authorized services.

Listing 2 illustrates an SAML assertion that contains two attribute statements:

Listing 2. SAML statement with attribute statements

<saml:Assertion ...>
  <saml:AttributeStatement>
    <saml:Subject>..Sang..</saml:Subject>
    <saml:Attribute
      AttributeName="PaidStatus"          (attribute A)
      AttributeNamespace="http://smithco.com">
      <saml:AttributeValue>              (with value a)
        PaidUp
      </saml:AttributeValue>
    </saml:Attribute>
    <saml:Attribute
      AttributeName="CreditLimit"         (attribute B)
      AttributeNamespace="http://smithco.com">
      <saml:AttributeValue>              (with value b)
        <my:amount currency="USD">500.00
        </my:amount>
      </saml:AttributeValue>
    </saml:Attribute>
  </saml:AttributeStatement>
</saml:Assertion>

Listing 2 contains two attribute statements for a subject Sang. The first attribute has the name PaidStatus, with corresponding value paidup. The second attribute has the name CreditLimit, with corresponding value of 500.00. This assertion could be used for the third use-case, where a Works.com employee tries to purchase million worth of chairs from Office.com.

Authorization statement

An authorization statement is the third kind of SAML assertion statement. This type of statement says that an issuing authority decides whether to grant the request by subject S for access type A to resource R, given evidence E presented by the requesting party. The resource can be a Web service or Webpage.

Listing 3 shows an SAML assertion containing an authorization statement:

Listing 3. Authorization statement in an SAML assertion

<saml:Assertion ...>
  <saml:AuthorizationStatement
    Decision="Permit"                        (Whether to grant request)
    Resource="http://jonesco.com/rpt_12345.html"> (for res. R)
    <saml:Subject>... Sang ...</saml:Subject>                  (by Subject S)
    <saml:Actions
      ActionNamespace="http://...core-25/rwedc">
      <saml:Action>Read</saml:Action>        (for access type A)
    </saml:Actions>
  </saml:AuthorizationStatement>
</saml:Assertion>

Listing 3's SAML assertion contains a single authorization statement. The resource is a Webpage whose address is http://jonesco.com/rpt_12345.html. In this example, after receiving an SAML assertion request message with some kind of evidence E, an asserting party grants the request, indicating that the subject Sang can read the Webpage.

SAML request/response protocol

Figure 4 shows the simple request and respond communication model between the relying and asserting parties.

Figure 4. SAML request/response protocol

The relying party is sometimes called the requesting party, while the asserting party is called the issuing party. The relying party sends SAML assertion request messages, and the asserting party, in response, sends back SAML assertion responses. The examples of SAML assertion statements you have seen in this article are in fact SAML assertion response messages.

WS-Security

The WS-Security (Web Services Security) specification defines a set of SOAP header extensions for end-to-end SOAP messaging security. It supports message integrity and confidentiality by allowing communicating partners to exchange signed and encrypted messages in a Web services environment. Because it is based on XML digital signature and XML Encryption standards, you can digitally sign and encrypt any combination of message parts. WS-Security supports multiple security models, such as username/password-based and certificate-based models.

It also supports multiple security technologies, including Kerberos, PKI, SAML, and so on. In addition, it supports multiple security tokens; for example, tokens that contain Kerberos tickets, X.509 certificates, or SAML assertions.

ebXML Message Service

The ebXML initiative is a set of next-generation XML-based standards enabling electronic business transactions via the Internet. One of the ebXML standards is ebXML Message Service, which defines how to securely and reliably send and receive SOAP messages. Figure 5 illustrates the ebXML Message Service security architecture.

Figure 5. ebXML Message Service security architecture

How the initiatives work together

Now let's talk about how these standards would work together. The SAML assertions can be digitally signed using XML digital signature. The same assertions can be encrypted using XML Encryption to ensure privacy. The public key used for digital signing and encryption can be validated and registered via XKMS. As for XACML, an SAML asserting party could use it to define an access control policy as a basis for handling SAML-based assertion requests.

Figure 6 illustrates how SAML works with other XML security standards.

Figure 6. How Web services security standards work together

On the left side of the diagram, Alice uses XML digital signature and encryption to digitally sign and encrypt the purchase order XML document. She then sends the document to her supplier, perhaps using SOAP, whose header structure is defined either in the WS-Security or ebXML Message Service standard. The document's receiver then could use XKMS to look up and validate Alice's public key. Once the key is determined trustworthy, the receiver then validates and decrypts the purchase order. Finally, the receiver checks a policy server for authorization by sending and receiving SAML requests and responses. The policy server might maintain the access control policy information in XACML.

So far, I have focused this discussion on XML-based Web services standards. Next, I talk about identity and identity management architecture.

Why identity management architecture?

So what is identity? Identity is a set of attributes that describes a profile of an individual, business organization, or software entity. The set of attributes for an individual, for example, could include driver's license, social security number, travel preferences, medical history, financial data, and so on.

What is the consequence of lacking a well-integrated and interoperable identity management architecture? Silos of identity, which is the state of the consumer Web today. In this state, which I call a state of identity crisis, each site has its own authentication method, and its own method of maintaining identity information and user profiles. Each site has inconsistent schemes for accessing and editing identity information. And each site has unclear and/or differing policy and privacy statements. Few, if any, silo identity systems truly interoperate.

This situation is not limited to consumer Websites. The same can be said of an enterprise. Distinct identities and logins exist for building access, workstation login, application access, and remote access. Different applications require the user to reenter username and password, which don't interoperate. This makes managing Web properties, applications, identities, and policies nonscalable, and effectively prohibits the interaction (or even the association) of identities across applications or Web services.

Figure 7 shows two possible identity management architectures, one based on a centralized model and the other, on a federated model.

Figure 7. Two possible identity management architectures

In the centralized model, a single operator performs authentication and authorization by owning and controlling all the identity information. In the federated model, both authentication and authorization tasks are distributed among federated communities.

One advantage of the centralized model is that, because a single operator owns and controls everything, constructing and managing the identity network could be easier than with the federated model. However, the centralized model has serious downsides. The most serious one is the dangerous potential for the single operator becoming a tollgate for all transactions over the Internet. For example, the operator might charge a fee for every transaction you make. You might have to pay a few cents or dollars whenever you perform a transaction on eBay.

The centralized model has another serious problem: the single operator could represent a single point of security failure or hacker attack. One more reason why the centralized model has not garnered any support, especially from the business community, is because a single operator can take away the most important business asset—that is, customer identity and profile information—from an organization. That results in a serious threat to businesses such as banks and brokerage houses whose success depends on their customer information. This information represents one of the most critical assets to a business, one it is not willing to give up to a third party.

The federated model, driven by the Liberty Alliance Project, is designed to correct the centralized model's problems. The goal of the Liberty Alliance Project is to create an open standard for identity, authentication, and authorization, which will lower e-commerce costs and accelerate organizations' commercial opportunities, while at the same time increasing customer satisfaction. In a Liberty architecture, organizations can maintain their own customer/employee data while sharing identity data with partners based on their business objectives and customer preferences.

Figure 8. Roles in federated identity management architecture

As illustrated in Figure 8, in the federated identity management architecture scheme, three roles could exist. The first is the role of a consumer. As a consumer, you can have multiple identity profiles, and you can ask different identity providers to maintain these profiles. For example, you might want your HMO to manage your healthcare profile and your brokerage house to maintain your brokerage profile. In fact, as a consumer, you can pick and choose which identity provider to maintain your profile based on price, credibility, service, and so on. In this model, consumers have a final say in terms of who can access what information. Consumers can be a person, a business, or a software entity.

In this case, the HMO and brokerage house play the role of identity provider. Identity providers maintain user profile information and can interoperate among themselves as long as they have permission to do so from the profile's owner, the consumer. Identity providers are expected to compete for your business in the future in the same way HMOs, banks, and brokerage houses compete for your business today.

The third role is that of the service provider, the merchant who has services to offer consumers. Service providers can customize their services to each consumer by retrieving relevant identity profiles from the identity providers. For example, your travel agent might discover your travel and dining preferences from the identity provider you designated to maintain your travel preference.

Figure 9 shows how a federated identity network is expected to evolve.

Figure 9. Evolution of identity networks

In the first picture, a phase with no federation, a consumer must log in separately to each site. This phase will then evolve into an environment where multiple identity networks exist. Within a single identity network, single sign-on can be achieved. However, no network-to-network identity propagation is available at this stage.

Eventually, these individually constructed and operating identity networks will work together by exchanging their consumers' identity information, thus providing a truly seamless, global-scale identity network, the Liberty Alliance Project's ultimate goal.

Figure 10. Analogy to ATM networks

As illustrated in Figure 10, the ATM network serves as an analogy for the federated network. Initially, individual banks issued their own ATM cards, and different banks did not interoperate. At this stage, you could not use your ATM card in an ATM machine owned and operated by another bank. These days, you can use your credit card or ATM card in any ATM machine, as long as the bank that owns the machine and your bank are members of the same affiliation network. In the not too distant future, it is not a stretch to think about a single global network to which all banks directly or indirectly belong. The identity network should evolve similarly.

One possible challenge of the federated identity network model is that because there are many parties involved, the standard has to be defined in an unambiguous manner. The Liberty Alliance Project addresses that challenge.

Ensure secure transmissions

1 2 3 Page 2
Page 2 of 3