Des Powley, Solutions Director, Security and Identity Management, Oracle UK, Ireland, Israel and South Africa looks at combining security and SOA
The perceived risks associated with exposing a company's IT system to outside threats have traditionally deterred investment in Service Orientated Architecture. The Web Services Interoperability Organisation, which aims to promote web service interoperability across platforms, operating systems and programming languages, has aligned with vendors to address issues such as transport of data and secure messaging. Gartner predicts that by 2008, 60% of enterprises will use SOA as their ‘guiding principle' when creating applications and processes, so it is clear that as standards continue to evolve, security will play a growing role in ensuring that users can trust their SOA model.
Old technologies, new security requirement
In previous years, companies built (or bought) applications and secure access to applications. In order to provide security across these applications, it was a simple matter of just linking valid users to the applications; providing access rights, authentication and authorisation as required.
However, when it comes to SOA, it adds a whole new dimension of IT challenges. In order for SOA to work, it needs to threat multiple applications together, providing the functionality that is required on a case-by-case basis. In other words, SOA takes the business functionality of a specific application and then allows it to be ‘discovered' and subsequently used by other applications.
By its very nature, SOA relies on the concept of managing trust across business process domains or organisational boundaries, as multiple stakeholders both inside and outside the organisation have access to vast amounts of information. In contrast, security has long been inherent in enterprise IT systems, to ensure only the right people have access to information that is relevant to them.
Whilst a significant positive for business efficiency, this does present an IT security problem. The strict connections between user, application and data sources have been well and truly separated. As well as disconnecting these links, SOA also promotes reuse, sharing and aggregating of data and processes that could well extend beyond traditional groups of known users - and known uses. Increasingly, SOA is enabling processes to dynamically interact across organisational boundaries.
Put simply, business applications involved in any SOA-based application will have different identity mechanisms and security policies. It is likely that users will have different privileges for different applications. Therefore, they will need to be authenticated for each of the applications that are used by the SOA application.
This problem is underlined by the way that SOA works. Linking between applications takes place through an abstraction layer that does not provide access to local user identity validation in the applications that are accessed. In previous years, the only way to overcome this would have been for the application itself to provide access, which is extremely unlikely to be the case.
Enhanced business processes or IT security?
It appears that organisations face a dilemma. SOA is becoming a pillar of IT strategy as it has the potential to enable organisations to more effectively utilise information assets and maximise their competitive edge. SOA also promotes business agility as it encourages the sharing and reuse of information. However, SOA also introduces new forms of IT security risk. The benefits of SOA - improved information agility, competitiveness and IT alignment with the business - are viewed as a direct contrast with traditional IT security. The question has always been: “if I implement SOA strategies, am I sacrificing a level of security?”
Despite these concerns, companies are trialing SOA with more than one-sixth (17 per cent) of technology chiefs engaged in trials and more than one-third (36 per cent) weighing up whether to move to the new architecture, according to a Butler Group survey. It is clear that IT security needs to address the structure of SOA, and fast.
SOA - a new security dimension
There is an underlying problem that even when organisations have implemented fairly comprehensive access security, it is fragmented. To provide IT security for SOA requires an end-to-end identity management capability that can determine access rights for every application involved. Even organisations that have invested heavily in identity management will not be able to achieve that.
There are a number of best practice points that organisations can refer to in order to enhance their security. In order to address the siloed applications, companies need to create a single, consolidated reference architecture that is implemented across the entire enterprise. Keeping enterprise architecture artefacts simple will increase the chances that users will understand and read them, and they can be effectively enforced and updated as appropriate.
Most large companies that have been developing technical solutions for years, either internally or through acquisitions, end up with redundant teams that rely on different vendor products or home-grown solutions, while still providing the same basic functionality. Until recently, the onus had been on the developer to ensure systems were secure. Developers had no choice but to create environment ‘silos' that were extremely difficult to manage and expensive to maintain.
The SOA solution for these legacy environments and existing infrastructures are unlikely to be accommodated by a single vendor - the complications across security, management and governance are too great. The only resolution can come from industry standards to ensure vendor offerings are interoperable.
The main goal of SOA security standards is to provide a basis for interoperability across multiple products used in heterogeneous customer environments. Policies must be enacted to create and use an enterprise layer that logically centralises access to the data spread across the enterprise. This set of data provides several architectural advantages.
First, the enterprise can assert greater control over the governance and implementation of data access mechanisms. Second, clients use a consistent mechanism to access data. Third, the enterprise can design and implement a solution in a holistic fashion instead of the typical one-off models that are the norm in data integration, thereby reducing cost and improving information quality.
Finally, the underlying architecture can support data aggregation, inter-service transactions and multiple access and usage patterns, all while ensuring acceptable levels of quality of service. With this in mind, Oracle Fusion Middleware components were developed to be ‘hot pluggable' with other standards-compliant vendor platforms.
In order to protect SOA deployments, Oracle has adopted a holistic approach. This includes an identity management infrastructure (Oracle Access Manager, Oracle Identity Federation, Oracle Web Services Manager), development and deployment tools (Oracle Security Developer Tools (OSDT), JDeveloper (Java Integrated Development Environment), Application Development Framework (ADF)) and a secure, governance-aware runtime environment (Oracle Components for Java).
As part of Oracle Fusion Middleware, Oracle provides an encompassing SOA security and management solution that allows companies to control security outside applications and web services, combine transport-level and application-level protection and use a layered defence system.
Oracle, along with various other vendors, has played a key role in developing these standards to ensure the capabilities of SOA are realised.
There is little question that SOA presents some issues when managing IT security. The differentiator is the context: conventional IT applications mean that the use of the IT system, and consequently the security requirements that go with it, can be easily predicted and managed. The context is known and so the trust required is implicit. Adding SOA changes the whole dynamic of the system. The context for using the services may not be known until the service is actually being used - a totally different experience for the developers. And, as SOA allows for the aggregation of requests and services, the service provider may not ever see the full picture of who or what is using the service.
Extending IT security practices to accommodate SOA requires specialised knowledge on existing authentication, authorisation and access control processes, and how these processes must be extended to cover the demands of SOA. However, the growth in SOA will ensure that organisations develop this knowledge. If they don't, they risk being left behind by their competitors.