Helpdesk applications come and go. Like Antivirus and backup products they are all horrible, except the other ones are worse. Each of those three products have good and bad features and none seem to have them all.

With the move of seemingly everything to cloud-hosted applications, helpdesk is next. (I am waiting for desktop imaging in the cloud, when we have enough bandwidth, I am sure it will happen). ServiceNow is a popular web based Helpdesk application. IDM already has connectors to Remedy ARS (Action Response System) as an example and in IDM 4.5 and change they added a ServiceNow driver. (The package requires that you install on IDM 4.5.5).

I thought it would be interesting to get back into the driver walk through series that I had left idle for a year or so with ServiceNow. You can see more of these walk throughs, collected on a Wiki page I maintain here: https://wiki.microfocus.com/index.php?title=Detailed_driver_walk_through_collection

If you have done any similar driver walk throughs, please update the Wiki with some links.

Package versions I am reviewing are:

ServiceNow Base

1.0.1.2017012414475

ServiceNow Default Configuration

1.0.0.20161202164353

ServiceNow Entitlements

1.0.0.20161202164458

ServiceNow Password Synchronization

1.0.1.20161202164618

The versions matter, since of course updates and fixes will be released over time, and better to not date myself.

Looking at the driver configuration, this looks a lot like a SOAP driver. You often can tell if the shim is a SOAP shim with some custom XSLT by the configuration. An example of that is the SAP Portal or Salesforce.com driver. This is important to know, since you can simply send SOAP through to the shim and if the XSLT internal does not remove it, it will let it through and process it.

I was helping someone in the forums with Salesforce.com and entitlements, and he wanted to know how to manage a different type of object that the shipped driver did not support. The trick was, build the SOAP you need for your event, send it to the shim and process it when returned and all is fine.

Thus if we find we need to do more in ServiceNow, it seems likely it would be possible to send it the specific SOAP document we want and have it process. This is a very useful feature that is quite underrated.

In the configuration, we have a URL for the ServiceNow endpoint, an ID and password to authenticate, and then settings for certificate security. You can either import the signing CA public key certificate into a keystore file, or else tell the shim to always accept the server certificate.

You can easily get the certificates you need by visiting the endpoint URL in a browser, and depending on your browser, click on the Lock icon and there will be some interface to view the certificate information.

The tricky bit, is that you need to get the chain of signing certificates, the root CA, the intermediate CA and potentially more. You do NOT need the certificate itself. You just want the parent signing certificates.

You can click on each level in the hierarchy and select Export. Internet Explorer exports it into the Windows keystore from which you then have to export to a file. But most other browsers let you send it to a file directly.

Once you have a file for each certificate you can build a JKS (Java KeyStore) file from them. I like 'Portecle' tool, at http://portecle.sourceforge.net for doing it in a GUI. You can always do it with the 'keytool' command that is built into Java.

Usually it is better to use the Keytool from your JVM, but it has been compatible since Java 1.6 to 1.8 so not that big a deal. The engine uses the JVM in the eDirectory distribution (Well IDM installs it inside the eDirectory binary path) so best to use that one. The default location is: /opt/novell/eDirectory/lib64/nds-modules/jre

I will assume our working files are in the /tmp directory for brevity, so a quick lesson on 'keytool'.

The base command is:

/opt/novell/eDirectory/lib64/nds-modules/jre/bin/keytool

We need to use the commands:
    -list -v (verbose)
    -import

And the parameters
    -keystore
    -storepass
    -file (path to file referenced)
    -trustcacerts (flag as a trusted root)
    -alias (nickname for certificate)

My preference is to start with a basic command, and then add commands after. This way it is easy to up arrow on the command line and work faster.

/opt/novell/eDirectory/lib64/nds-modules/jre -keystore /tmp/sn-store.jks -storepass SomePassword -import -trustcacerts -alias SN-Root-CA -file /tmp/sn-root-ca

This would import the sn-root-ca file (assuming you save the file with that name) and write it to a keystore /tmp/sn-store.jks, which since it does not exist, it just created with the password SomePassword.

Then let's get an intermediate cert as well, simply changing the file name for import and the alias name.

/opt/novell/eDirectory/lib64/nds-modules/jre -keystore /tmp/sn-store.jks -storepass SomePassword -import -trustcacerts -alias SN-inter-CA -file /tmp/sn-inter-ca

Once done, we want to make sure we got them both, we do a list:
/opt/novell/eDirectory/lib64/nds-modules/jre -keystore /tmp/sn-store.jks -storepass SomePassword -list -v

