With the wide adoption of service oriented architectures (SOAs), organisations are allowing applications to be assembled
from a growing set of internal and external services that are distributed over a federated infrastructure. The re-use and shared
access to these services makes addressing security concerns a critical success factor for SOA. So what is the best approach
to SOA security? One solution to this difficult problem is to establish “trust zones” within an enterprise IT architecture, with a
policy engine that sits between service providers and consumers.
There's a new level of complexity in an SOA environment. A given user’s back on traditional (and usually less secure) approaches where services trust
request can travel through many different connected services as the user is the other services that use them. This means that once you get in the front
fundamentally triggering a business process. Identity management products door you can go anywhere. Authorisation, today, is not “path aware”: it
focus on providing a single way to identify the user to all services so that you doesn't know how the user got to the service they are trying to access. If
can determine whether the user is authorised to use a particular service. they arrived as part of a business process they are entitled to use, they
However, a business process crosses many services. So to allow a new user should be allowed to use the service. If they arrived through a different path,
to access a business process, you need to find all the services triggered they shouldn’t.
downstream by the business process and authorise the user for each service.
Even if the security team knew this information (and they don’t), adding one So it's easy to see why establishing a non-invasive framework that enables
user could result in tens or hundreds of different per-service authorisations security for services, applications and users in a trusted environment is such
to be coded into the system. And that’s assuming that the processes never a challenge. It requires a policy-driven, centralised configuration capability
change (and they always do). that can be distributed and enforced locally to comply with SOA require-
ments for federation. And ultimately, it needs a distributed policy and secu-
This level of security becomes so complex to manage that most organisa- rity service that is also able to serve as an operational visibility tool
tions rarely use identity manager information for authorisation - they fall
Real estate issues
Add to that the diverse nature of IT real estate found inside most modern model often results in the application itself being written with security capabilities,
organisations and the problem is magnified. Most enterprise IT architectures meaning that IT spends time on each and every project working on security and
consist of a large number of technologies, both bespoke and packaged and covering often creating a separate security capability for each project. This approach can
technologies such as Web services supported by many platforms, including J2EE be referred to as an application-based security model.
and .NET. This is coupled with increasingly sophisticated SOA platforms that
allow re-use of “legacy” systems. And with a large quantity of data stored and In a world where business functionality is brought together as a composite
moved around the business, operational visibility and control is difficult. process from services, there is no such notion as application-based security. In
fact, asking IT to write security into each and every service is doomed to failure
This diverse and fast changing face of IT makes it necessary to take a due to the excessive time costs and disparate use of security standards that will
non-invasive proxy based approach that complements the existing infrastructure inevitably follow. As an organisation increasingly adopts SOA over more geo-
to address these security concerns without the need for redesign of existing graphically dispersed business this security problem is exacerbated.
architectures. Indeed, best-practice is now clearly indicating that we need to
lift security completely out of services and/or applications and place it into a The open composite serviced-based model found in SOA delivers many benefits,
specialised capability. but it does not deliver a simple security model - quite the opposite. Any business
embarking on a SOA strategy must therefore consider security up-front. The
In a conventional enterprise application security set-up, each application is main issues that must be addressed in SOA around security are:
secured as a single monolithic domain and governed standalone. This security
• SOA consists of a number of collaborative services and therefore requires a • Although the message can be secured and protected while on the bus, once
messaging infrastructure to move data between these services in a reliable it leaves the bus it also needs securing.
and secure fashion.
Organisations therefore need a full SOA infrastructure product to manage the
• Messages will typically be moved via some sort of service bus, such as complexity of moving messages between services in a secure and reliable
Progress Sonic's Enterprise Service Bus and will have to visit a number of way - with encryption, non-repudiation, authorisation and authentication.
nodes along the way.
SOA is about the loose coupling of services. Although the messaging between Policy engines allow users to create a set of “rules” to describe a broad range
services can be protected by the use of an Enterprise Service Bus, the services of service requirements and capabilities. For example, a business could define
themselves - especially where they exist outside of the bus and are called via a policy for security requirement that only certain users from this specific
technologies like Web Services - must also be secured. The creation of trusted location are allowed to call a particular service. With a proxy engine provided
services and users is called “trust zoning” - where you enforce by Actional Server, policies are validated and enforced at run-time and within
(for example) a policy where only certain users are able to call a particular the context of the interaction rather than as a paper-based design time
service - and only via a certain gateway. approach which is prone to error and long change cycles.
Progress Actional is a technology that solves the problem of SOA security by
delivering trust zoning with a lightweight and efficient policy engine that sits
between a service and its consumer.
This policy engine is driven from a centralised control panel that allows our
customers to centrally design, configure and deploy policy to distributed proxies
at the same time as receiving detailed data-flow and interaction information
about the IT operational environment.
Progress Software Limited
210 Bath Road, Slough, Berkshire, England SL1 3XE
Tel: 44 (0)1753 216300 Fax: 44 (0)1753 216301 Web: www.progress.com/uk
For more information about the benefits of Runtime Governance,