So where does one begin?

Begin by making sure that access policy management - administration, resolution, auditing - aren't embedded inside a component or composite service. If the application logic is developed in a standard container model, e.g., J2EE or .NET, then try to make the service resources that need to be protected be at the granularity of the container interfaces. If so, then the access policy enforcement can be performed by a standards-based interceptor that can be integrated into the application infrastructure stack without any change in the application code. This interceptor-based enforcer will permit or deny a service resource to be accessed by permitting or denying the corresponding container interface from being invoked. Similarly, if the application logic has a standard invocation model, such as SOAP, and the granularity of the resources being protected are at the granularity of the invocation interface then the access policy enforcement can be performed by a standards-based interceptor in the SOAP stack. The interceptors can be deployed as code that is co-resident with the business service or they can be a separate infrastructure service that is invoked from within the application code. Generally the application code will invoke the policy resolution service over standard interfaces, e.g., XACML over SOAP, to get the access policy decision and will enforce the decision in the application code.

A well-designed SOA that is truly loosely coupled with access policy administration, resolution, and auditing as standards-compliant infrastructure services is depicted in the figure below. (Figure 3)

Unlike most other infrastructure services the Access Policy Resolution for fine-grained accesses or entitlements has constraints that dictate which particular instance of the Resolution service should be used. Since the access policy will be applied on every access and since the policy resolution may require message context and other attribute information that is local to the business service, it's likely that a relatively local instance of the resolution service will need to be invoked. It may be impractical from a performance, scalability, and availability point-of-view to use a centralized resolution service. Therefore it's important that a practical and effective security infrastructure for a SOA permit distributed Access Policy Resolution through multiple distributed instances of the Resolution service.

While this is the end state deployment architecture, how does one get there from here? What are some of the key operations and policy administration issues, and how does one deal with them?

Since there are many different owners of access policy for a given resource, e.g., component service administrator, composite service administrator, enterprise security and InfoSec teams, enterprise and LoB compliance teams, it's imperative that the policy administration service has a rich and effective delegation capability. It's critically important that the administration service not require all of these owners of access policy to coordinate their efforts or to have to come together and administer a single unified policy at the same time. Some of the conditions of the policy may need to be defined at different times. For example, the administrator of the composite service may want to have a say in the access policy of the component service at a much later time than the administrator of the component service will want to administer his say into the access policy of the component service. Similarly the compliance team will want to change the compliance aspects of the access policy, say an order initiator can't be the order approver, autonomously from the administration of the other aspects of the policy. In fact the compliance team will want the capability to change the policy to respond to a change in regulations without having to coordinate with the other administrators of access policy for a resource. In many instances it will be important from a checks-and-balances perspective that the administrators be different and independent.

Depending on the role a person is playing, when the person logs into the administration service they should only be able to administer those aspects of access policy for a resource that they are permitted to administer. So the administration service itself needs to be entitled, and needs to have rich delegation capability.

Now if there are to be many autonomous administrators of policy and if they aren't to be required to coordinate with each other, then it's possible that the policies that they define will be in conflict with each other. For example the administrator of the reconcile day orders composite service may specify a policy allowing access to the order management component service but the administrator of the order management component service may specify a policy that denies the access perhaps because the user on whose behalf the composite service is being initiated is also the approver of an order and this violates a segregation of duty policy at the order management component service. Therefore the administration infrastructure service should anticipate and handle access policy conflicts. These conflicts should be resolved when the access using the most up-to-date dynamic information and the resulting policy decision are enforced on the resource access.

A related and very important administration issue relates to user roles. Role-based access control (RBAC) or the use of roles in access policies is a very important way to manage accesses to resources. The benefits of RBAC are many and have been well documented in many excellent articles. The key driver for RBAC is ease of management - there are typically many fewer roles than there are users. Since the same user can be a member of multiple projects, each project can have its own access requirements, and since user-to-project and project-to-access mappings can change, roles are a powerful abstraction to manage and enable this flexibility.

Important as RBAC may be, when deploying a security infrastructure service in a SOA (the security infrastructure service is more accurately a set of services - administration, resolution, and auditing - as mentioned earlier) role assignment can also be cause for paralysis. Whether deploying a SOA or not, many organizations first try to reconcile all roles across the enterprise in a top-down fashion. This is a long, painful, and largely futile exercise. There are a few enterprise-wide roles; most roles are resource-specific. Yes, you may be a "VP" in the corporate LDAP, but that by itself isn't going to let you access the development version of a business service. And that by itself shouldn't let you administer the HR service.

Each resource has its own notion of roles and what level of access should be allowed users with what roles. These resource-specific roles in conjunction with global roles can be the basis of an effective RBAC solution. For example, an access policy may state that access to a business service is allowed to users who have a "controller" role in the enterprise LDAP or an "administrator" role in the service being protected. The access policies should allow global and service-specific user roles to be specified and used (user attributes in general, where a role is one form of attribute; others could be geography, organizational membership, employment status, etc.). The security administration service should also allow resource owners to specify, assign, and manage resource-specific user attributes.

Such distributed ownership and management of resource-specific user attributes is consistent with an unstated principle that underlines SOA: local control, global coordination. It's not only necessary for the smooth functioning of a practical SOA, it also expedites getting to a state of meaningful and effective RBAC. Now instead of trying to reconcile all roles across the enterprise in a top-down fashion and trying to keep them all consistent when user-to-role or role-to-access mappings change, most role assignments are delegated to the resource owners who can define what they need for their particular resource and can administer and manage appropriate changes at an appropriate pace.

In conclusion, a Service Oriented Architecture is more than simply packaging application functionality into business services that adhere to industry standard interfaces. It requires the externalization of non-business logic-related functionality from the applications that have to be provided and used as a set of standards-compliant infrastructure services. Security is a critical infrastructure service that is key to achieving the plug-and-play goals of SOA. If designed well it can abet the smooth operation and evolution of a SOA environment, and more importantly it can smooth the path to a SOA environment. If not, it can be the undoing of an otherwise sound SOA plan.