Access Manager attribute manipulation - Part 1


NetIQ Access Manager is a great product. One of its strong points is the extensibility in terms of look ’n feel, authentication and other customizations.

An area with less flexibility is the user data, especially when working with SAML. Access Manager generally assumes that the data in your LDAP directory has the format you need.

Our Challenge

Many customers at some point realize that the data they have in their LDAP directory is not exactly what they need for their NAM implementation. For example, a SAML Service Provider may expect your username attribute to be of the form <user>@<domain> while your LDAP directory only contains <user>. Or, simply, your users have the manager DN attribute populated, but you need to pass the manager’s full name instead of the raw DN.

Of course the LDAP schema can be extended in these cases, and an IdM system backing up NAM may be a great help. But many times this is a lot of overhead for just a small data transformation issue. Why not use Access Manager’s extensibility for this?

Our Solution

Enter the ConditionalData extension. This extension allows you to specify rules that manipulate the LDAP user data to the format you need, at authentication time, for the duration of the user’s session only.

This extension comes as an authentication class that is executed at each login. It allows conditional rules that can transform user data and write the result into a temporary user attribute in memory.

The overall rule syntax is a single line with element name and content separated by a colon, where the content is delimited by double quotes.

A sample rule may be:

condition: “not( ( ou = 'sales' ) )”,
 action: “concat( sn, ', ', givenname )”,
  destination: “myFullname”

The above rule will fire on all users that are not in sales, and then concatenate the user's surname and givenname separated by a comma. The result is stored in the temporary attribute myFullname which can be used in other policies. You can just add this name as an LDAP attribute in NAM.


Firstly, you need to download the conditionaldata extension ZIPfile containing the authentication class and JSP page.

The second thing to do, is to upload the JAR file to the IDPs that require it, into the WEB-INF/lib directory of the nidp webapp. For NAM 3.2 and higher the location is /opt/novell/nids/lib/webapp. If you want to use the debugging feature using the intermediate JSP page, upload the rule-debug.jsp page to the IDPs that require it, into the jsp directory of the nidp webapp.

A restart of tomcat is required to load the extensions.

After restarting, the new authentication class may be configured in the Administration Console:

  • Go to the IDP cluster configuration and choose Edit

  • Go to Local / Classes tab and choose New

  • Fill in a display name (ConditionalData seems good) and choose Other for the Java class

  • Enter nl.idfocus.nam.authentication.ConditionalData as the Java class path and choose Next

  • If you want to debug the rule results, create a property called DEBUG with value true

  • It makes sense to use MainJSP with value true when debugging the rules, together with JSP and value rule-debug

  • Enter the rules that you want to configure as properties of the class using New

  • Choose RULE_<number> as the Property Name for each rule

  • Enter the actual content as the Property Value for each rule

  • Choose Finish to create the class definition

Screen Shot 2014-12-09 at 16.54.57

  • Now go to the Methods tab and choose New

  • Fill in a reasonable Display name and choose ConditionalData as the Class

  • Uncheck Identifies User and choose one or more User stores

  • If desired, more rules can be added here in the properties of the method. This allows a different set of rules for different contracts.

  • Choose Finish to create the method.

  • Now the method should be added to one or more contracts, but never as the first method!

Screen Shot 2014-12-09 at 17.03.02

Note: rules specified in the Method properties are also applied. This allows you to specify a different set of rules for each contract. More on this in the next article.

Rule Options

Rules must at least have an action and a destination. Optional components are a condition and a disabled boolean flag (eg. disabled: "true"). Everything supports multi-valued attributes; from comparisons in the condition to concatenation of values in actions. When the result of an action is multi-valued, a multi-valued temporary attribute is created as the destination.

Everything that is not an action is treated as either an attribute name or, when enclosed in single quotes, a literal string. The words condition:, action: and destination: are treated as labels and the following data enclosed in double quotes as their content.

There are several options and many different actions available in this extension. The complete list is contained in the upcoming documentation which will be published in the follow-up article.

A selection of actions is listed below:

  • concat( a, 'b' )concatenate attribute a with literal string b

  • dn( a, b )lookup attribute b from the DN value of attribute a

  • replace( a, 'b', 'c' )replace all occurences of string b in attribute a with string c

  • substring( a, '0', '5' )return the first 5 characters of (all values of) attribute a

  • join( a, 'b' )join all values of attribute a into a single string, separated by string b

  • split( a, 'b' )split the value(s) of attribute a into multiple values using string b as separator

Important to remember is that almost all actions can be nested to accomplish what you need. An example may be, to concatenate two attributes that come from a DN lookup in a similar fashion to our very first example:

concat( dn( manager, sn ), ', ', dn( manager, givenname ) )

In the second, follow-up article, we will go into more detail regarding the conditions and actions. Also there is an "external data” extension for IDP external attribute configurations which will be covered. Stay tuned!



How To-Best Practice
Comment List