NetIQ Access Manager Policies & Order of Operations

NetIQ Access Manager, formerly Novell Access Manager or NAM for short, is a cool application that allows you to configure various applications and websites for single sign-on (SSO) and other forms of access control.  You can perform authorizations that check whether the current user meets certain criteria to access a certain resource or even a sub-section of specific resource.  NAM can redirect users to different URL’s based on information in the user’s profile.  NAM can even rewrite the HTML of a protected resource for dynamic branding or URL targets for a truly personalized end-user experience all based on parameters defined within the NAM configurations.  NetIQ Access Manager, currently on version 3.2.2, is a very powerful tool for companies and while its capabilities are many it is actually pretty simple to use.

One of the key things in NetIQ Access Manager is the ability to define different types of traffic policies that can be assigned to the various resources NAM is configured to protect.  Traffic policies are generally confined to four types: roles, authorization, injection and form fill.  For the most part these policy types are fairly self-explanatory.  Role policies determine if an authenticated user meets the specified criteria to be granted a particular role for that resource, usually based on some attribute’s value or values on the user’s profile.  Authorization policies try to determine if a user is authorized or not to access the requested resource.  In some cases authorization policies can even redirect users to different URL’s.  Injection policies takes information about the current user and “injects” that information into the target resource either through the use of cookies, query strings, etc. so that the target resource can identify the user without requiring additional authentication requests, hence single sign-on.  And then there is form fill.  Form fill is just that, it monitors HTML pages for forms and will populate form fields with specified information when appropriate.  All of these policies make NAM a very versatile application.

The thing to remember when you are creating policies for NAM is that they have a very strict order of operations logic.

For every request that NAM processes NAM will always check to see if the request requires authentication and if so if there is an active session for that user.  If there is then NAM will continue to the next step but if not then NAM will require the user to authenticate before moving to the next step.  Authentication is controlled by the authentication contract assigned to the requested resource.  Authentication contracts can use one or more data stores including NetIQ eDirectory or Microsoft Active Directory.

After authentication has been performed NAM checks for any authorization policies.  It is also important to note that multiple authorization policies can be assigned to a single resource.  NAM will process the authorization policies in the order specified in the resource configuration.  As mentioned before, authorization policies can grant or deny users access to the requested resource or URL based on information in that user’s profile including redirecting users to other URL’s.

After a user is authenticated and authorized NAM then looks at the injection policies.  This is where NAM takes information like the user’s login ID, email address, password expiration date, employee status, etc.  Whatever the protected resource wants that contained within the user’s profile in the selected data store.  Most often this is down through headers or cookies but can also be done by adding query string parameters in the URL passed to the resource/application.  This is probably the most commonly used policy type in NAM.  NAM’s primary function is SSO services among resources and the identity injection policies is what really makes this application successful.

The final policy to be considered is the form fill policies.  Form fill policies are similar to injection policies but instead of injecting user attributes into the URL via query strings or using cookies from fill policies scan the HTML code of the pages on a protected resource and will automatically populate fields in the specified forms using data from the user’s NAM session profile.  Form fill policies can even be configured to automatically submit the detected HTML form after the page is loaded and the fields are populated!

Now that we understand the different policies used by NAM and the order that they are evaluated by the application let’s talk about a common “gotchas” with authorization policies.

When you define authorization policies you can create multiple rules in a single policy and then assign each rule a priority level.  The lower the priority number the higher in the priority list the rule is evaluated.  For example, a rule with a priority of 1 is considered the highest priority and is evaluated before a rule with priority of 10.  The most common problem I have seen when reviewing policies in NAM is that people often combine redirect rules with grant/deny rules.  Usually the policies are built so that the user’s permissions to access the resource is evaluated and then the next rule will redirect the user to a different URL.  At first glance, especially someone familiar with eDirectory driver development, this seems like a perfectly legitimate policy design but NAM behaves differently than eDirectory drivers so the results are often not what you want.

In the scenario above the user will not be redirected to the specified URL even though the conditions for the rule have technically been meet in the authorization policy.  The simple answer to why is that the redirect rule is never evaluated.  The answer is included in the product documentation but there are a number of different documents for NAM so unless you know what you are looking for it is easy to miss.  The official statement in the NetIQ documentation is “In such a policy, as soon as an allow match is processed, the rest of the rules are not processed and the user is granted access to the resource”.  In a nutshell what this says is that when rules are evaluated in a policy the policy evaluation ends as soon as a rule is executed.  So if you have three rules in a policy and the first rule’s criteria are met then the other remaining two rules are never evaluated.  Rule one executes and authorization policy is exited.

So how would a resource be configured for both grant/deny rules and a redirect rule?

Easy, two policies.  The first policy would be the grant/deny policy that would contain the required rules to determine access. The second policy would just be the redirect policy.  What this does is if a user is granted access by the first policy then the second policy is evaluated and the user can be redirected if required.

Another common gotcha is assuming injection occurs on a redirect.  Take for example the following scenario:

You have a website with an admin section that requires authentication (ex: and uses an identity injection policy to assert the user’s information to the website.  Upon authentication the user’s password expiration date is checked and if the user’s password is expired the authorization policy redirects the user to another URL that does not require authentication (ex:

The common mistake is that developers assume that because the user was authenticated before the redirection occurred that  the user’s credentials will be supplied by the NAM identity injection policies to the target application.  In the scenario above this isn’t the case.  Because the user was redirected before the identity injection policies were evaluated no credentials were injected.  Due to the order of operation the redirection sent the user’s browser to an URL that did not require an injection to take place.  Since the browser was redirected before the injection took place NAM stopped processing the original request ( and evaluated the new request ( which was to an unprotected resource.

As you can see it is important to remember when dealing with NAM and its protected resources to know in what order the policies are executed and what happens when a policy is executed in relation to the other policies and rules configured for that resource.  It is real easy to forget that once one rule executes that no other rules in that policy will execute and its even easier to forget that one policy can prevent other policies from ever being evaluated by changing the requested URL.  

Just remember, when all else fails, check the documentation!