Application Policies (hear-after called simply Policies) are definitions that are returned from a policy data store, and is used during run time by application software. In the past, these might have been hard coded parameters that were embedded within an application program. Sometimes, some of these parameters are placed into configuration files where the settings can be changed by editing these files and restarting the application (or having the application re-read the configuration file). Policies generally replace the majority of configuration data in a configuration file.

Policies can provide far more data than configuration files. A policy may refer to additional policies and applications as needed to solve advanced and/or provide for more dynamic applications.

Who would use them?

Configuration data in a centralized policy store allows an inventory of the existing configurations to exist and be managed, as well as determine what systems are actually out there in the network.

A set of policy might be created to support application data sharing among different companies - those that partner with other organizations to utilize services that provide synergistic capabilities between companies.

How are they Different than Configuration files?

• They can be far more complex

• They can be highly dynamic (other applications, from anywhere on the network can alter a Policy as required).

• They can be tied to other objects, and used by more than one application on any system within a network.

Why use a Policy?

• Centralized management - applications can be anywhere, but the operational settings are visible no matter where they are.

• Policies allow applications to be far more scalable; as you need more processing power, the added processors can share one or more dynamic policies.

• Can hold things that configuration files cannot (for example, Serialized Java Classes).

• Any program that can access an LDAP Policy Store can use or share a policy.

• Existing programs can be adapted to use a Policy in place of a Configuration File and join in as a new processing agent to a larger application solution.

• Different parts of a Policy, or groups of policies can be used by different applications at the same time.

• Any application can provide dynamic updates to one or more Policies.

• Policies can be versioned - that means that you could have different policies of the same name available at the same time, allowing applications to roll forward or backward depending on:
  • New Software Releases

  • Special Events

  • work hours/off hours

  • Holidays

  • Reaction to application load - ie. additional application processors can alter functionality based on need for support.

  • A policy can be defined for all operational interfaces. This could mean a unique policy for each unique devices. This becomes important as new features must be added. XML, which can be associated with a policy, provides a means to support new devices. This is particular important when considering the plethora of new Internet enabled devices that are appearing, especially in the area of Wireless.

Why use an LDAP Directory Server to manage Policies?

LDAP Directories allow you to store objects that inherit objectclasses. These can be used to define complex processes. An objectclass can be extended by creating your own objectclasses.

Attributes can be multi-valued, ie. there can be more than 1 value associated with an attribute. This is extreamly useful if you want to allow different applications to be able to identify what they could be operating against or groups of related data providing status.

LDAP Directory Objects can be almost anything. They can be raw data or they can be unique programs. One example is Serialized or Marshalled Java classes. Java has the ability to extend itself during run time - this method is a variation of RMI (Remote Method Invocation); A Java application can overload new classes from a Directory server that can alter the way an application operates. This capability allows a centralized Policy store to distribute application updates from a centralized source. Because versioning is available, each individual application can be brought up with the changes as needed, or only some application servers need accept the changes. Its managed from a central point.

Policy Management.

Portions of policies will be created by engineers; operational information, XML DTD's, program logic, etc. - these should not be modified by anyone except the engineering staff. Other portions are configuration related; these should be managed by the systems operations group in an organization. Lastly, portions of the policies may be updated by the applications running against the policies.

Policy Management applications need to be created to allow Operations Staff to properly configure the Policy Based applications. Other Policy viewer applications need to exist that allow the current status of the policy be viewed by anyone who needs to see it. Engineering alterations need to be provided in the form of an LDIF file that is applied as an entire entity using a script to apply it - this way it retains the entire information as provided by engineering.

Policies must be maintained within a Configuration Management system. They can become as complex as a program and casual modification may cause processing to occur inconsistently, or in a fashion that was not tested or designed to do.

Benefits - Pros

• Faster application deployment when leveraging existing applications that use the same or related policies.

• Central applications management.

• Central device management.

• Improved applications scalability - many applications can share the same policies, and provide a degree of parallelism that is hard to do in a distributed environment.

• Support Organizations have access to application operational status and conguration information.

• X.509 based Security can be brought into applications - PKI is very strongly tied to policy management. A consistent method can be created and adapted to each new application that requires it.

• Portions of applications can be disabled during run time and used for other purposes, allowing the applications to provide methods to adapt to usage loading.

• Different versions of the same named policy can be available at all times. This allows application function rollback to occur at any time. It also allows the same application in different environments to operate using different policies, allowing a rolling update to occur to multiple sites with little or no down time.

Issues - Cons

• Infrastructure must be in place.

• All systems must know how to interact with the Policy Server.

• Network must be able to support the Policy Based applications.

• Network Delays may affect Directory Access operations - the design of the applications will need to take this into account.

Configuration Management

Engineering staffs must be able to test within an environment that closely mirrors the production environment. They must also be able to identify the policy components that are not configuration related or application run time specific and develop changes that can be applied to a system that is operating (this is most effectively done with versioning of Policies).

Once developed, the Policies need to be archived into a Configuration Management System. These should be stored in LDIF format - this is text based and supported by all major Configuration Management Systems. The LDIF file can either be manually created by Engineering, or collected from the test environment using tools that are provided with the the various Directory Servers.

Redundant Policy Servers

Depending on your applications needs, the replication intervals may not need to be real-time. The issue of network availability may impact situations where your policies must be updated by a remote application server.

Your network may need to access another server anywhere on the planet in order to operate against a Policy Server. Many networks may have delays associated with them that your application will need to deal with. If this is tied to performance related issues with the network, then it is reccomended that that a policy server co-exist in the same area.

Summary

• Policies, in their simplest terms, operate very much like configuration files - something well understood by programmers, system administrators and support organizations. This makes it fairly painless to adapt to existing technologies and applications.

• New devices, such as VPN Servers, Routers, Internet Appliances and Wireless devices need to consider how to utilize policies to deploy their applications with.

• Security via PKI and policies can standardized.

• Operations is simplified as compared to having to manage configuration data on dispersed systems.

• Support can be effective because the methods and configuration can be made accessible to support organizations. This should reduce support costs and reduce down time once issues are detected.

• Engineering benefits in that they can more easily reuse and expand upon existing applications. Many parameters can be exposed to allow for improved support or application tuning.

Comments? Questions? Contact Engineering