A.3 Concepts

The Java sample files delivered with this SDK demonstrate a basic data value filter that enables you to extract part of an identity data item from a source data repository, then inject it where it is required by a target resource using a policy you create in Novell Access Manager.

For example, examine the following string from an attribute called the acmeDiamondAccount attribute:

 1#0#1#9999999920510000101#atlantis24@acme.com#Atlantis user24#
  ^ ^ ^                   ^                   ^...............^

You could use a regular expression filter to extract the value (Atlantis user24) specified between the fifth and sixth # delimiters in a string.

The Access Manager interface allows you to retrieve the username and password from the authenticated user. With this information, you can bind to the data repository as the user, get the acmeDiamondAccount attribute, filter out the data you want, and return that as the data to be injected. The Access Manager components are then configured to inject the data into a header (or query string) and send it to the Web server.

Consider the following concepts as you design your identity injection plug-in:

A.3.1 Identity Injection Architecture

Figure A-1 shows the overall architecture of the Novell Access Manager Java plug-in, and how it is able to inject data into your Web applications.

Figure A-1 Novell Access Manager Java Plug-in Architecture

The Access Gateway and Embedded Service Provider reside on a common server and are linked by a SOAP interface. In the SOAP interface for identity injection, there is a configure process and an evaluate process that occurs between the two services. When an evaluate request comes across, an Embedded Service Provider-based policy engine is configured to call your external Java module.

A.3.2 Understanding the Java Identity Injection Plug-In

The Java module performs two main tasks:

  • Looks up almost any identity data you want from a wide range of data sources.

  • Returns the requested identity data in a specified string format to the Access Gateway. The Access Manager components then inject this data into an HTTP request header or the HTTP request query string.

The Java plug-in expands your ability to extract identity data from proprietary data sources. Access Manager supports three types of LDAP directories: eDirectory™, Active Directory, and Sun One. The plug-in allows you to use other types of data sources such as an SQL database. The plug-in also extends the formats for data to formats not provided in standard Liberty attributes, credential profiles, or other LDAP user stores. The plug-in enables you to tailor the process of accessing, returning, and injecting user identity data for specific needs you might have that are beyond the services provided in the core Access Manager product.

For example, you might want to search an LDAP attribute to gather selected user identity information from a data store, then return only specific data using an Access Control List (ACL) to inject your required user data to the back-end server. This is just one of many scenarios where you might use the Java plug-in to customize the basic data injection services provided by Access Manager.

In practical application, a user makes a request to the Access Gateway using a browser. The Access Gateway, via the SOAP channel, gathers all of the information it needs from the Embedded Service Provider for identity injection. The Access Gateway then forwards the requested data to the Web server. According to the requirements of your Web service, the data might be injected into custom headers, the auth header, or the query string.

A.3.3 Understanding Policy Configuration

The conditions and rules by which the plug-in functions are controlled by the Access Gateway, which serves as a Policy Enforcement Point (PEP). In this role, the Access Gateway evaluates the user data and the conditions of the data to determine access to a desired resource according to defined Policy Decision Points (PDP). The PEP also requests the PDP to configure the policy and to keep track of it by logging its condition and actions, then later evaluates it.

For more information about creating and managing policies, see “Policy Management” in the Novell Access Manager Administration Guide. Figure A-2 shows an example list of policies that you might see in the Access Manager Administration Console:

Figure A-2 User-Defined Policy Enforcement Points for Access Manager

When a policy is evaluated, the PDP goes through the list of defined rules in priority order, as shown below in the Rule List:

For identity injection, the PDP evaluates all of the injection policies in the order of priority (from 1 to 10) that was specified when the policies were defined.

When the policy is enabled, users are either granted or denied access to the resource, or some other action might be triggered depending on the rules configured by a policy.

A.3.4 Understanding Your Data Requirements

Before writing a custom Java plug-in, you should assess whether the desired result can be obtained by mapping data from external data sources into an Access Manager Liberty Profile attribute or by using the native LDAP Profile. For more information about these procedures, see Configuring Liberty Web Services.

By using the mapping functionality of the Identity Server, administrators can transform attributes from SAML assertions and LDAP attributes into data elements used in role establishment, authorization, identity injection and form-fill policies. Because this method of extending the data model for a policy is supported natively by the Identity Server, it is the recommended method and should be fully explored before deciding to write a custom data filler.

If using these native services is not possible for your application, decide specifically what your Web application requires before building the plug-in. What data does the service require in a particular header file and in what format? In other words, your application data requirements are driven by the back-end Web services that you provide.