William Bathurst

Subscribe to William Bathurst: eMailAlertsEmail Alerts
Get William Bathurst: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Related Topics: SOA & WOA Magazine, Sarbanes Oxley on Ulitzer

SOA & WOA: Article

Extending Identity Management Solutions Into a SOA

Managing and applying policies and controls to Service Oriented Architectures

Policies can then be treated independently of specific entities, meaning that they can be used and reused for different entity types. For example, you might create a policy stating that some entities can access some resources between 8:00 a.m. and 5:00 p.m. from machines outside the firewall. Then you can associate groups of users and groups of resources with that policy at any time.

Associating Policies with Entities
An association of policies with entities can be based on the entities' attributes and capabilities. Consider Figure 1

Each of the boxes in the figure represents a managed object. The entities can be users, services, devices and the like. Policies can be created to govern the interactions between these entities. Policies are made up of a set of rules, which are independent of the policies and can be assigned to be part of many policies. Policies are then associated with entities, or groups of entities, based on the entities' metadata.

Policy Association A associates Policy 1 with any entity with Metadata C or D when it interacts with any entity with Metadata Y or P.

The benefit of the combination of the dynamic nature of association and delegated administration is that corporate policies can be defined and associated at the highest level and also require adherence at a lower level. For example, a corporation might have a corporate policy that says, "All passwords must be sent over SSL." A policy defining this requirement can be created, along with a dynamic association, to force all passwords to be sent over SSL. This association wouldn't be reversible by delegated administrators.

Another concept to borrow from identity management is that of advanced groups. For example, identity management leverages the power of dynamic and nested groups. Expanding the use of traditional identity management groups beyond groups of users to include collections of policies, rules, and even associations can easily lead to an expansion of traditional "roles." Traditional roles are generally associated with authorization policies (as defined in role-based access control [RBAC]), but generalized policy management can also mean generalized roles.

All types of entities can act in a role, not just for authorization policies but also to determine which steps to take as part of a process or a company policy.

So what should an expanded policy management system look like?

Architecture for Policy Management
Policy frameworks have three main components as shown in Figure 2:

  1. A policy server: the central authoritative policy distributor
  2. A policy manage: the GUI application that allows the management (creation, validation, monitoring) of policies
  3. And a policy enforcer: the distributed policy enforcement points, such as gateways and agents
Before an entity can interact with another entity, it must first know what policies govern the interaction. Policy enforcers are part of each entity. For example, Web Services run in an application server, which should have a policy enforcement agent running as part of its process. This policy enforcement agent, which is the policy enforcer, gets policies for the Web Services it controls.

There are two ways an enforcement point can get its relevant policies:

1.  Pull: The policy enforcement agent queries the policy server for the policy expressions that govern interactions associated with the entity it's assigned to, and the policy server returns a policy document containing the policy expressions associated with a specific interaction.
2.  Push: The policy server pushes a policy document containing all the policies that are associated with an entity to the policy enforcer for that entity.

Because of different requirements for different policy enforcers, a generalized policy server must support both the push and pull models of distributing policy documents. In fact, a single interaction between two entities may require both pushing and pulling policy information. For example, Entity A wants to interact with Entity B. The policy server may have pushed Entity B's policies ahead of time. Before Entity A can interact with Entity B, Entity A may need to know some aspects of the policies governing the interaction. Entity A may query Entity B for the relevant policies, or it may query or pull the policy information from the policy server.

No current standard is sufficient to provide the flexibility necessary to express all types of policies. WS-Policy is widely used to describe Web Services policies. Authorization policies are often described by another standard called XACML. WS-Policy by itself can't describe authorization policies nor can XACML describe Web Services policies. It's unclear if it will be necessary to develop a so-called "Über" policy language capable of describing general policies.

The policy server, combined with an entity management server, can be used as an authoritative registry for entities, their capabilities, and their policies. It's essentially a Universal Description, Discovery, and Integration (UDDI) server on steroids.

Because policies can be very complex and may be created at different levels by different people, a policy server has to be able to resolve conflicting policies. Rules of precedence should be part of the policy manager application.

Identity management is evolving to satisfy the need for more generalized entity management. It must be able to address the various types of entities found in corporate infrastructures, such as persons, services, and devices. With the focus on policy, businesses have to be able to control how access is managed across all their applications easily and consistently whether they're Web-based applications or Web Services. This will provide IT with a flexible approach to managing access and applying policies across application and SOA environments.

More Stories By William Bathurst

William Bathurst is a senior product manager at Oracle with 18 years of industry experience. He is currently the product manager for J2EE security and web services management.

More Stories By Robin Martherus

Robin Martherus is a consulting member of Technical Staff within the Security and Identity Management group - part of Oracle Fusion Middleware. Robin was previously with Oblix where he was a senior developer.

Comments (1) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.

Most Recent Comments
SOA Web Services Journal News 01/12/07 02:01:21 PM EST

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.