Access Governance Suite

From MicroFocusInternationalWiki
Revision as of 15:09, 1 August 2018 by Geoffc (Talk | contribs) (Created page with "{{TOCright}} Micro Focus International Wiki  |  Micro Focus Community  |  Knowledge Partner Program  | &nbsp...")

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Micro Focus International Wiki  |  Micro Focus Community  |  Knowledge Partner Program  |  KP/Geoffrey Carman  |  User App Log Levels

If you are familiar with Microfocus/NetIQ/Novell Identity Manager then you will be familiar with many of the features in Identity Governance. The focus of Identity Manager is to provision and manage users in multiple systems. Initially this was all automated, via HR data or the like. This expanded greatly with Roles and Resources so that users can both request, but also allow approvals/denials in the flow of those requests.

The main goal of Identity Goverance is to 'govern' that system. That is, just because someone has certain access does not mean they really should. Perhaps they have permissions they got in a previous job role that was never removed. Perhaps there are some historical anomalies that led to this odd set of rights a user has acquired.

The initial versions of this product were called Access Review for just this reason. But there is much more to the product. Once you have collected all the data (users, accounts, permissions, access) from all the relevant systems, you can start to review it. At this point, how do you fix things that need to change? Well there is a whole fullfillment model. Perhaps it is manual and sends an email that stays unresolved until a link is clicked to confirm it is done. Perhaps you write straight to a data source to make the change. Perhaps you kick of an IDM Workflow. Lots of options.

Put all that together, review, fixing things, and then checking again for completion (Just because they said they fixed it does not mean they really did) and you have a cycle you call a Certification Campaign.

Then there are a bunch of fun frills like Business Roles and Role Mining, where you can determine that 90% of your users have the same basic set of permissions. This might consist of 10 different permissions. Reviewing all 10 every campaign can be painful and time consuming, whereas coallesciing that set into a Business Role and approving or revoking just the Role can be much simpler. (One versus ten should be obvious why that is.)

Some of these Roles will be obvious and easy to define, but others will be harder to discover, so the product can Mine for them. That is, look for commonly occuring patterns of permission sets and allow you to examine, tweak, and then create appropriate Roles from them.

All that being said, here we have another product to manage and learn how it works at a level, that allows us to understand it and troubleshoot it.

Enabling logging

The logging configuration is not in the GUI, like it was in User Application (login as a User App Administrator, Administration tab, and then Logging side tab), nor in the file in tomcat/bin as for OSP. Rather it is in the tomcat/conf directory in the file: /opt/netiq/idm/apps/tomcat/conf/ig-server-logging.xml

Some examples of entries in that file are:

<logger additivity="true" level="DEBUG" name="com.netiq.iac"/>

       <logger additivity="true" level="DEBUG" name="com.novell.soa"/>
       <logger additivity="true" level="INFO" name="com.netiq.iac.AuthPermissions"/>
       <logger additivity="true" level="INFO" name="com.netiq.iac.server.admin"/>
       <logger additivity="true" level="INFO" name=""/>
       <logger additivity="true" level="INFO" name=""/>
       <logger additivity="true" level="INFO" name="com.netiq.iac.server.spi"/>
       <logger additivity="true" level="DEBUG" name="com.netiq.persist"/>

You can see there is name XML attribute for the name of the class to log. There is a level XML attribute that can be one of these values:

  • INFO
  • ALL
  • FINE

Now lets list off each logging class and see if we can get people to add in examples of where they used each log level to troubleshoot a specific issue. If you could include trace examples as well that would be great.


This is a parent class and includes tracing all the child classes, so this one gets very verbose, very fast, so take care when enabling this one. As you will see some of the subclasses are called out as examples in the file (like iac.AuthPermissions and so on).




This setting is quite useful as it shows the REST requests and responses made. This makes it clear that the IG-Client, the user interface, is talking REST to the IG-Server for all display data.



This seems to include database operations, usually through Hibernate and generates tons of trace as this product makes many database calls throughout. I would not enable this one unless you have a specific database problem as it clogs the log and is pretty hard to read.

Or put another way, I had a database issue, and I enabled this, but it was also the very first thing I turned off once I figured out my issue.