We recently held an essay contest inviting Micro Focus employees and customers to describe why they love using Micro Focus products. We wanted to know how our users were using Micro Focus products to make their lives—and the lives of their users—easier. Entries were sorted into solution groups and judged by the appropriate Solution Marketer.

This entry was selected as the first-place winner in the Identity and Access Management solution group. The author, Matthew Ruane, received the first-place prize of a $350 Amazon Gift card as well as a free Micro Focus community t-shirt.

Take a look at the winning entry below.

---

 
By: Matthew Ruane

End-to-End Identity and Access Management (IAM)

 

I have noticed many discussions taking place recently, in the various social media and web outlets, on the topic of IAM. There appears to be a big difference in people's interpretation of IAM functionality and benefits.

Organizations may feel overwhelmed when they contemplate a full implementation of IAM. Almost all cloud applications require some form of IAM so I felt I would use my involvement in a cloud migration project last year to demonstrate the various IAM components and the practical steps required to implement them.

The project in question involved the migration of a number of corporate on-premise applications to the cloud. I was asked by the project team to advise them on authentication solutions (access management) for both internal and external users. I advised the project team that the organization had an IAM solution (Micro Focus IAM) in-place and this could be configured as a SAML identity provider (IDP) to talk to the cloud service provider (SP); all internal users would have single sign-on (SSO) to their desktop and externals would be asked for logon credentials.

After access management was addressed, the question of account provisioning was raised. One approach was to manually create the accounts in the cloud directory. The accounts would be created as an exact replica of their internal account i.e. user id, givenName, surname, email, employeeStatus etc must match that of the internal account. The initial user count for this project was in excess of two thousand.

From my experience this type of manual process may work for a while but in the end it will break down, the project team will be long gone and the help desk and IT support will be left to deal with the fall-out.

Issues with this approach to provisioning are:

• Big delays in granting access.

• User data integrity issues.

• Help desk workload.

• Endless hours wasted in troubleshooting.

• Security issues (base authorization was going to rely on one of the user attributes values).

Further investigations found that the cloud solution provider offered a SCIM API for user provisioning. System for Cross-Domain Identity Management (SCIM) is an open API for identity management and can allow for the provisioning of user accounts using REST. I proposed that I could configure the Micro Focus REST IDM driver to automate the provisioning process.

Solution

 
The organization already used Micro Focus identity and access management (IAM) for their IAM requirements. IDM is the identity vault and access manager takes care of cloud federated SSO.
Active Directory is the corporate desktop login directory for internal users and Micro Focus eDirectory is the corporate LDAP directory for both internal and external users.

IAM.

Micro Focus NetIQ Access Manager (NAM) V4.3

• This is the corporate access management solution so I configured an identity provider (IDP) for this cloud service provider (SP).Micro Focus Identity Manager (IDM) v4.0.2

• This is the corporate identity management solution so I configured the IDM REST driver for user account synchronization and the IDM user application with two roles.

Note: I installed an IDM 4.5 serve in the IDM 4.0.2 identity vault so I could use the REST driver.

Configuration

 
The configuration of a NAM IDP is well known and basically the same across SPs therefore in the following procedure I have included some basic high-level steps only. Similarly, the IDM user application role configuration and the supporting IDM policies are not documented in great detail. I have included more detail about the configuration of the IDM REST driver. The REST driver is a generic driver and, understandable, required customization.

Cloud Authentication (Access Management)

 
NAM was configured as the SAML identity provider (IDP) to interact with the service provider (SP)
High level IDP configuration as follows:

• Attribute set created and sends assertion containing - CN, givenName, Surname.

• Authentication response - Post binding, name ID format transient.

• Step up authentication contract - Kerberos contract which allowed for integrated SSO to the desktop for internal users. If the user account is not found in the AD (external user) then the LDAP directory (eDirectory) is used as the authentication source and the user will login with the branded NAM form.

• Password self service (SSPR) is activated for password management by external users. This is the corporate password management solution and is a component of Micro Focus IAM.

User account provisioning to the cloud (Identity Management)

 
For this project I configured user provisioning using the IDM REST driver for synchronization of accounts to the cloud directory, the IDM user application v4.0.2 for role assignment and an IDM loopback driver for user schema initialization.

IDM REST driver (user account synchronization to the cloud)

The REST driver needed to be configured to synchronize user accounts to the cloud's Oracle OIM SCIM API. The driver would need to create new accounts, update attributes, disable active accounts, enable accounts and match to an existing account in the cloud.

