SOA

Companies are under tremendous pressure to meet the complex business requirements found in their IT infrastructures.

For example, they need to expose their applications to external trading partners, comply with government regulations such as Sarbanes-Oxley, integrate merged companies or their own complex application environments. One common solution path that helps solve these problems is to adopt a Service Oriented Architecture (SOA), which allows companies to be more agile in meeting their business needs.

When a company begins to expose their business processes in a SOA, then they will need to ask how they will control access to their services. These interactions can be complex, since SOAs can be composed of many composite applications. These interactions can also be dynamic, where business processes can be re-routed, or modified quickly. There are a number of questions that need to be answered in this type of environment:

• How can access to these services be managed in such a dynamic environment?
• Can access management be centralized?
• Can existing identity management solutions be used to manage access to SOA services?
• Even though identity management access control was built for Web-based applications, is it powerful enough to secure services or business processes?

This article introduces a solution for managing and applying policies and controls to Service Oriented Architectures. First it looks at the need for policies and why they need to be centralized, next it will define the access and identity management problem, and then finally discuss possible architectures that can used for access policy management.

Access and Identity Management
Identity management infrastructures are used today to address access control and policy management for Web applications. Expanding them to SOAs, where policies will be applied to business processes instead of URLs, will require more sophistication and intelligence from identity management solutions.

Before considering the new requirements demanded of identity management, let's review the current state of identity management. The following definition comes from the Internet-based Wikipedia, which does an excellent job of summing up identity management:

"Identity Management (IM) is an integrated system of business processes, policies, and technologies that enable organizations to facilitate and control their users' access to critical online applications and resources - while protecting confidential personal and business information from unauthorized users. It represents a category of interrelated solutions that are employed to administer user authentication, access rights, access restrictions, account profiles, passwords, and other attributes supportive of users' roles/profiles on one or more applications or systems."

Identity management is a mature technology that provides standard features such as delegated administration, user provisioning, policy management, and access control. The security challenges for Web-based applications are very similar to those in the SOA world. They require both authentication and authorization policies, and each has its own policy store. SOA and Web application policies are created and managed with different tools, and the protocols, methods, and session-handling mechanisms of Web-based and Web Service applications differ. The ability to create, manage, and apply policies across both technologies requires advanced identity management.

Let's now drill down into the policy management component of identity management and see how it can be expanded to control access to SOAs. The following sections of this article define policy and describe a system in which policies can be applied broadly and generically across Web Services and applications.

Policies
Policy means different things to different people. Here are some common definitions:

• Rules of practice and procedure
• An established course of action that must be followed
• The set of rules that govern the interaction between a subject and an object
• A written principle or rule to guide decision-making
• A governing principle pertaining to goals, objectives, and/or activities

For purposes of this article, let's consider a policy to be a set of rules that govern the interactions between entities. An entity could be a person, device, service, and so on. This definition encompasses current buzzword technologies (such as identity management and Web Services management) and is general enough to apply to a broader range of technologies. Let's also define policy management. It can be considered the act of creating, modifying, monitoring, and enforcing policies.

Policies have been in use for some time in the Web server single sign-on world for protecting specific URLs by letting an administrator determine who can access them and under what conditions. Policies of this type, usually called authorization policies, are tightly integrated into identity management architectures in the Web server single-sign-on context. Authorization policies have made identity management one of the essential components of any IT infrastructure.

Policies are also used as integral parts of Web Service management. In this context, they're used to describe the flow of information between a Web Service client and a service. They dictate the format of a request and a response, how they are to be signed and encrypted, and so on. Authorization policies can also be included in Web Services policies.

At a higher level, an organization can have a set of business policies. These kinds of policies generally apply across organizations and describe technically abstract rules. For example, an organization's IT department might dictate that all passwords must be encrypted on the network. Such a policy doesn't describe how the passwords are to be encrypted or even where they're used. It's a very general statement of a rule.

Generalized Entity Management
Using policies to govern the interaction between entities has to take into account that each entity type often has its own policy management. For example, there are a slew of Web Service management products, with their own specialized set of ways for managing entities. They include quality-of-service monitoring to verify adherence to service-level agreements. For example, a Web Service may have a policy stating that if response times are greater than agreed on, some clients may be redirected to an alternative Web Service. Web-based applications also have their own set of policies that control their interactions with users.

Efforts underway to combine the features of different types of entity management products into generalized entity management products would bring provisioning and delegated administration to Web Service management. There's no reason to have multiple products that manage different types of entities.

Any good identity management system can be used to manage entities other than people, but the products aren't designed to manage anything else. It's not hard to imagine that an application can have its own identity when it attempts to interact with a Web Service. An application's identity is very similar to a person's. An application can authenticate itself, and it has attributes such as its location and whether it's a batch process or interacts with users. However, many standard identity attributes, such as "manager," "phone number," and "e-mail address," are specific to people and inapplicable to applications.

Generalized Policy Management
Just as the management of entities is in the process of being generalized, there's a need to generalize the underlying policy management technology to allow standardized management of existing policy types as well as future ones. At the same time, an infrastructure is necessary that can meet the specific vertical needs of each policy type.

Building an infrastructure that can administer and enforce various policy types is complex. Different policy types are usually administered and enforced by different organizations in an enterprise, managing them has required different applications, and different standards have evolved that focus exclusively on one policy type.

Policies used to be associated with a specific entity. Take, for example, an authorization policy for a Web site or a specific resource (the entity being acted on) on that site. Any person using a browser (the entity doing the acting) to access those resources had to be authorized in accordance with the authorization policy before gaining access. That authorization policy was designed specifically for those resources on that Web site. More advanced authorization engines allowed the same policy to be used for a larger set of resources on multiple Web servers.

Another example might be a process policy assigned to a specific Web Service (the entity being acted on) designating a set of steps required before and after a SOAP request coming from a SOAP client (the acting entity) can be handled.

The ideal way of managing policies would be to enable policies to be managed the same way entities are managed. Policy management will be able to take advantage of the same rich feature sets that identity management has enjoyed for some time now. Policies will be able to go through approval-based workflows, for example. Imagine that you're modifying a policy that specifies which entities can access a Web Service containing sensitive information and that your corporate security office needs to review the modified policy before it can go live. When you make the change in the policy management system and save it, it will automatically create a ticket for the security office for review and approval. The change doesn't go live until after it's approved. This is similar to the approval process built into many identity management products.

Add Your Feedback

In order to post a comment you need to be registered and logged in.

Register | Log in

Please wait while we process your request...