Planning_and_Impleme.. - didier beck weblog

www.butlergroup.com
Planning and Implementing SOA
POLICY AND SECURITY IN A SOA ENVIRONMENT
CATALYST
As the concept of services becomes more widely accepted, it will become increasingly important to
consider some of the security requirements surrounding them – especially to gain wider acceptance of
SOA. Simply restricting access to authorised personnel via standard access control mechanisms becomes
impossible in a service-oriented environment, and new standards are starting to evolve here.
SUMMARY
The use of policies allows abstraction of concepts to a higher level, simplifying
creation and maintenance.
Security issues for SOA are more complex than in older architectures.
Standards for SOA security and policy are starting to mature, and interoperability is
improving.
ANALYSIS
In static architectures and application development, one of the key aspects is that it is possible to hard-wire
the security. In creating a SOA with loosely-coupled components, it will be necessary to look at how security
needs to be defined and managed for that type of architecture. The same applies for other policies – in the
older architectural styles, there is the ability to implement policy at the design level. That ability is not there
within a SOA. Here it will be necessary to ensure that the message flows that pass through those
architectures actually access and interact with the declared policies at the right points within the
architecture. This is a far more complex management infrastructure, but one that is balanced by a far more
usable and far more relevant application infrastructure.
The use of policies allows abstraction of concepts such as security to a
higher level, simplifying creation and maintenance.
Policies help to ensure compliance with organisational objectives; at the highest level these are likely to be
highly business-related, and tend to cover people-related issues such as “projects must comply with internal
design and architecture guidelines”, or generically, that all IT projects are subject to reviews for security and
regulatory compliance.
Today, policies are already there in most computing infrastructures, it is just
that, where relevant, they tend to be hard coded and explicitly defined. An
example of a security-related policy is ‘passwords must be eight characters
long’ – this implies that there must be code embedded in each application to
check that this is the case. This is not practical in SOA – policies must be
specified and managed at the infrastructure level. Policies can relate to other
areas including management and monitoring.
Policies could represent more specific regulatory compliance issues; for
example, in the healthcare industry patient’s personal identifiable information
must be communicated and stored securely (in order to comply with the US
Health Insurance Portability and Accountability Act (HIPAA) legislation). In the
business sector, all financial transactions must provide traceability and
tamper-proof mechanisms for mandatory audit records (to meet with
Sarbanes-Oxley and Basel II regulations).
Policies could
represent more
specific regulatory
compliance issues; for
example, in the
healthcare industry
patient’s personal
identifiable
information must be
communicated and
stored securely...
December 2006 Section 1: SOA Deployment 19