Tips for Activating NetIQ Access Manager 4.3 Portal
The NetIQ Access Manager (NAM) tool is a great tool for providing Single Sign-On (SSO) services to both internal and external web applications for any business. Whether you need support for SAML, WS Fed, OAuth, Liberty, HTML Form Fill, HTML Rewrite, Header Injections, and Cookies, NAM is pretty versatile and can provide SSO capabilities for almost any web application out there, even homemade, internally-built, custom applications.
A pretty cool feature with NAM 4.3 and the newer versions is the portal feature that allows NAM administrators to create quick links to various applications that have been integrated with NAM. This provides end users a “one-stop shop” where they can find and access their common applications without having to store several links in a browser or trying to remember each application’s URL. If you’re working in NAM 4.3, you’ll only see a few applications that work in the portal, but rest assured that many others are supported in version 4.4 and newer.
Should you choose to continue with NAM 4.3 despite the number of supported applications, there is one quirk to be aware of; the instructions provided by NetIQ talk about deleting certain settings that are created by default when the product is installed for “demo purposes.” Specifically, the instructions say to delete 4 items from the Protected Resources of the default Access Gateway. Things like Portal_Managers, Portal_Employees, etc. However, in some of the appliance install versions, and potentially the non-appliance installs, the Portal_Public resource has a path of “/*” which essentially gives that resource power over everything under the resource’s DNS path, which in this case is the base NAM URL. The other portal resources that you are instructed to delete include more defined paths that start with “/portal/” so that they only pertain to the portal directory, whereas the public portal resource covers the entire NAM path.
This is significant because if you delete the Portal_Public resource without ensuring that another resource exists with the path “/*”, then as soon as you update your NAM settings to reflect the removed resources you will no longer be able to access the NAM Admin Console (AC). Since the Admin Console is the NAM URL with a sub-directory path that is no longer configured under the Access Gateway (AG), NAM will block access to itself. Any configured authentication contracts and resources will continue to work but administrators will be unable to access the Admin Console to manage and maintain the services.
One option is to NOT delete the Portal_Public resource since it already has the path of “/*” but remove the other resources as instructed. By leaving the Portal_Public resource, NAM will continue to recognize the Admin Console URL path that would otherwise be blocked and that would allow NAM admins to continue managing the tool.
Alternatively, you can remove the Portal_Public resource but before updating the NAM configurations. To do this, you will need to create a new resource, call it “public” or whatever you like, and give it the path of “/*”, just like the Portal_Public resource that you removed. Of course, you could also just rename the Portal_Public resource to something else if you really wanted but for those who are sticklers for details and want to follow the instructions exactly. Creating a new resource with that path will be your salvation else you will find yourself locked out of your Admin Console by your own NAM tool.