Highlighted
Knowledge Partner
Knowledge Partner
111 views

Permindex clustering - to what end?

Was looking at the docs and found this link:

https://www.netiq.com/documentation/identity-manager-47/setup_windows/data/enabling-the-permission-index-for-clustering.html

 

which nicely explains HOW to enable Perm Index clustering.  And implicitly how to turn it off.  But it does not mention WHAT Perm Index clustering is, or why you would do that.

The Permindex as far as I understand it is a Lucene index, with the Solr search engine, buried deep inside the idmdash.war app.  Its configuration is built into the WAR.  You can see it at start up wihen you see a report that rbpm.roles, rbpm.resources, and rbpm.prd permissions are loaded.  Usually 2-3 minutes AFTER tomcat reports it is properly started.  This basically queries (through the UA driver?  LDAP direct? Unclear) the vault for all 'permissions'  That is Roles, Resources, and PRD's so that in IDM Dash when you Request access you hope to search against Lucene (permindex) which is way faster than an LDAP query.

Lucene is designed for fast free form text searches.  LDAP is designed for fast directory queries.  The Request Access query is a free form text search not a directory query so it is a better fit.

Once you get into Request on Behald/For Others it is a different world since now we need to see if you have permissions to request this role.  (Looking at the nrfAccessMgrGrantRole style permission to see if you have rights to grant this role to someone else or not.  It uses the LDAP Proxy bind functionality in eDir 9.x instead of the NMAS SAML connection to eDir which is of interest) to check effective rights to all the  various objects that meet your query results for some attributes.

Teams for permissions appear to somehow use the Lucene index better. (Maybe a Team with static permissions can cache those permissions into Lucene?  I dunno.  Unclear but if you have permission performance issues on Request On Behalf, make the people members of the TEam and grant the team permission.  It can make a huge performance difference).

The UA driver, events on Roles/Resources (add/modify but NOT rename/move) and sends them into the UA web app which actually updates the Permindex.  So new roles/Resources get added.  Renames/moves do not.  In theory you could add a Sub-Etp and ocnvert move/renames into modifies which might update the Lucene index.

The permindex is recreated every WAR restart so you can delete it at will. Do check its size, a customer with 350K Roles/Resources was talking up 6GB of disk space!!!

So that is a quick mind dump of everything I know about Permindex.

So how does Clustering fit into this?  Seems like each instance would have its own copy.  Not sure how clustering would help?  (I guess a modify on UA driver would only send to one node?  Which would sync to second/third node?  I guess...  But I suppose seems like we would need more info.)

The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.