Page 2 of 3   « previous page   next page »

One mechanism would be the use of a challenge-response protocol as defined in WS-Trust (see Resources for more information about the WS-Trust spec). This is used by a Web service for additional challenges to a requester to ensure message freshness and verification that the use of a security token is authorized. This model is illustrated in Figure 3, showing that any requester may also be a service, and that the requester and target service may have a trusted third-party security token service that helps validate the security tokens required per the target service's policy.

This SOA security model - claims, policies, and security tokens - subsumes and supports several more specific models, such as identity-based authorization, access control lists, and capabilities-based authorization. It allows use of existing technologies, such as X.509 public key certificates, XML-based tokens, Kerberos shared-secret tickets, and even password digests.

The SOA security model, in combination with the Web Services Secure Conversation Language (WSSC) and Web Services Policy Framework primitives, is sufficient to construct higher-level key exchange, authentication, policy-based access control, auditing, and complex trust relationships.

A Web service has a policy applied to it, receives a message from a requester that possibly includes security tokens, and may have some protection applied to it using WSSC mechanisms. The following main steps are performed by the trust engine of a Web service:

• Verify that the claims in the token are sufficient to comply with the policy and that the message conforms to the policy.
• Verify that the attributes of the claimant are proven by the signatures. In brokered trust models, the signature may not verify the identity of the claimant; it may verify the identity of the intermediary who may simply assert the identity of the claimant. The claims are either proven or not based on policy.
• Verify that the issuers of the security tokens (including all related and issuing security tokens) are trusted to issue the claims they have made. The trust engine may need to externally verify or broker tokens (that is, send tokens to a security token service in order to exchange them for other security tokens that it can use directly in its evaluation).

Network and transport protection mechanisms, such as IP Security (IPSec) or Transport Layer Security/Secure Sockets Layer (TLS/SSL), can be used in conjunction with this SOA security model to support different security requirements and scenarios. As an added level of security, requesters should consider using a network or transport security mechanism, if available, to pre-authenticate the recipient when issuing, validating, or renewing security tokens.

Programming model design principles
From a security perspective, the programming model includes decisions to be made about who is responsible for enforcing security policies (such as infrastructure or application) and what of this information needs to be made available to requesters. In addition to the operational aspects, some of the design-time policy (for example, captured in J2EE deployment descriptors) can help manage the application. One of the key implementation decisions is whether the business needs will best be met by enabling the infrastructure to implement the security model or by codifying security enforcement into each application. Another dimension to consider is how variable the service invocation is. Are service consumers given flexibility through choices they can customize during subscription? Lastly, when implementing any secure solutions, one should consider security engineering - an engineering methodology to build secure applications.

Infrastructure-Managed vs Application-Managed Security
Each organization typically gives certain people the responsibility for identifying and enforcing its security policies. In many cases this process is manual, causing the organization to devote significant resources to coordinating access across different entities and applications.

We recommend that complex organizations centralize, in the infrastructure, the enforcement of the security policies associated with a solution - that is, validating the user challenge (for example, user ID/password), controlling access to applications (such as reserve() method on travelService), and delegating identity (for example, run-as travelAgency id) to ensure a consistent approach. Initial application security policies can be defined in some deployment artifacts (e.g., deployment descriptors for J2EE applications). After development, when the application logic is largely known, the policy information can be made available to the deployment environment. Policy declarations can be abstracted into high-level policy requirements for later refinement as implementation constraints are considered during the deployment phase.

The application design introduces decisions to be made about infrastructure- versus application-managed security. The security constraints and conditions are attached to the implementation artifacts. The time for deciding whether to let the infrastructure handle security, or codify security in the application, is during the implementation phase when information about the application platform - such as Java 2 Platform, Enterprise Edition (J2EE) and Microsoft .NET - is usually available.

We recommend that applications focus on business logic and defer securing the service access and the messages to the infrastructure (the runtime container hosting the application). In this infrastructure-managed approach, security policies attached to design artifacts are transformed into platform-specific policies [for example, requirements expressed through a Unified Modeling Language (UML) model are transformed into J2EE deployment descriptors).

In the application-managed approach, security enforcement is done in the application, and the appropriate security callouts must be implemented. Even application-managed security has to translate its security callouts (such as authenticate()) into appropriate platform-specific functions [such as loginContext.login() using Java Authentication and Authorization Service (JAAS)].

Authorization and access control can vary from coarse- to fine-grained. The choice of coarse-grained access (to the solution itself) versus fine-grained access (to one of its operations) is usually governed by business and technical considerations. Granularity is also influenced by factors, including the instance of the information entity (for example, credit account profile for a given traveler), contextual information, such as user attributes (for example, travel agent), temporal constraints (for example, 9-5 p.m.), purpose of access (such as for the purpose of making a travel reservation), access path (for example, Authorization-related policy can be abstracted by defining application roles, where a role is a collection of permissions that allow certain actions on given application resources. For example, a travel application can declare that the view() or change() reservations methods on ReservationBean can be accessed by TravelAgent role. In other words, TravelAgent is an implementation-defined role that identifies what can be done by a "travel agent" in terms of a set of permissions to invoke specific methods on the respective Enterprise JavaBeans (EJBs). What is not likely defined during the implementation phase is who has the privileges of a TravelAgent. User-to-role assignments are typically initialized at deployment and managed thereafter throughout the application's lifetime. Listing 1 shows an example of code defining some role-based method permissions.

Listing 1: Code defining some role-based method permissions<method-permission>

<role-name>TravelAgent</role-name>
<method>
<ejb-name>ReservationBean</ejb-name>
<method-permission>
<role-name>TravelAgent</role-name>
<method>
<ejb-name>ReservationBean</ejb-name>
<method-name> view</method-name>
<method-name> change</method-name>
</method>
</method-permission>

Page 2 of 3   « previous page   next page »