Access Manager attribute manipulation - Part 2
Be sure to read the first article in this series before continuing below.
In this article:
- External Attribute extension
- Advanced Features
- Additional Actions
External Attribute extension
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:
- Go to Policies / Extensions
- Choose Upload... and select conditionaldata.jar
- Now create a configuration by choosing New...
- Choose a Name and Description
- Select Identity Server: External Attribute Source as the Policy Type
- For the Class Name, use
- Select conditionaldata as the File Name
- After saving, select the new extension to edit its settings
- Add the following options in order:
- Replica with ID 10, Mapping User Store Replica:[Current]
- User with ID 20, Mapping Credential Profile:LDAP Credentials:LDAP User DN
- User Pw with ID 21, Mapping Credential Profile:LDAP Credentials:LDAP Password
(Using the logged-in user's credentials means that all data needed should be readable by that user!)
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:
- Go to Policies / Polices / and choose New...
- Pick a Name and select Identity Server: External Attribute Source as the Type
- In the policy editor, select New / Fetch Attributes
- Provide a desired attribute name and select Data Extension /
- After clicking OK and updating the IDP cluster, the attribute is available
You will only need to create one policy, which is able to fetch all configured extensions through multiple Fetch Attributes rules.
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.
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:
- Class properties: 3 default rules
- Method 1 properties: 2 rules for external users
- Method 2 properties: 4 rules for internal users
- External Contract: Method 1 selected, 5 rules executed
- Internal Contract: Method 2 selected, 7 rules executed
This way, you can achieve maximum efficiency by limiting the number of rules that are executed at login time. The authentication class caches all ruleset combinations at first startup and after reconfiguration (IDP update), so parsing happens only during the very first login.
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.
|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