Belkast Consulting has development a reusable Framework which simplifies the integration of both Connected and Non Connected Systems with respect to NetIQ IDM. By using this Framework, you can implement the same application permission logic regardless of whether the System is connected via an IDM Connector or is completely ‘stand alone’.

The differences

A Connected System is a System which sends or receives data directly to or from the Identity Vault. It is a System which is connected to the Identity Vault via an IDM Connector. Identity Vault Objects synchronize with the Connected System; whether it is a User Object, a Group Object, a Computer Object, whatever type of Object. In the Connected System scenario Users would, for instance, be placed in one or more Groups in order to assign permissions for the Connected System. In the case of Active Directory where applications use Groups to determine access, manipulating Group Membership is key in defining application access. Not so with a Non Connected System.

A Non Connected System is a System which is not connected to the Identity Vault via an IDM Connector; it is said, therefore, to be ‘stand alone’. The Identity Vault, for all intents and purposes, is an island; the Identity Vault has User and Group data, but the Non Connected System never has knowledge of this data. Therefore, what happens in the Identity Vault stays in the Identity Vault.

Why a framework is needed

Architecturally speaking, a Framework is required so that all data processes stay identical regardless of whether the process affects a Connected System or a Non Connected System. The access rights for a Connected System are handled in exactly the same way as those for a Non Connected System. The only difference is the method by which the access changes are relayed to the end System. A Connected System is notified via the automatic synchronization of events across the IDM Connector; a Non Connected System (rather the ‘owner’ of the System) is notified via an email alert. However, the data representation in the Identity Vault (i.e. Roles, Resources, and Entitlements) is exactly the same.

The following list shows what we attempted to accomplish with the Framework:

  • DO NOT over complicate permissions to applications. The permissions are represented by Group Membership
  • Make the data representation for Connected and Non Connected Systems work exactly the same way
  • Use Roles, Resources, and Entitlements – adding an Entitlement puts the User in a Group; removing the Entitlement removes the Group membership
  • DO NOT use Entitlement Queries to external application. Store the Entitlement lookup Objects (Groups) locally in the Identity Vault

If you follow the above rules you will have implemented a solution which is supported, extensible, and easy to manage. So, you might ask, how does one go about creating a solution similar to this?

Using Entitlements for all permission logic

Regardless of whether the System is Connected or Non Connected, treat permissions to those Systems as Group Membership. Using an Entitlement Query allows the NetIQ User Application (RBPM) to tie a Group to a Resource. Since one or more Resources can be assigned to a Role, assigning a User to a Role could (and should) result in the User being placed in one or more Groups. This is where the Identity Vault logic ends and the Connected System (IDM Connector) logic takes over; either that, or an email is sent to the application ‘owner’ directing them to assign the User the appropriate application permission(s).

Custom Components

  • Q: Surely it is easier said than done to just distinguish between a Connected and a Non Connected System?
  • A: Well, yes, this is true. But Belkast Consulting have implemented a Framework to ensure that the definition of permissions to Connected, and Non Connected, Systems is defined in exactly the same way, every time. The following components are present in the Framework.

User Application Workflow

A custom built Workflow allows privileged Users to create an application ‘definition’, Connected AND Non Connected. The User defines who the owners of the application are, to which Connector (or not) the application belongs, which Groups should be ‘sucked in’ from the Connected System (or not). Basically, Connected and Non Connected Systems can have multiple applications defined. Each application is defined as an Organizational Unit in the Identity Vault. Each application permission, or set of permissions, is defined as a Group.

IDM ‘Application Manager’ Connector

This custom built Connector implements the following logic:

  • Creation of an Entitlement Object (and update of entitlement.xml) when an Organizational Unit is created
    • The Entitlement Object defines a Query which returns all the Groups under the OU which is defined as the ‘application’
    • By doing this EXACT SAME LOGIC for both Connected and Non Connected applications, the code works seamlessly for both
    • The value in the Entitlement string put on a User is oblivious to the fact that the Entitlement is for a Connected of a Non Connected application
  • Deletion of an Entitlement Object (and update of entitlement.xml) when an Organizational Unit is deleted
    • When an Organizational Unit is deleted, all Group Membership (the Groups are deleted also) and Resources are revoked
    • It is therefore extremely easy to remove the definition of an application. All the associated data on affected Users is cleaned up automatically
  • Optionally synchronize all application Groups when an Organizational Unit is created. The Groups are placed under the correct OU
  • On assigning an Entitlement to a User, places the User in the appropriate Group
  • On removing an Entitlement from a User, removes the User from the the appropriate Group
  • If an application group is deleted, revokes the appropriate Resource from all Users who were in the Group
  • If a Group is created, and the creation did not originate from a Connected System, the Group is assigned a Unique ID (DirXML-Association value)

ECMAScript for Group synchronization

This custom built script, which is shared by all Connected System IDM Connectors, converts the Entitlement Value (DirXML-Association) into a Group DN so each IDM Connector never needs to worry about parsing the value.

Identity Vault configuration

Each application is represented in the Identity Vault in the following way:

  • An ‘application’ is simply an Organizational Unit
  • Each application is assigned to a Connector (DN) or tagged as ‘Non Connected’
  • Each application is assigned one or more ‘owners’ (DN)
  • Each ‘permission’ is a Group. Each application Group is created under the appropriate Organizational Unit

During the definition of a ‘Connected’ application, the User defines where in the Connected System the application Groups are located. If applicable, all Groups in the location defined are ‘sucked in’ from the application; the DirXML-Association value on the Group is the uniqueID contained in the Connected System. For Non Connected applications, all Groups created under the applicable Organisational Unit are assigned a DirXML-Association which is uniquely generated by the Unique ID Generator Connector. Click here to see the code which is responsible for synchronising the Connected System Groups.

How do the Entitlements work

When the Organisational Unit is created, a Utility Loopback Connector (already built by Belkast) creates the Entitlement definition for that ‘application’. This allows:

  • For the display of all applications from within the User Application
  • For the assignment of a valued entitlement (just a Group) to a Resource
  • For the Resource to be assigned to a Role

The value of the Entitlement is ALWAYS the DirXML-Association of the Group; therefore, when a User receives an Entitlement, the Utility Loopback Connector (already built by Belkast) places the User in the appropriate Group. If the Group Object is a Connected System Group (it has been synchronized from a Connected System) then the User will synchronize to that application Group in the Connected System. If the Group Object is a Non Connected System Group, there needs to be logic built to send out an email. However, this is fairly straightforward because the Group Object is located under an Organisational Unit which contains the email address of the application owner (this was done using the Workflow mentioned above). The Organisational Unit is also tagged as a ‘Non Connected System’, so there should be no ambiguity.

Supported Architecture

This architecture is supported because the way in which the Groups are assigned to the User are based on entitlements (which are supported) and are not based on an ‘if then else’ rule on an application by application basis.