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

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.

Conclusion
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.