Identity Governance with MicroFocus – Getting Started, Points to Consider

[vc_row][vc_column][vc_column_text]

Introduction

Gartner Research defines identity governance and administration (IGA) as a means to “manage digital identity and access rights across multiple systems and applications.” While this seems straightforward, most enterprises have a massive and complex digital environment.

IGA is necessary to manage and control user access across the entire organization, regardless of where and from what device, as well as provide visibility into “who has access to what.” A modern IGA solution will allow you to manage identity lifecycles, handle access requests, execute access certifications accurately and quickly across dynamic user scenarios. Benefits of an IGA solution include:

Supports regulatory requirements by strictly controlling access to sensitive information (PII, financial data, healthcare data, etc.) and simplifying the audit process (proof of compliance)

Speeds time to value by automating and streamlining provisioning and approvals for employee transitions (new hires, promotions, transfers), mergers & acquisitions (where large user population changes must be handled quickly), etc.

Mitigates risk with better access management and governance through least privilege principles (eliminating excess privileges), faster elimination of orphaned accounts (either the employee left or the account is no longer in use for another reason), and segregation of duty monitoring

Reduces cost through improving and automating manual tasks (e.g. introducing role-based access certification)

Now that we’ve established “why” IGA is a must, we’ll dive into what do you need to know/consider when implementing the MicroFocus Identity Governance product. In this blog, we’ll cover version 3.5, but these insights apply to other versions as well. 

Key points to be aware of

  1. The /opt/netiq/idm/apps/tomcat/bin/setenv.sh file in the JAVA_OPTS section can use the entry: -Dcom.sun.jndi.ldap.object.disableEndpointIdentification=true if you have certificate-related issues where the subject alternative name is not present or not resolving.
  2. The setenv.sh file is also where you will set your java heap size. By default, the file is a gig in size but should be tuned considerably higher to pull in all of the collections. One customer with 45,000 accounts increased their java heap to 8GB with 32 GB on the system for allowing additional growth.
  3. Collecting data can be intensive as it pulls in all accounts/permissions, depending on the source type. Virtual List View can be enabled to scale down the performance hit on the eDirectory/LDAP servers as you pull in data sources.
  4. The Tomcat server’s certificate should be imported into the ~/tomcat/conf/apps-trustore.pkcs12 if the certificate was not available on the initial install. If Tomcat is already installed with https working, Identity Governance will grab the certificate and pull it in.
  5. For the install, use the install scripts included as a resource on the documentation website. This saves a lot of time and brings consistency to your installation if you need to work with support.
  6. The java version should use the Zulu version specified in the documentation.
  7. If you use Postgres, it is highly recommended that you have staff that understands Postgres maintenance. There are websites (such as https://pgconfigurator.cybertec.at) that will give sample configuration values based on the amount of ram, processors, etc. Postgres has no tuning by default on install.
  8. Email templates should be imported with the same name as they were exported with as the product is expecting that same file name. Branding can be implemented by converting an image to base 64. A website such as duri.me may help in the conversation.
  9. Tomcat may need a header max size exception included in the server.xml file.
  10. If there are multiple Identity data sources, make sure that the NetIQ eDirectory is the first one configured. It needs to be number one, assuming you have eDirectory in your environment. Also note that with the merge, it is best to match based upon unique values. If those values could be mixed cases in the different systems, it is highly recommended to set them to all lower or all uppercase so that the merge of the data will find the unique values with the same case.
  11. Including data into the catalog, such as cost center, location, job codes, etc; will help others identify users based on roles, and what would be expected.
  12. Fulfillments can fulfill to one Identity source. If you have multiple identity sources, you can fulfill to one. If that identity source connects with an Identity Manager system, it will then have the potential to clean up the other sources, depending on the system being used.
  13. Using Identity Application / User App will give the greatest flexibility for complex fulfillments for a wide variety of accounts. Fulfillments are not required for certification but are great to help ease administrative burdens, etc.

Conclusion

While there is much more that can be said about this product, a proof of concept can be whipped up fairly quickly to give you a better idea of what to expect. Prior to implementing a new solution, having some key items worked out internally on how the use cases of various user types and certification process will look, will go a long way toward getting a solution up and running that will meet your requirements.[/vc_column_text][/vc_column][/vc_row]