SOA Policy Enforcement

There are several key challenges with respect to service oriented architecture policy enforcement. One of which is that application developers are typically not policy experts: they don’t have all of the insight needed to understand the compliance and governance rules or even all of the notions of security policy required throughout the SOA, both of which are knowledge gaps which introduce a degree of risk. And automated tools can't protect against inexperienced developers.

What's more, it's not easy to check and make sure that all of the SOA governance policies are being applied and enforced during the development cycle. The organization needs to separate the roles and responsibilities for policy enforcement so that the experts on policy are able to focus on what they do best, as opposed to mixing application expertise with policy expertise.

Why is SOA Policy Change a Challenge?

Policy change is a serious challenge for the following reasons:

• Policies change independent of applications.
• Every time a policy changes IT needs to version and roll out affected applications which can be time-consuming and complex.
• Sarbanes Oxley doesn't say: "These rules come into effect for the next version of your software".
• Regulatory rules and thus, policies, are in a constant state of evolution. The organization can't easily decouple compliance from its applications in the traditional sense.

IT needs to look at ways to decouple policy enforcement from the actual application development and deployment process to reduce the complexities of dealing with changing policies.

Decoupling SOA Policy Enforcement

Consider a typical SOA environment involving several service consumers and various services, each with various security measures associated with them, for example: authorization, authentication, encryption, digital signatures, etc. ...And each service having been traditionally developed on a per-application basis, and very often by service developers that, in addition to having to worry about rolling out their applications and service logic, are also concerned with the complexity of security. There are a lot of security complexities that developers need to worry about -- if they don't have the notion of runtime governance. But by bringing Actional runtime governance into the SOA picture, the complications of security can be offloaded in a centralized manner.

Policy-Driven SOA Security

Actional provides the ability to offload the security from developers and the application logic itself, enabling IT staff to bring in a security expert whose expertise is having knowledge of both global corporate policy and local security policies that apply to service-specific issues, and who is able to worry about different types of authorization and authentication methods, credential mapping between consumers and the services that they're trying to access, and, overall, ensure that security rules are being applied. Security policies can then be centrally defined, and when it comes time to enforce them, they might be enforced either centrally (for example, if policies are changing frequently) or in-container (for example, if the organization wishes to offload processor-intensive activities). Last-mile security is also important: making sure that if the organization has offloaded security, that there's no way for people to find a way to work around that.

From Business Policies to Enforced Service Oriented Architecture Policies

How do business policies actually become enforceable policies? A typical approach, without runtime governance, would involve all of the organization's defined business policies being interpreted by someone, and then having them converted into enforceable policies which could then be applied to each individual service on the network. This approach suffers because it's complex and every time there is a policy change IT needs to re-visit all of the deployed services. (A huge, ongoing task, to say the least.) When one considers business rules and business logic, their typically not applied at an individual service level. For example, privacy policies are applied at the informational level (e.g., "whenever you use personal information, it must be encrypted"): they are not service specific. The same goes for process policies, and similarly, to policies that apply to specific customers. These are broad-based policies and not service-specific policies.

Enforced Service Oriented Architecture Policies with Runtime Governanc

Now let us take a look at how Actional would fit in, first from the view of the policy owner who is aware of the various compliance and governance rules that need to be put into place around how to deal with personal identities, what to do with shipping destinations, etc., so that the organization can create policies to enable the encryption of personal data and the auditing of shipping destinations. The policy owner has the expertise needed to do that.

Now let us look at the situation from the perspective of the service owners who might not have specific knowledge of these policies and the rules as they need to be applied, but what the do have is detailed knowledge of their services and the messages that flow through them, for example, an XML Web service message. They will understand where in these messages these different data fields map to -- for example: personal information, shipping information, and customer information. Actional understands both policies and the service-specific nature of different services and how to map them together, merging the notion of policies and where they should be enforced, and the different ways in which they should be applied.

Total Solution: Actional Service Oriented Architecture Runtime Management

Once policies are created, they need to be enforced. Actional actively enforces policies across the SOA broadly as they apply to data as it flows through the network -- and to all the specific services where this policy would need to come into effect.

It's important to be able to deal with change in an environment, for example, when rolling out new applications as the service network grows. As change happens, policies need to be enforced without the overhead of having to go back to each individual service and roll out a new version that takes into consideration new policies. At the same time, it is essential to be able to discover rogue service consumers or providers and get them under control. Actional automatically adjusts to all the changes in the SOA and applies and enforces policy to services on the network.

For More Information

Service oriented architecture policy enforcement could save your firm millions -- in fines and lost revenue. Learn more about compliance and policy management. Download the free webinar, SOA Runtime Governance