|
In Service Oriented Architectures (SOA), business processes are typically implemented by passing messages between service components. These components often implement functionality which is common across multiple business processes. Component implementations and deployed component instances are potentially shared by multiple business processes which themselves span multiple business entities. This provides business value by enabling shared resources as well as centralized administration and enforcement of policies.
The processing performed by deployed components typically depends upon the “context” of the invoking business process. By context we mean a variety of things including: initiator’s identity, initiator’s authentication mechanism, initiator’s location, business process flow, etc. Essentially, context for processing a message by a component includes any information about previously performed steps in the business process. From a security standpoint we are concerned with any security specific contextual information as well as security of generic context information.
The focus of our project is to investigate security context management within the scope of Service Oriented Architectures and in particular to look at the capabilities of IBM’s middleware and platforms to support security context management in a zSeries environment.
In light of emerging regulatory requirements (Sarbanes-Oxley, HIPAA, Basel II, etc), accountability of transactions and auditability of security context information is becoming increasingly important. One aspect is the ability to accurately identify the originator and all involved participants in a business transaction and its subsequent processing steps even when that processing is performed by components hosted on platforms where those entities may not have an account. Another aspect is the ability to audit these activities consistently and associate them with the correct business process and participants. Authorization is also complicated by the need to control access based on a set of participants, each acting in some set of roles associated with the business process. Finally, the strength, method, and point of authentication must be tracked through audit records as well as for use in authorization decisions. Security context must be capable of being propagated from each component to the next in a manner that does not disclose confidential information and does not adversely affect performance.
We built a proof of concept that demonstrated the flow of security context from Client to Web Applications to Web Services to Legacy Applications. This continues to be an excellent test bed to explore the areas of management of business activities in a heterogeneous On Demand / Service Oriented Architecture (SOA) environment.
Last updated 18 Apr 2006
|
