Maximo Authentication : Utilizing WebSphere's File Based Repository

Body

For today's blog I'm going to shift back from IoT and mobile topics to security, specifically I want to discuss WebSphere's file based repository and how it can be used with Maximo.

So first you ask what is WebSphere's file based repository, well just think of it as a directory of users that is local to WebSphere, it also stores your wasadmin user out of the box.  This file based repository can exist as part of a federated repository configuration and be used to store users that can authenticate to your applications and WebSphere. For anyone who has started configuring or has configured the Maximo Anywhere product, this is how MobileFirst initially stores it's Application Center and MobileFirst console users. 

The next question is  how can you use this?  One way to take advantage of this repository could be to utilize it as a test directory for Application Server Security to see how the application works and test file configuration before actually connecting your enterprise directory server.  It could also be used to store specific users, that can be kept outside of the directory.  The great thing about federated repositories is that if one repository goes down, it shouldn't affect the others, this is why I normally keep it for the wasadmin user rather then creating it on the directory server.  This way If your directory goes down, you can still authenticate wasadmin against the file based repository to get in to WebSphere and fix your directory configuration, such as when the principal users password somehow changes without anyone knowing.

On top of that recently I had a customer ask me how they can have backup users that can be authenticated in to Maximo, but exist outside their directory. What they had wanted initially was mixed mode authentication, however with a single ear file deployment this is not possible,  users would have to authenticate against a directory.   The client was using a Federated Repository configuration and still had the file based repository intact for wasadmin, so my suggestion was to use this.  We can create backup users in the file based repository that can authenticate with application server security, but are outside the customers domain. So if the domain went down they could still get in to Maximo.

To accomplish this we did the following.

1.  First we need to confirm the file repository exists,  from your WebSphere console expand 'Security' and click on 'Global Security'.  Make sure your available realm definition is set to Federated Repositories and click on 'Configure'.

From here you can see the repositories in your realm, ensure that not only do you have your directory base repository ( if configured) but also your InternalFileRepository as seen below.  If it doesn't exist you can add it back by clicking on the 'Use built-in repository' button.

2.  Next we can create our users,  so again from the WebSphere console, expand users and groups and click on 'Manage Users' and click on 'Create'.  You can fill out the required information as seen below, ensure you define an email if it is required by the user mapping.

3. Now that the user is created, again from 'Manage Users' do a search for maximobackup and you should see your user with the o=defaultWIMFileBasedRealm base appended to it as seen below.

Now at this point, if maximobackup existed in your maxuser table and was mapped to the required maximouser role you would be able to log in, however in most cases this user would not exist and would need to be synchronized in to Maximo. To do this we will create another instance of the VMMSYNC crontask to synchronize from the file repository base DN of o=defaultWIMFileBasedRealm.

4.  From Maximo,  Go To - >  System Configuration - > Platform Configuration and select the 'Cron Task Setup' application.  From here filter for the VMMSYNC cron task and open it.  Because we are syncing from the o=defaultWIMFileBasedRealm we need to use VMMSYNC so it can utilize the VMM API's to access the File Repository.

5.  Create a new cron task Instance and define a schedule as seen below.

6.   In the Parameters section for the instance,  set your principal and credential to a user with access to the File Based Repository,  wasadmin will work for this.

Principal : wasadmin

Credential : wasadmin

For the user mapping and group mapping xml all we need to do is set the Base DN to <basedn>o=defaultWIMFileBasedRealm</basedn>

7. Save and Reload the Cron Task Request and that's it!

If you have the VMMSYNC logger set up, on your next cron task run of the new instance you should see the synchronization happening against the file repository.  The data graph would look similar to what you see below where you see our maximobackup user being brought in to Maximo.

Synchronizing VMM Users: Action psdi.security.vmm.VMMPrivilagedSearchAction@ae24aade
Synchronizing VMM Users: vmmSubject Subject:
    Principal: defaultWIMFileBasedRealm/wasadmin
    Public Credential: com.ibm.ws.security.auth.WSCredentialImpl@1e4c826d
    Private Credential: com.ibm.ws.security.token.SingleSignonTokenImpl@7c2f415c
    Private Credential: com.ibm.ws.security.token.AuthenticationTokenImpl@f5d0c86
    Private Credential: com.ibm.ws.security.token.AuthorizationTokenImpl@7c963df4

24 Jun 2016 08:43:58:991 [DEBUG] Synchronizing VMM Users: VMM search results
<?xml version="1.0" encoding="UTF-8"?>
<sdo:datagraph xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance&quot;
    xmlns:sdo="commonj.sdo" xmlns:wim="http://www.ibm.com/websphere/wim"&gt;
  <wim:Root>
    <wim:entities xsi:type="wim:PersonAccount">
      <wim:identifier externalName="uid=wasadmin,o=defaultWIMFileBasedRealm" repositoryId="InternalFileRepository"
          uniqueId="5d690527-72a8-406f-8b66-ecd0da98b77f" uniqueName="uid=wasadmin,o=defaultWIMFileBasedRealm"/>
      <wim:uid>wasadmin</wim:uid>
      <wim:sn>wasadmin</wim:sn>
    </wim:entities>
    <wim:entities xsi:type="wim:PersonAccount">
      <wim:identifier externalName="uid=maximobackup,o=defaultWIMFileBasedRealm" repositoryId="InternalFileRepository"
          uniqueId="17114c6c-c377-4e8c-9fed-1285c259eadb" uniqueName="uid=maximobackup,o=defaultWIMFileBasedRealm"/>
      <wim:uid>maximobackup</wim:uid>
      <wim:sn>Howard</wim:sn>
      <wim:mail>maximobackup@localhost.com</wim:mail>
    </wim:entities>
   </wim:Root>
</sdo:datagraph>

You will also see the other users from the File Repository being brought in, if you don't want this to happen, use the user mapping to filter for just the users you want.

A couple notes:

1.  Users can't exist in multiple repositories, so if maximobackup is in my file repository it can't exist in the directory or there will be authentication failures

2.  The file repository users must be mapped to the maximouser role if All Authenticated is not defined.

3.  To allow for the File Repository to stay active if another domain in the realm goes does, you must have the following checked in the repositories configuration page in WebSphere.

"Allow operations if some of the repositories are down"

If there are any questions comments or concerns regarding this blog, please feel free to post below. I hope this was informative and for those looking practice configuring application server security with Maximo that don't have a directory server,  this is a good way to run through those configurations.