4.1 Getting Started

The following sections explain the requirements for developing an extension and provide an overview of the possible types of extensions and an overview of how the Access Manager policy engine interacts with an extension.

4.1.1 Prerequisites

  • Access Manager 3.2 installed and configured. For detailed installation and configuration information, see the NetIQ Access Manager Installation Guideand the NetIQ Access Manager Setup Guide

  • A basic understanding of the Access Gateway Authorization policies and Access Gateway Identity Injection policies. See “NetIQ Access Manager 3.2 Policy Guide”.

  • An integrated Java development environment.

  • Copy the nxpe.jar file from the following directory of your Access Manager device to your development environment:

    • Linux: /opt/novell/nam/idp/webapps/nidp/WEB-INF/lib (for roles)

      or

      /opt/novell/nam/mag/webapps/nesp/WEB-INF/lib (for other policies)

    • Windows: C:\Program Files (x86)\Novell\Tomcat\webapps\nidp\WEB-INF\lib (for roles)

      or

      C:\Program Files\Novell\Tomcat\webapps\nesp\WEB-INF\lib (for other policies)

4.1.2 Types of Policy Extensions

You can use the policy extension API to create the following types of policy extensions:

  • Action: This type of extension allows a new action to be added to the policy. When the policy is evaluated and the conditions evaluate to true, the extension is called so that it can execute its action. The action can be a permit, deny, or obligation action.

    For example, when a user is denied access to an Access Gateway resource, the extension generates a dynamic page that is displayed to the user and updates a database with the details of the attempted access.

    Actions extensions are used in Access Gateway Authorization policies.

  • Condition: This type of extension allows a new condition to be added to the policy. When the policy is evaluated, the extension is called to evaluate the condition and is responsible for returning a True, False, or Error value for the condition.

    For example, the Acme company requires historical sales records to be available via the corporate intranet. Access to the records is granted according to regular procedures set up by the accounting department. The accounting department manages the access rights in a database that supports SQL. In order for Access Manager to take advantage of the access granting process already in place in the accounting department, a condition extension is created that queries the accounting access rights database and returns true, false, or error.

    Condition extensions are used in Access Gateway Authorization policies and Identity Server Role policies.

  • Data: This type of extension retrieves data from an external source that can then be injected into a policy and used as input for evaluating a condition or an action.

    For example, suppose a policy needs to use the role assignments made in an Oracle* database to determine whether a user is assigned an Access Manager role. The data extension could retrieve the role assignments from the database and return them in a string object that could be used by Access Manager in evaluating the condition for the Role policy.

    Data extensions can be used in Access Gateway Authorization policies, Access Gateway Identity Injection policies, Identity Server Role policies, External Attribute Source policies.

4.1.3 How the Policy Engine Interacts with an Extension

When the policy engine processes a policy, the first step is to configure the policy. The following elements can be marked as external elements in the policy:

  • Conditions

  • Data elements

  • Actions

As the policy engine is configuring the policy, it calls the extension when it encounters an external element. The engine expects the extension to return an object that is specific to the type of extension, unless an exception occurs. The object contains any data that the extension needs for processing, and the object is returned to the policy engine with the data the engine needs to continue processing the policy. For specific details, see the following:

How the Policy Engine Interacts with a Condition Extension

When the policy engine is processing a policy and encounters a condition marked as an extension, the engine instantiates an object that must comply with the NxpeConditionFactory interface. The engine then calls the getInstance method, and expects an NxpeCondition object from the extension unless an NxpeException is thrown by the NxpeConditionFactory object.

This process is illustrated in the following code snippet:

public interface NxpeConditionFactory
{
    NxpeCondition getInstance()
        throws NxpeException;
} /* NxpeConditionFactory */

During the next part of the configuration phase, the policy engine calls the NxpeCondition.initialize method, passing an NxpeParameterList object for the configuration parameters. The configuration parameters are used to initialize the NxpeCondition object and are the parameters that the extension needs for evaluating the condtion.The values for these configuration parameters are retrieved at evaluation from the NxpeInformationContext object that is passed by the policy engine.

The initialize method is guaranteed to be called before any other method, followed by a method that sets an ID for the condition.

The following code snippet illustrates this process:

