Planning_and_Impleme.. - didier beck weblog

Planning and Implementing SOA
www.butlergroup.com
Policies must be able to change, based on their usage over time. An example of this might be that a policy
has been defined stating that e-mails to ‘Gold’ customers must always be checked by a manager, to ensure
that they are polite, and follow guidelines for customer interactions. But how many times does the manager
actually change the e-mail when it is checked? Can a customer service representative (or automated
process) be regarded as sufficiently trusted to cut out this checking step altogether? The policy could be
applied to untrusted or new people or services, but not once trust has been established.
Policy is thus not always static. Some elements of policy are likely to be immutable (due to compliance
requirements); others are more flexible, as illustrated by the e-mail checking example above. It will be
necessary to report on policy usage and provide audit trails over time in order to provide the feedback into
an iterative improvement process. The end result is that policy specification must be separable from policy
implementation. SOA policy is an area that has seen a number of providers coming to market with products,
and then establishing relationships with, or even being acquired by the bigger infrastructure players.
When reviewing requirements for policy management and implementation, the following points should be
considered:
Policies should not be hard coded.
Policies need to be enforced in a distributed manner.
Actions and tasks should be checked against policies at run-time.
Standards in this area are still developing, but again there is a likely candidate – the WS-Policy framework,
which describes the rules, capabilities, and constraints of a Web service. The framework covers three
A policy description
can be made up of
one or more policy
assertions; examples
include service
requirements,
preferences,
characteristics,
capabilities, and rules.
specifications; WS-Policy, WS-Policy Assertions (which covers the service
properties expressed by a policy description), and WS-Policy Attachments. It
is a part of the WS-Security framework. A policy description can be made up
of one or more policy assertions; examples include service requirements,
preferences, characteristics, capabilities, and rules. Each assertion may be
required or optional – for example, a preference is likely to be optional,
whereas a rule will be compulsory. It is possible that a different policy should
apply to a service depending on where and when that service is deployed –
an example of this might be in the Financial Services sector, particularly in
securities trading, where depending on where the trade request is placed,
different legislation may apply to commissions and payment terms etc.
When assembling services into a composite application, it is necessary to
protect the whole extended ‘application’ via a policy managed solution, without altering the existing
services. Policy and security therefore need to be separately managed outside the ‘application’ layer.
Security issues for SOA are more complex than in older architectures.
When developing any application, the issue of security is one that must be carefully considered. In an
application-centric world, developers must consider security carefully, and may well need to spend a
significant part of development time within each application on this. Security within a SOA world is different
from the tightly coupled world in that security information needs to be shared, passed around, and
understood across multiple services.
A service provider does not know who or what will be accessing the service – this is the essence of decoupling.
Securing the perimeter of an organisation with firewalls, Virtual Private Networks (VPNs), or
security appliances will not work in a service-oriented environment that needs to set up new external
relationships quickly and flexibly. Even internally, a service-oriented approach still needs security issues to
be extrapolated out of the service and into the infrastructure. For this to then work across a heterogeneous
architecture, standards will be vital.
Secure access to business applications and to support integration between different applications is vital.
There are five common security requirements – identification, authentication, authorisation, confidentiality,
and integrity. On top of this there must always be an audit trail to prove conformance.
20 Section 1: SOA Deployment
December 2006