Application Delivery Management
Application Modernization & Connectivity
CyberRes
IT Operations Management
Be sure to read the first article in this series before continuing below.
In this article:
The extension - in contrast to the authentication class - can supply the value(s) for one attribute only. Also, it cannot benefit from internal Access Manager data connections and such.
Configuration of the extension is a lengthy but straight-forward set of steps:
nl.idfocus.nam.extension.ConditionalDataFactory
You can then add any number of rules, starting with ID 30, using Mapping String Constant and named however you like.
Just remember, this extension can only return one attribute, so the result of all rules will be combined into one (multi-valued) result. Because the extension is used in a policy, there is no need to specify the destination attribute name - it wil be ignored if you do.
Now there are two things left: distribute the JAR file and use the extension in a NAM policy. To distribute the JAR, simply select the just-created extension in the list and choose Distribute... in the menu. The JAR will then be copied to all IDPs. Note that if you do this, the authentication class is also automatically copied to all IDPs.
To start using the extension, create an External Attribute policy that will use it. The steps for such a policy are:
All in all, the extension is a lot more work than the authentication class, more expensive performance-wise and it provides less functionality. However, you remain within the normal NAM SDK.
All of the different actions fully support multi-valued attributes. However, sometimes you may want to limit the set of values that is returned to only those that match a certain string or expression.
Enter the filter()
action. This action is able to filter the list of values depending on one or more expressions. For example: filter( memberOf, 'Security', 'Access' )
returns only the groups that the user is a member of, whose DN contains "Security" or "Access".
Most actions are capable of nesting another action. The level of nesting is not limited, except maybe at a practical limit of readability.
To show deep nesting of actions, we will use the following example: you want to limit the result to only the saMAccountNames of groups that the user is a member of, that start with "app", and you want to join them into a single pipe-delimited value. Your action will look like: join( filter( dn( memberof, samaccountname ), '^app' ), '|' )
Yes, that actually works.
The properties of the authentication class allow you to specify a set of rules. However, the Method also allows you to specify a set of rules in its properties.
Using this functionality, it becomes possible to specify a different set of rules for each authentication contract, provided they use different Methods. For example:
Some additional actions that are useful in more complex nested action sets are listed in the table below. These mostly ensure that the data is presented properly.
Syntax | Description |
length( action ) | Return the length of the contained action's result. Must be a single value. Useful for substring(). |
lower( action ) | Convert all values in the contained action's result to lowercase. |
trim( action ) | Remove trailing / leading space from all values in the contained action's result. |
upper( action ) | Convert all values in the contained action's result to uppercase. |
Hopefully people will find these extensions useful for their deployments. If you are doing very cool things with them, or you are just missing that one feature in order to do so, please let me know at mvreijn at idfocus.nl