public interface NxpeCondition
{
    void initialize(
            NxpeParameterList   configurationValues)
        throws NxpeException;

        NxpeResult evaluate(
                        NxpeInformationContext   informationContext,
                        NxpeResponseContext      responseContext)
                throws NxpeException;
    
    void setInterfaceId(
            String interfaceId)
        throws NxpeException;

}

How the Policy Engine Interacts with a Data Extension

When the policy engine is processing a policy and encounters a data element marked as an extension, the engine instantiates an object that must comply with the NxpeContextDataElementFactory interface. The engine then calls the getInstance() method, passing the name, enumerativeValue, and parameter as arguments, and expects the extension to return an NxpeContextDataElement object unless the NxpeContextDataElementFactory object throws an NxpeException.

The following code snippet illustrates this process:

public interface NxpeContextDataElementFactory
{
     NxpeContextDataElement getInstance(
            String    name,
            int       enumerativeValue,
            String    parameter)
        throws NxpeException;

} /* NxpeContextDataElementFactory */

During the next part of the configuration phase, the policy engine calls the NxpeContextDataElement.initialize() method, passing an NxpeParameterList object with configureParameters. The configureParameters are used to initialize the NxpeContextDataElement object and are the parameters required during policy evaluation. It is expected that the values for these configureParameters are retrieved from the NxpeInformationContext object passed by the policy engine.

The following code snippet illustrates this process:

public interface NxpeContextDataElement
{
    void initialize(
            NxpeParameterList   configurationValues)
        throws NxpeException;

    String getName();

    int getEnumerativeValue();

    String getParameter();

    Object getValue(
            NxpeInformationContext  informationContext,
            NxpeResponseContext     responseContext)
        throws NxpeException;

} /* NxpeContextDataElement */

The policy engine calls the NxpeContextDataElement.intialize() method to initialize a component in preparation for policy evaluation. Derived classes are required to implement this method. This method is guaranteed to be called before any other method is called, because it is part of object construction.

The configurationValues parameter contains a list of the configuration data required by the external ContextDataElement handler. If the context data element wants to preserve configuration data, it must maintain a reference to the configuration value parameters.

How the Policy Engine Interacts with an Action Extension

When the policy engine is processing a policy and encounters an action marked as an extension, the engine instantiates an object that must comply with the NxpeActionFactory interface. The engine then calls the getInstance() method, and expects the extension to return an NxpeAction object unless the NxpeActionFactory object throws an NxpeException.

This process is illustrated in the following code snippet:

public interface NxpeActionFactory
{
        NxpeAction   getInstance()
        throws NxpeException;

} /* NxpeActionFactory */

During the next part of the configuration phase, the policy engine calls the NxpeAction.initialize() method, passing an NxpeParameterList object with the configureParameters. The configureParameters are used to initialize the NxpeAction object. The configureParameters are those parameters needed during NxpePolicy.evaluate(). It is expected that the values for these configureParameters are retrieved from the NxpeInformationContext passed by the policy engine.The following code snippet illustrates this process:

public interface NxpeAction
{
        void initialize(
            NxpeParameterList   configurationValues)
        throws NxpeException;

The NxpeParameterList is a list of configuration data required by the external action extension. If the action extension wants to preserve configuration data, the extension must maintain a reference to the configuration value parameters.

The second method called is the setInterfaceId method, which sets up a value for trace evaluation. The interfaceId parameter sets a unique sting value for the action. The following code snippet illustrates this last step in the NxpeAction interface.

    void setInterfaceId(
            String   interfaceId)
        throws NxpeException;

} /* NxpeAction */

The policy engine calls the doAction method to initiate the action. It has the following parameters:

  • The informationCtx parameter contains the policy enforcement Point information context to query for values

  • The responseCtx is a reflection object for communicating detailed response information back to the application. This is additional information and does not replace the need to place an action completion status in the return value from this call.

This method returns an NxpeResult, which contains an error code, permit, deny, or obligation. Derived classes are require to override this method to implement the supported action.

The following code snippet illustrates this process:

    NxpeResult doAction(
            NxpeInformationContext  informationCtx,
            NxpeResponseContext     responseCtx)
        throws NxpeException;