Tag: allowdfltlogin

In older versions of Maximo, the product would ship with the ability to process inbound messages through an anonymous super user account when the system was configured to use native Maximo authentication. The user MXINTADM, which comes configured with MAXADMIN privileges when Maximo is installed, would be used as the default account to broker any inbound traffic through the Integration Framework. This made integrating with other systems via Web Services or standard HTTP very easy; simply supply a properly formatted message to the integration framework and you can do just about anything in the system. Common tasks such as creating Service Requests and updating Purchase Order details were very easy to accomplish.

While this method offered ease, it also came with an inherent security risk. Anyone familiar with the Maximo integration framework and its messaging structure could send inbound transactions to Maximo without having to identify themselves. The transaction would show as having been performed as the MXINTADM user in the system.

Luckily, the folks at IBM identified this risk and took steps to ship the product with this feature disabled by default in recent versions. Here is an IBM support article that identifies the security risk and outlines a mitigation procedure:

http://www-01.ibm.com/support/docview.wss?uid=swg21968191

Now, let’s walk through how to check that your environment has anonymous integration access disabled, and how to disable it if necessary.

Maximo System Property: mxe.int.allowdefaultlogin

In Maximo 7.6.0.3 IBM introduced a new System Property called mxe.int.allowdefaultlogin. This property is a boolean value that controls whether anonymous access is allowed. A property value of 1 will allow anonymous access, while a property value of 0 will not. If you are running Maximo 7.6.0.3 or higher and do not have this property, you can add it through the System Properties application.

Maximo EJB Deployment Descriptor

If your environment does not have the mxe.int.allowdefaultogin property, or is at a patch level less than 7.6.0.3, then you must modify the Maximo EJB Deployment Descriptor file to disable anonymous access. This file is located in the following directory (substitute the proper Maximo home directory for C:\IBM\SMP\maximo):

C:\IBM\SMP\maximo\applications\maximo\mboejb\ejbmodule\META-INF\ejb-jar.xml

C:\IBM\SMP\maximo\applications\maximo\mboejb\ejbmodule\META-INF\ejb-jar_notf.xml

Each of these files have 4 instances of the ALLOWDFLTLOGIN environment entry. These descriptors look like:

<env-entry>
  <env-entry-name>ALLOWDFLTLOGIN</env-entry-name>
  <env-entry-type>java.lang.String</env-entry-type>
  <env-entry-value>0</env-entry-value>
</env-entry>

Change the value of 1 to 0 in each of the 4 locations within each file. Then rebuild the MAXIMO.EAR file and re-deploy the file to WebSphere.

Making these changes will force any systems that are integrating with Maximo to supply proper authentication header credentials. In environments that utilize native Maximo security, these means supplying the MAXAUTH header with a Base64 encoded username:password combination.

If you have any trouble, or have questions on how this works, please leave feedback in the comments below.