Applications that require authenticated identity information before performing some business logic must obtain that information from the infrastructure. For instance, in a J2EE environment, the run time establishes the user's identity after authentication; the application can retrieve this information with an API, such as getCallerPrincipal().

Flexibility of choiceSometimes certain requirements or constraints on the access to the service itself -- including authentication, integrity, and confidentiality requirements - are needed by a client run time. And it may be desirable to support a wide variety of client run times (such as browser clients, nonbrowser clients, and PDA thin clients). To achieve this, you publish policies asserting that the client runtime must ensure message confidentiality and must provide evidence of the user's identity (user ID/password or a certificate). The policy abstraction for authentication can list alternatives, such as the types of credentials that are acceptable or which credential-issuing authorities are trusted.

For instance, a TravelService Web service can declare its intent to require certain security token types and confidentiality requirements. The implementation may support the declaration of intent through descriptors. Tools can, in turn, generate necessary machine-level details (such as a WS-SecurityPolicy expression), as illustrated in Listing 2.

Listing 2: Example of WS-Security Policy description<wsp:Policy>

  <sp:SymmetricBinding>
    <wsp:Policy>
      <sp:ProtectionToken>
        <wsp:Policy>
          <sp:KerberosV5APREQToken
              sp:IncludeToken=".../IncludeToken/Once" />
        </wsp:Policy>
      </sp:ProtectionToken>
      <sp:SignBeforeEncrypting />
      <sp:EncryptSignature />
    </wsp:Policy>
  </sp:SymmetricBinding>
  <sp:SignedParts>
    <sp:Body/>
    <sp:Header
       Namespace="http://schemas.xmlsoap.org/ws/2004/08/addressing"
    />
  </sp:SignedParts>
  <sp:EncryptedParts>
    <sp:Body/>
  </sp:EncryptedParts>
</wsp:Policy>

SummaryAn SOA programming model must ensure that each service invocation adheres to security policies that are valid for both the requester and service endpoint. The security infrastructure -- including the ability to authenticate requesters and authorize their access to services, propagate security context across Web service requests based on an underlying trust model, audit significant events, and effectively protect data and content -- forms a fabric of the SOA environment that helps secure components and services. At the core of all SOA security is a policy-based infrastructure and management of the policies. In the ideal case, the SOA application is centered on business logic, delegating the enforcement of security policies, and handling trust relationships for the infrastructure. The Web services security model and approaches based on the Web services security specifications help meet the challenges of securing service-oriented applications.

Sidebar:
(This article was first published on developerWorks at http://www.ibm.com/developerWorks/webservices. It is the seventh article in a series. This article, resources linked to it, and related articles can be found at the developerWorks URL listed here.)Securing applications in a service-oriented architecture (SOA) is challenging, because the loose coupling that characterizes an SOA can expose existing security implementations' weaknesses. The following solution includes well-defined trust models based on acceptable forms of proof as well as reliance on policies, Web services security, and security engineering best practices.)