You should see the two certificates. (For fun, go look at your OSP installs JKS files, since you need to have the Tomcat, SAML federated partner, eDirectory, and OSP's certificates in there).

This driver making HTTPS calls means you might need a Proxy server configured. In the past it seems like IDM expected the system proxy to be set on the server level and that has been a mixed bag in terms of success. Here they support Proxy servers specifically to be configured, with a URL, username, and password. This is a nice step forward.

The final option is Use Custom Application Schema. This is a bit odd, since it expects the path to a file.

There are no Subscriber Configuration items, and only the Publisher heart beat setting of 1 minute on the other side. Often this is used to poll for changes, so will have to see how this driver works, to see if it matters, later in this series.

This driver can run as a Remote Loader, but do remember to copy the JKS file from above to the proper path on the Remote Loader server if you run that way. (What is the correct path? Wherever you specify it to be, but on the server running the shim (The engine or RL as appropriate).

The only ECMA object linked in is the standard NOVLIBAJC-JS with a bunch of useful ECMA functions, so nothing special used in the driver configuration.

Next up are the Global Configuration Values. There are only two GCV objects linked in, and surprisingly, the Default Configuration does not provide one.

There is a Password Synchronization and Entitlements GCVs.

The Password Synchronization GCV has two options. The Application Accepts Passwords (Sub channel password sync) and Email on failed password change. This clearly indicates that as expected this driver only can send passwords for users to ServiceNow and not pick up password changes made in ServiceNow to synchronize to IDM.

This makes sense as few web based applications will expose the user password in a retrievable fashion. In the application model, it may be possible to use an API (like the Password Complexity API in Active Directory via the Password Filters) whereas in the Cloud application model, you are at the mercy of the cloud vendor.

The Entitlements GCV is more interesting and gives us a number of options that hints at a number of features.

You may recall from previous articles on this series that the way User Application realizes a driver has Entitlements and makes them available for the Resources to be mapped is via a Code Map Refresh.

In that process, the User App queries the tree for DirXML-Driver objects, loops over that set, and queries each driver for an entitlementConfiguration object (Ironically it looks for DirXML-ContentType with the entitlementConfiguration MIME type (text/vnd.novell.idm.entitlementConfiguration xml), but only handles the specifically named object. It would be very useful if we could have multiple objects of this type as it would make adding a custom entitlement much simpler. Especially since if you want to add a new entitlement type in your own package you need to build a policy that adds the XML to the entitlementConfiguration object, after the NetIQ delivered code is finished. If you could make your own, so long at the object class and DirXML-ContentType was correct, then it would be much more flexible.

It then parses the XML inside the EntitlementConfiguratiob object for the <entitlement> nodes for information about what sort of entitlement (Static? Administrator Valued? Query based?) and handles each one. The most important case is the Query based entitlements since it will then loop over the <entitlement> nodes and perform any queries defined. This can take a while if you have a lot of results.

This GCV is used by a Startup policy that will build the EntitlementConfiguration from these settings.

The nodes look something like this:

<entitlement data-collection="true" dn="CN=Group,CN=LDAP,CN=dset,OU=idm,OU=system,O=data" parameter-format="idm4" resource-mapping="true" role-mapping="true">
	<type category="security grouping" id="group" name="group">
		<display-name>
			<value langCode="de">Gruppe</value>
			<value langCode="en">Group</value>
		</display-name>
	</type>
	<parameters>
		<parameter mandatory="true" name="ID" source="association"/>
		<parameter mandatory="true" name="ID2" source="association"/>
	</parameters>
	<native-value source="src-dn"/>
	<member-assignment-extensions>
		<query-xml>
			<read-attr attr-name="member"/>
		</query-xml>
	</member-assignment-extensions>
	<query-extensions>
		<query-xml>
			<operation-data data-collection-query="true"/>
		</query-xml>
	</query-extensions>
</entitlement>

The GCV's control the options in the entitlement node like:
    data-collection
    parameter-format
    resource-mapping
    role-mapping

There is a GCV for each of the Entitlement types so it proliferates quickly. Interestingly they did not use a structured GCV wit one instance for each type of Entitlement.

We can derive from these GCV's that there are queryable entitlements for Users, Groups, Role, and Department without even looking to see what Entitlements might be defined.

There is an Advanced Settings option, that when enabled shows a Role Mapping, Resource Mapping, Parameter Format, and Entitlement Extension that control how the policy sets the values appropriately in the generated EntitlementConfiguration object's XML.

If you look in the Startup policy set you will find the NETQSRNWENT-stp-InitEntitlementConfiguration, that on each driver startup will look at the GCV's and rebuild the XML as needed. Alas this generates a ton of trace in a driver restart. I will discuss that policy when I get there.

Now that we have looked at the GCV's and inferred the existence of the various entitlements, let's look at the Entitlement objects to see if any of them are interesting.

• Group is looking for a Group object and showing the CN attribute.

• Role is looking for a sys_user_role object and showing the name attribute.

• Department is looking for cnm_department and showing the name attribute.

• UserAccount is looking for a ServiceNowAccount object class, and uses the DisplayName as the value that is shown.

It looks like the Department Entitlement's description has a typo and says "The Department entitlement represents sys_user_role in ServiceNow". They copied the Role one and did not properly edit it I think.

The UserAccount entitlement looks for an odd object class, so that a policy can catch it and send back a simple predefined response. This is handled in the Output Transform in a policy NETQSRNWENT-otp-EntitlementImpl. This makes sense, as it seemed odd to query for a User Account, you really only have one type of user, you would expect. Though I could see a case where you have full time and part time user types, but I have yet to see a driver use that.

You see this approach in many drivers where the name of the target system is the value to select in the User App for a value for the entitlement. I strongly remember in one version of the Active Directory driver, you could select the OU you wanted the user placed in, in the Entitlement value. That would be an example of a useful query.

To replace that, I have an add on package for the Active Directory driver that adds a Placement Entitlement. It queries for Organizational Unit objects and you select the proper value for your Resource. If anyone is interested, feel free to ask.

That is about it for this article, stay tuned for more in the next one when I start looking at the filter and schema map.