MAS 9.2 User Management: Five Cutover Controls

A platform owner running a MAS 9.1 to 9.2 dry run in a non-production cluster opens the joiner feed from the HR system and finds it calling the user creation API. That endpoint belongs to one of three API families deprecated in IBM Maximo Application Suite (MAS) 9.1 and removed in 9.2, alongside workspace assignment and role assignment. The dry run stops at the first provisioned starter. MAS 9.2 user management is the part of the release most often under-scoped, because nothing looks different on screen until a provisioning path stops or an access review asks where a security group’s site access is now set.

Starting in 9.2, user and group data for authentication is stored in the Maximo Manage relational database, which removes the duplicated user data and the synchronisation process between suite applications. The upgrade migrates the required data automatically. What remains is procedural: the provisioning integrations, the environment refresh runbook and the access-request form.

The relational database is the user record in 9.2

The deprecated APIs wrote user information directly to MongoDB. The current APIs follow a transient model: data lands in MongoDB briefly, is migrated to the relational database, and the relational record becomes the single source of truth, after which the original MongoDB entries are ignored. For applications running in compatibility mode, a foundationSyncComplete flag is added to each user for each such application once the initial synchronisation with Maximo Manage has run. That flag is the artefact to look for when a user appears in one application and not another.

MAS 9.0 and earlier granted access through fixed roles such as user or administrator, with no way to narrow scope inside a role. The current APIs assign specific permissions and compose custom roles from them, which is what makes multiple administrator scopes possible. From 9.2, setting an initial role is no longer available and authorisation is administered through the APIs. A provisioning script that granted a starter the administrator role and left the rest to the functional team has no equivalent single call in 9.2.

Change in MAS 9.2	Where IBM puts it	Decision it forces
User and group data held in the relational database, suite synchronisation removed	Platform	The user step in the environment refresh runbook
User creation, workspace assignment and role assignment APIs removed	Platform APIs	Which provisioning callers are rewritten, and by when
Manage user settings: default site, self-service requisition storeroom, default repair facility, access to inactive sites	Suite > Access and usage > Users	Who sets a default site, and on whose authority
Security group access to sites and to object structures	Suite > Access and usage > Security groups	Which route carries an access change between environments
Purchasing permission by general ledger account, set when the user is created	Suite security	Where finance sign-off sits inside user creation
JSON Web Token expiry, settable beyond 90 days or with no expiry	`mas-jwt-expiry-duration` header	The rotation date for every provisioning token

Five controls for the 9.1 to 9.2 identity cutover

The caller inventory sets the cutover date

IBM’s instruction is explicit: integrations and scripts using the deprecated APIs must be updated to the current APIs before the 9.2 upgrade. The callers include the HR joiner and leaver feed, the service desk onboarding automation, contractor onboarding, any automation script that creates test users during an environment build, and the provisioning step in whatever runbook stands up a training environment. Hold that list as a named artefact with an owner per caller, and set the production window from the last caller to be rewritten and tested, not from the OpenShift maintenance calendar.

One joiner, one mover, one leaver, one contractor

IBM directs administrators to review the changes to password migration and SCIM synchronisation before upgrading from 9.1 to 9.2. The test that proves it is four people. Provision a starter through the normal identity provider path, move one user between sites, disable a leaver, and onboard a contractor whose identity sits in a different provider. Run all four in non-production after the upgrade, with the identity team in the room. The leaver case is the one that matters in an audit, so treat access removed inside the agreed window as the gate rather than as an observation.

The refresh runbook needs a scrub step

With user and group data held in the relational database, a production-to-test database copy brings live user records, group memberships and site access with it. Before 9.2, the user step in a refresh runbook reconciled two stores; the work now is to scrub and repoint a single one. Rewrite that step before the first refresh after the upgrade, name who approves the scrub, and state in the runbook what the training environment’s authentication points at.

The access-request procedure names the new screen

Two tabs that functional owners used inside Security Groups in Maximo Manage, site access and object structure access, are configured in suite security in 9.2, at Suite > Access and usage > Security groups. User settings including default site and the self-service requisition storeroom are on the Users page in the same place, under a suite navigation section now named Access and usage. Update the access-request form, the change record template and the screenshots in the administrator’s procedure. Then confirm, in the 9.2 non-production environment, which route carries each of those changes between environments, alongside the existing route for Maximo configuration.

Every provisioning token gets a rotation date

SCIM provisioning from an external identity provider runs on a token derived from a MAS API key. MAS 9.2 allows a JSON Web Token to be issued for longer than 90 days or with no expiry at all, by setting the mas-jwt-expiry-duration header, where NEVER is a valid value. A token set to never expire is a standing credential that no calendar prompts anyone to replace. Set a finite duration, record the owner and the rotation date in the credential register, and apply the same rule to the service accounts used by agents and integrations, which is the discipline set out in the note on AI agents writing to Maximo.

What stays hard

Two exceptions survive the consolidation: access assignments for the IoT tool and for Maximo Real Estate and Facilities continue to persist data in MongoDB. An estate running either one holds user data in two places, and its access review has to cover both.

Composing custom roles from specific permissions produces a more accurate access model and a longer review. An organisation that previously signed off two administrator roles now signs off a set of permission combinations, and the functional owner who approves them needs time booked for it.

Ownership does not move. Joiner, mover and leaver processing belongs to HR, the service desk and the identity team; the MAS platform team holds one step inside it. The 9.2 change does not close the gap between a leaver being recorded in the HR system and their access being withdrawn, which is a process measurement worth taking before the upgrade so the figure after it means something.

The access review is the exit test for the upgrade

For an estate on MAS 9.1, the identity change earns its own workstream in the 9.2 plan, with the caller inventory as its first artefact and the four-person provisioning test as its gate. The exit test is a completed access review, signed by the functional owner, in which a leaver’s access has been removed inside the agreed window and every provisioning token carries a rotation date. Programmes that treat MAS 9.2 user management as a release note will discover the API removals in a dry run, which is the cheap version of that discovery; the expensive version is a production window that closes with the HR joiner feed still failing. Put the access review in the acceptance criteria rather than in the post-go-live list.