The Oracle OIM SCIM API operation details can be found here:
https://docs.oracle.com/cd/E52734_01/oim/OMDEV/scim.htm

The following are the required SCIM API operations:
Get User Key
Create User
Update User
Disable User
Enable User

Some additional IDM vault eDirectory schema extensions were added to map to the OIM schema. (This is not the eDirectory naming convention I used).

OIM API Attrib Name

eDirectory Attrib name

active

OID-Active (Aux class)

orgref

OID-OrgRef (Aux class)

orgvalue

OID-OrgValue (Aux class)

department

OID-Dept (Aux class)

userType

OID-EmpType (Aux class)

id

OID-id (Aux class)

schemas

OID-SCIMSchema (Aux class)

title

title

userName

CN

displayName

Full Name

givenName

Given Name

middleName

Initials

mail

Internet Email address

familyName

Surname

Phone userType

Telephone Number employeeStatus

Notes on schema:

• The OID-id attribute is returned from the API in the REST response after a user create. This is a unique identifier returned by the API. I extract this id in the published channel and update the IDM vault user. It is then sent to the API with subsequent modify events..

• The OID-SCIMSchema attribute is a multi-valued attribute with values such as - urn:ietf:params:scim:schemas:core:2.0:User and sent to the SCIM API if required.

• The OID-Active attribute is used to activate or de-activate an account in the cloud.

As an example, the SCIM API will accept the following JSON for a create user operation:

Create User

URL = https://11.111.111.11:73001/idaas/im/scim/v1/Users/
METHOD = POST
HEADERS
- Authorization = Basic eGVsc3lzYWRtOlA2c3N3b3JkM1BDTQ==
- Content-Type = application/scim json
INPUT (raw-JSON)
{
 "schemas":
 [
   "urn:ietf:params:scim:schemas:core:2.0:User",
   "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User",
   "urn:ietf:params:scim:schemas:extension:oracle:2.0:OIG:User"
 ],
 "userName": "TUSR123",
 "name": {
   "familyName": "Tom",
   "givenName": "Jerry",
   "middleName": "V"
 },
 "displayName": "Tom Jerry",
 "emails":
 [
   {
     "value": "TomJerry123@example.com",
     "type": "work"
   }
 ],
 "phoneNumbers": [
   {
     "value": "123-456-7890",
     "type": "work"
   }
 ],
 "userType": "EMP",
 "title": "Tour Guide",
 "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User":
 {
   "department": "Tour Operations"
 },
 "urn:ietf:params:scim:schemas:extension:oracle:2.0:OIG:User":
 {
   "homeOrganization":
   {
     "value": "4",
     "$ref": "https://11.111.111.11:73001/idaas/im/scim/v1/Organizations/4"
   }
 }
}

IDM REST driver Configuration

Micro Focus IDM is very flexible and there is usually more than one way to achieve the same result. Normally when I work with Micro Focus IDM drivers I rarely need to use JavaScript as I find the majority of functionality is available using the built-in tokens and xpath. This REST driver however did require some JS which I expected because it's a generic REST driver, not designed for any API in particular. To customize the driver for this SCIM API I discovered, thanks to some Micro Focus cool solution IDM contributors, that there was a JSON JavaScript library on gethub.com that could be used.

Following is the main customization I implemented in the REST driver.

Driver properties - Resources

Subscriber Channel

On the subscriber channel (from IDM to the cloud SCIM API) I created two ECMAScripts to parse the JSON: one to take care of all non-modify events and one for all modify events. I duplicated the nested actions in the NETQRESTJSON-otp-XDStoJSON policy and called one action with If operation not equal to "modify", and the other action with If operation equal "modify"
The work in the SUB channel to convert XDS to JSON is done in the Output transform NETQRESTJSON-otp-XDStoJSON. I modified this Translate XDS to JSON policy as follows:

Before change:



After change:



As can be seen above, I duplicated the do-if in the else perform actions. The first do-if is for all non-modify events and the second do-if is for all modify events. I created three ECMAscripts/JavaScripts - one for non-modifies, one for modifies and one to remove the brackets/arrays. The latter I found on the coolsolutions forums and it worked; I plugged it in and used its output as input to the scripts I created. I added the json2.js library from gethub so I could use the JSON.parse() and JSON.stringify() functions in the scripts created and made use of the reviver parameter.
JSON.parse() will convert JSON to JavaScript objects. JavaScript is then used to parse these objects and JSON.stringify() is used to convert back to JSON and returned to IDM.

Example of a modify event trace on the SUB channel.

XDS input to NETQRESTJSON-otp-XDStoJSON policy:

