In the tradition IT infrastructure world, many people think of policies as something typically related to SOA security. In an SOA, however, policies have much broader scope. They aren’t just about security – they include SOA governance, compliance, quality of service, etc.
The easiest way to define “policy”, used in the context of SOA, is as requirements that well-defined sets of services must follow. For example, “all externally-accessible services must use HTTPS” would be an example of a policy.
Because of the broad scope of what policies mean in an SOA, I've seen a lot of confusion as people try and understand what one person means by “policy” versus the next person’s definition. So, here’s a framework I use to think about the different types of policy...
There are two dimensions to consider about policy, which you can broadly think of as the type of policy and the scope at which it is applied.
Broadly speaking, there are three types of policies:
Schema policies - these are policies that impact the schema of the messages themselves that will be exchanged between consumer and provider. For example “platform specific data structures (e.g. .NET DataSets) cannot be used in the schema.” These policies impact the contract between consumer and provider directly. The WS-I basic profile is a standard which defines specific schema policies to improve interoperability.
Communication policies – these are policies that impact the communication (including encoding, transport, security, etc.) between consumers and providers. For example “all messages must be encrypted.” These policies directly impact the contract between consumer and provider, though primarily at the infrastructure layer, not the application layer. The WS-Policy standard is primarily related to this type of policy.
Behavior policies – these are policies that impact the behavior of a service, but do not directly impact the message sent from consumers to providers. Examples are “Requests from gold customers must be given priority over other requests” and “all order IDs must be logged for an audit trail”. XACML is a standard for defining behavior policies specific to access control.
Beyond policies is the question of what do policies apply to. There are two fundamentally scopes to which policies can apply:
Service scope – these are policies which apply to specific services (or operations). For example “this policy is applied to all ordering services.”
Content scope – these are policies which apply to specific content. For example “this policy is applied to all personal identities.”
Here are some specific examples to bring it all together:
Services must be WS-I compliant
Externally accessible services must use HTTPS
Order creation must be audited
Customers must be represented using the corporate-standard schema
Credit card data must be encrypted
Reject requests with international billing addresses
Beyond the scope of application, some policies may be statically applied (e.g. “always encrypt”) while others may be conditionally applied on a request by request basis. Here are some examples of conditionally applied policies:
Orders over $10K must be digitally signed
Requests from gold customers must have priority
Encrypt personal identity when consumer is located in Europe
Audit any requests related to cancelled customer IDs.
Since conditional policies apply based on individual requests, they do not apply to schema policies (since schema is inherently statically defined).
Also note that WS-Policy does not allow you to explicitly define conditional communication policies. You would instead, for example, define signing or encryption as optional in a WS-SecurityPolicy, and check the conditions at runtime to decide whether to do it or not.
While the above is really about classifying what “buckets” a policy fits into, one other aspect to consider, which is specific to products that work with policies, is what role a product plays in the policy lifecycle:
Authoring – the product lets you create (and edit) policies.
Repository – the product is able to store policies. A key question is whether the product has a generalized repository, or whether it can only store its own policies.
Binding – the product manages the association between policies and scopes.
Approval – the product provides an approval workflow process, rather than just security controls over publication of services and policies.
Validation – the product is able to validate that policies are adhered to during service publication (note that this only applies to schema policies).
Execution – the policy is able to apply and enforce policies at runtime (note that this only applies to communication and behavior policies).
So, the next time someone starts talking to you about policies in an SOA, hopefully this will help you make sense of what they are really talking about.
2 Questions: #1: Can you compare and contrast policy with standards ? #2: I can see where the quality of service is built into policy but where is the governance and compliance? How do you enforce policy?