|What are Application Policies?
Author: Jens Moller
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?
If you have hundreds of applications that use configuration files, it is
often hard to manage them, especially if many are related to different
versions of application software running at different sites. It is often
impossible for one organization to locate all of these applications as
they tend to be managed by various groups or organizations within
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?
In their simplest form, A policy is nothing different than a configuration
file. The major differences are:
- 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
- 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
- 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
- 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?
The vast majority of policy accesses are for reading the current policy and
any related sub-policies that are required. Applications often need a large
group of attributes that define required functionality.
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.
LDAP Directory Servers store data in a way that really only allows you to
access it via LDAP (a Protocol). This is not really an issue as LDAP is
easily accessed from C/C++, Java, PHP, ADSI and thru text based LDIF
formatted Directory commands that are applied using script files.
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
- Support Organizations have access to application operational status and
- 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
- 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.
Policies are textual representations of character, integer and binary data.
Typically, a policy is created by an engineering staff. This data is pushed
into a Directory Server by use of an LDIF formatted file.
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
Redundant Policy Servers
There are many opportunities for failure if the network is unreliable.
Policies are usually stored on a different networked system from where the
application usually operates. If the application is dependent on 100% access
to the Policy Server, it will fail. For this reason, redundant Policy
Servers should exist in the networks where the applications are. Replication
is a feature of all of the major LDAP Directory Servers available - this
includes: iPlanet Directory Server, Microsoft Active Directory, OpenLDAP,
Novell NDS, Oracle Directory Server, etc.
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.
A Corporate Strategy needs to be defined where application standards that
utilize policies must be defined. Policy infrastructure needs to be put in
place - this means 2 or more LDAP Directory Servers that are set up with
replication of the policy storage trees. Management must make a commitment
to support the technology and make it a part of their long term focus.
- 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
- 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