XXX-METADIR\Users\paddy" src-entry-id="39135" timestamp="1499210831#8">
   <association state="associated">paddy</association>
   <modify-attr attr-name="userType">
      <remove-value>
         <value timestamp="1487236827#3" type="string">Temporary</value>
      </remove-value>
      <add-value>
         <value timestamp="1499210831#8" type="string">Contractor</value>
      </add-value>
   </modify-attr>
</modify>"

JSON output from the NETQRESTJSON-otp-XDStoJSON policy returned to IDM. This is submitted to the driver shim:

<nds dtdversion="4.0" ndsversion="8.x">
<source>
<product edition="Advanced" version="4.5.5.0">DirXML</product>
<contact>NetIQ Corporation</contact>
</source>
<input>
<driver-operation-data class-name="User" command="modify" event-id="server123#20170704232715#3#1:646172f1-5cb7-4f27-b8ec-f1726164b75c" src-dn="\XXX-METADIR\Users\paddy">
<request>
<url-token association="44016"/>
<header content-type="application/scim json"/>
<value>{"schemas":["urn:ietf:params:scim:api:messages:2.0:PatchOp"],"Operations":[{"op":"replace","path":"urn:ietf:params:scim:schemas:core:2.0:User:userType","value":"Contractor"}]}</value>
</request>
</driver-operation-data>
</input> </nds>

Customization to NETQRESTJSON-otp-XDStoJSON:

Added content is in Bold

<conditions>
    <and>
    	<if-operation mode="regex" op="not-equal">instance</if-operation>
    	<if-operation mode="nocase" op="not-equal">driver-operation-data</if-operation>
    </and>
</conditions>
<do-set-local-variable name="applicationCont" scope="policy">
    <arg-string>
    	<token-xpath expression="rs:xdsToJSON($xmlInput)"/>
    </arg-string>
</do-set-local-variable>
<do-set-local-variable name="applicationContentstring" scope="policy">
    <arg-string>
    	<token-xpath expression="es:JSONRemArray($applicationCont)"/>
    </arg-string>
</do-set-local-variable>
<do-set-local-variable name="applicationContent" scope="policy">
    <arg-string>
    	<token-xpath expression="es:JSONparseADD($applicationContentstring)"/>
    </arg-string>
</do-set-local-variable>
...

<do-if>
<arg-conditions>
   <and>
      <if-class-name op="available"/>
      <if-class-name mode="nocase" op="not-equal">DirXML-Driver</if-class-name>
      <if-operation mode="nocase" op="not-equal">modify</if-operation>   </and>
</arg-conditions
…
 
<do-set-local-variable name="applicationCont" scope="policy">
    <arg-string>
    	<token-xpath expression="rs:xdsToJSON($xmlInput)"/>
    </arg-string>
</do-set-local-variable>
<do-set-local-variable name="applicationContentstring" scope="policy">
	<arg-string>
	    <token-xpath expression="es:JSONRemArray($applicationCont)"/>
	</arg-string>
</do-set-local-variable>
<do-set-local-variable name="applicationContent" scope="policy">
	<arg-string>
	    <token-xpath expression="es:JSONparseADD($applicationContentstring)"/>
	</arg-string>
</do-set-local-variable>
...

Duplicated do-if for modify events follows:

<do-if>
    <arg-conditions>
	    <and>
    		<if-class-name op="available"/>
    		<if-class-name mode="nocase" op="not-equal">DirXML-Driver</if-class-name>
    		<if-operation mode="nocase" op="equal">modify</if-operation>
    	</and>
    </arg-conditions>
…
 
<do-set-local-variable name="applicationCont" scope="policy">
    <arg-string>
    	<token-xpath expression="rs:xdsToJSON($xmlInput)"/>
    </arg-string>
</do-set-local-variable>
<do-set-local-variable name="applicationContentstring" scope="policy">
	<arg-string>
	    <token-xpath expression="es:JSONRemArray($applicationCont)"/>
	</arg-string>
</do-set-local-variable>
<do-set-local-variable name="applicationContent" scope="policy">
	<arg-string>
	    <token-xpath expression="es:JSONmodconvert($applicationContentstring)"/>
	</arg-string>
</do-set-local-variable>
…

Also set content-type to application/scim json when used in this policy.

Publisher Channel

After a request to add or modify a user is sent to the cloud SCIM API, a response is returned from the API to the IDM driver publisher channel. If this is a response from a user add, the user object ID (unique ID returned by the API) needs to be extracted and added to the IDM vault user. This value is required for future modifies to this IDM user. I created some JS (IDM policy follows) to extract the id value and update the user attribute and also set the user to active.

