[jcombs-pointblue]

Phase 3 of docs/MCP.md: Identity Applications tools for agent keys.

Stacked on #6 (base feature/mcp-phase2), and needs DirXMLDev 0.60.0: it pins dirxmldev.version 0.60.0, which carries the new IdApps client (PointBlueTechnology/DirXMLDev#118). CI fails until that release exists, because it downloads core's released jar. Merge order: #4, #5, #6; DirXMLDev #118 and its 0.60.0 release; then this.

What's in it

• Settings > Directory > Identity Applications for agents (PUT /api/v2/directories/{id}/apps): the address, the OSP client (rbpmrest) and its secret. The secret is sealed, never returned, and required: OSP gives refresh tokens only to a client with a secret.
• Authorizing (AgentApps):
  • Making a key with a password also does one OSP password grant (the person's DN works as the username, checked on the lab). The key keeps only the refresh token, sealed with the console's key, and shows authorized.
  • Access tokens stay in memory and are renewed with the refresh token (core's IdApps), so oidpInstanceData doesn't grow per call.
  • A refused refresh (400/401) marks the key authorize-again. Its tools then answer authorize-again until the owner uses POST /api/v2/agent-keys/{id}/authorize {password} (Agent keys > Authorize).
  • If the grant fails, the key is still made, and the answer carries appsProblem.
  • Keys made with single sign-on get no Identity Applications tools: the console has no password to sign in with.
• Tools, as the person:
  • reads: my_tasks, task, my_requests, request_detail, assignments, request_definitions, request_definition;
  • changes, for a key that may make changes (editor or operator): approve_tasks, deny_tasks, start_request, request_role, request_resource.
  • Changes follow the approval setting like any other: an approval runs the Identity Applications call then, with the key's token. They're audited as apps.<tool>.
• Agent keys page: an Identity Applications column (authorized / authorize again / no) with an Authorize dialog, and a note in the new-key form.

Calls checked on the lab before building on them

• POST /assignments/list {"dn"} gives a person's assignments.
• GET /IDMProv/rest/catalog/prds?q=* gives the request definitions. On idm254 the catalog still listed two PRDs deleted from the vault (including my earlier second-approver test PRD, which is gone from the vault), so request_definition (the permission index) is the check. This is recorded in core's docs/idapps-rest.md §11.

Decision for you

Identity Applications changes need the key to carry editor or operator, so a read-only key can't approve tasks. Say if you'd rather give them their own key option.

Tests

• AgentsTest.identityApplicationsAsThePerson, against a stand-in for OSP and Identity Applications:
  • the client secret is required and never returned;
  • one password grant, with the DN, and the refresh token sealed on disk;
  • the tools offered by role;
  • reads renew the access token with the refresh token, never a second password sign-in;
  • approve_tasks waits, is approved, and the task call is made;
  • a refused refresh gives authorize-again, and authorizing with the password restores it.
• All 166 server tests and 53 UI tests pass; npm run build passes. This was run with core 0.60.0-SNAPSHOT installed locally.
• Live on idm254 with LiveAgentsAppsCheck, all steps passing:
  • the applications admin, added for the run to a scratch group mapped to editor, signed in directly and made a key, authorized with one OSP grant;
  • my_tasks, my_requests, assignments (9) and request_definitions (12) answered as the user;
  • approve_tasks for a task that doesn't exist waited, was approved, and Identity Applications refused it. This runs the whole path without starting a workflow;
  • the key was revoked, the membership removed and the container deleted.

🤖 Generated with Claude Code

[jcombs-pointblue]

Added in 1a5d9ce: the next Identity Applications tools.

• Reads: search_permissions, who_has, others_tasks, request_tasks.
• Changes, for a key that may make changes: revoke_role, revoke_resource, retract_request, and form_data on approve_tasks and deny_tasks (through tasks/v2).

They're built on the new IdApps calls in PointBlueTechnology/DirXMLDev#118. The calls are documented in the private PointBlueTechnology/idapps-rest repository.

Live on idm254 with LiveAgentsAppsCheck, all steps passing:

• a scratch role made through the catalog API, and a holder inside the user search root;
• request_role approved, and who_has listed the holder;
• revoke_role approved, and the role was gone;
• the role, the user and the run's request objects removed afterwards.

Tests: 167 server tests pass.

🤖 Generated with Claude Code