PUB Input transform policy set.

Added these rules to the NETQRESTDCFG-itp-AddAssociation policy

<rule>
    <description>Extract Match values</description>
    <conditions>
    	<and>
    	     	<if-operation mode="nocase" op="equal">status</if-operation>
    		<if-association op="not-associated"/>
    		<if-local-variable mode="regex" name="varMatchvalues" op="equal">. </if-local-variable>
    	</and>
    </conditions>
    <actions>
    	<do-set-local-variable name="varSchema" scope="policy">
    		<arg-string>
    			<token-xpath expression="es:getschema($varMatchvalues)"/>
    		</arg-string>
    	</do-set-local-variable>
    	<do-set-local-variable name="varID" scope="policy">
    		<arg-string>
    			<token-xpath expression="es:getid($varMatchvalues)"/>
    		</arg-string>
    	</do-set-local-variable>
    	<do-set-local-variable name="varUsername" scope="policy">
    		<arg-string>
    			<token-xpath expression="es:getname($varMatchvalues)"/>
    		</arg-string>
    	</do-set-local-variable>
    </actions>
</rule>
 
<rule>
<description>Check for association - Mod-no-Ass</description>
    <conditions>
    	<and>
    		<if-operation mode="nocase" op="equal">status</if-operation>
    		<if-association op="not-available"/>
    		<if-local-variable mode="nocase" name="varSchema" op="equal">urn:ietf:params:scim:api:messages:2.0:ListResponse</if-local-variable>
    	</and>
    </conditions>
    <actions>
    	<do-add-association>
    		<arg-dn>
    			<token-text xml:space="preserve">Users\</token-text>
    		    <token-local-variable name="varUsername"/>
    		</arg-dn>
    	<arg-association>
    		<token-text xml:space="preserve">$varUsername$</token-text>
    		    </arg-association>
    	</do-add-association>
    	<do-set-op-association disabled="true">
    		<arg-association>
    		    <token-local-variable name="varUsername"/>
    		    </arg-association>
    		</do-set-op-association>
    	<do-set-dest-attr-value class-name="User" name="OID-id">
    		<arg-dn>
    			<token-text xml:space="preserve">Users\</token-text>
    			<token-local-variable name="varUsername"/>
    		</arg-dn>
    		<arg-value type="string">
    			<token-text xml:space="preserve">$varID$</token-text>
    		</arg-value>
    	</do-set-dest-attr-value>
    	<do-set-dest-attr-value name="OID-Active">
    		<arg-dn>
    			<token-text xml:space="preserve">Users\</token-text>
    		    <token-local-variable name="varUsername"/>
    		</arg-dn>
    		<arg-value type="string">
    			<token-text xml:space="preserve">true</token-text>
    		</arg-value>
    	</do-set-dest-attr-value>
    </actions>
</rule>

Automate user provisioning

Two permission roles were created in the IDM user application; one for internal users and one for external users. These permission roles can be added to business roles later.

Next I created a role-based entitlement in a loopback driver to add the mandatory user attributes required by the SCIM API.

When the user is added to the IDM role the resource will set the entitlement which will update the user attributes required for the REST driver creation policy. The user attribute update is the event trigger that is picked up by the REST driver, which sends the user create operation to the cloud API. I considered creating a UA entitlement but at the time I was concerned about compatibility between the IDM v4.02 user application and the REST driver running on an IDM 4.5 server.

Conclusion

 
So how does this all map to IAM and what are the business benefits?

1. Security of application using SAML authentication. This is the most secure standard for cloud authentication. (Access Management)

• Ease of user provisioning. The service desk adds the user to the role and IDM automatically provisions the account. (Identity Management)

• Fast user setup. IDM is event driven so once that user is added to the role the account is created in the cloud in a matter of seconds. Workflow can also be enabled for the roles which would allow the business to approve the account provisioning without the need to contact the service desk. The role approver (someone from the business) would approve the account creation. (Identity Management)

• Attribute integrity. The users are being synchronized to the cloud directory so all attributes will contain the correct values. This is one area which can negatively affect the whole IAM solution. Attribute integrity is paramount to all applications that rely on IAM. (Identity Management)

• IAM solution from one vendor. No need to purchase a point solution. There is great benefit in having a full IAM end-to-end solution from one vendor.

This example demonstrates that there are tangible benefits, both financial and otherwise, to the implementation of IAM for even one suite of cloud applications.