™ / mcp servers
Menu
MCP servers / Identity and access

midPoint

midpoint

Looks up identities, access and server tasks in Evolveum midPoint, requests roles, claims and decides approvals, and reports recent failures, with every call running as a real midPoint user through its REST API.

Try the approval inbox and access views in a simulated chat, with sample data. Open the demo

Status
Released
Version
v0.5.0
Tools
38 in 3 roles
Wraps
Evolveum midPoint (identity governance) over its REST API
License
Apache-2.0
Works with
midPoint 4.10
Repository
github.com/Strazahq/midpoint-mcp-server
On this page5 sections

Roles and tools

Three suggested application roles, split by risk; each reaches only this server. Risk comes from the server-side gates on its write and admin tools and what each tool does, read in its code.

midpoint-readRead only23 tools

Look-ups, the caller's own and expiring access, the approval inbox, team lists, server tasks, recent failures and audit search. No side effects.

  • pingCheck connectivity to midPoint and report the authenticated identity (calls GET /ws/rest/self).
  • whoamiReport the identity midPoint executes as, how it was established (personal = the server's configured credentials; resource-server = a validated per-request end user), and the orgs that identity is linked to.
  • search_usersFind midPoint users by free-text query (name, full name, or email) or by exact OID.
  • get_userFetch a single midPoint user by OID (identity attributes and status).
  • get_user_assignmentsList a user's direct assignments and effective role membership (each flagged direct or inherited): what they have and why, with where each assignment came from (who requested and approved it).
  • list_rolesList midPoint roles (name, display name, description).
  • get_roleFetch a single midPoint role by OID.
  • list_resourcesList midPoint resources (connected systems).
  • get_resourceFetch a single midPoint resource by OID, including connection status where reported.
  • list_requestable_rolesList requestable roles (self-service, or for a report via forUser): roles flagged requestable in midPoint's catalog, filtered to what the caller is authorized to see.
  • list_my_requestsList approval cases the authenticated user initiated.
  • list_work_itemsList the authenticated user's approval inbox: open work items assigned to them, and open work items offered to a group they belong to that nobody has claimed yet (offered: true, with offeredTo naming the group; midPoint shows those only to people allowed to read them).
  • get_caseFetch an approval case by OID, including its work items.
  • search_objectsFiltered search across midPoint object types (orgs, resources, roles, services, shadows, users) using a midPoint query-language filter, the building block for ad-hoc reports (orphaned accounts, unused roles, disabled users with access).
  • search_auditQuery the midPoint audit trail (who changed what and when, logins, approvals) over a time range with optional initiator, target, event-type, outcome and channel filters.
  • list_my_teamList the authenticated user's direct reports: the members of the orgs they manage (empty if they manage none).
  • list_my_managersList who the authenticated user reports to: the managers of the orgs they are a member of.
  • list_my_teammatesList the authenticated user's peers: the other members of the orgs they belong to (the caller is excluded).
  • get_my_accessList the authenticated user's own access: direct assignments with their dates and where each came from (who requested and approved it), and effective role membership (each flagged direct or inherited).
  • list_expiring_accessList the assignments that end within the next days (default 30) for the authenticated user and their direct reports (the members of the orgs they manage, as list_my_team), soonest first: whose access, which role, when it ends.
  • list_recent_errorsAnswer "what failed in the last hours?" from five sources, each checked on its own: failed tasks, accounts with failed operations, dead accounts and pending operations, systems that are not up, and audit records of failed executions.
  • list_tasksList the midPoint server tasks (reconciliations, live syncs, recomputes, scanners) you may read, filtered by name, execution state, result status and when the last run finished.
  • get_taskFetch one midPoint server task by OID: its state, owner and kind, the status and message of its last run's operation result, the items it processed by outcome, and the last item that failed.
midpoint-writeChanges data4 tools

The caller's own role requests and withdrawals, and claiming or releasing approval work items offered to their group. Nothing here decides a request; midPoint's approval policy does.

  • request_roleRequest a role for yourself or a report.
  • cancel_requestWithdraw your own open approval request.
  • claim_work_itemClaim an open approval work item offered to a group you belong to (offered: true in list_work_items), so it becomes yours to approve or reject with decide_work_item; the rest of the group can no longer claim it.
  • release_work_itemGive an approval work item you claimed (claimed: true in list_work_items) back to the group it was offered to, undecided, so anyone in the group can claim it.
midpoint-adminAdmin and destructive11 tools

Creates, enables and disables users, changes role assignments, recomputes, decides approvals, runs, suspends and resumes server tasks, and tests resource connections. Straza's eval stack holds the user, assignment and approval calls for an approver.

  • create_userCreate a new midPoint user.
  • enable_userEnable a midPoint user (activation to enabled).
  • disable_userDisable a midPoint user (activation to disabled).
  • assign_roleAssign a role to a user.
  • unassign_roleRemove a user's assignment to a role.
  • recompute_userRecompute (reconcile) a user so midPoint re-evaluates policies and propagates changes.
  • decide_work_itemApprove or reject an open approval work item assigned to the authenticated user, with an optional comment.
  • run_taskRun a midPoint server task now (midPoint's "Run now"): starts a runnable or closed task at once; a recurring task then continues on its schedule.
  • suspend_taskSuspend a midPoint server task: a running task stops after its current item (midPoint waits up to 2 seconds) and a scheduled one stops being scheduled, until resume_task.
  • resume_taskResume a suspended midPoint server task (or a closed recurring one), so it runs or is scheduled again.
  • test_resourceTest a midPoint resource's connection (midPoint's "Test connection"): the connector's initialization, the connection to the target system, its capabilities and schema.

Register with strazad

Installing also creates the server’s administration role, mcp-admin-midpoint, which your IGA can assign to the people who maintain it.

  1. Install the manifest below.
    shell
    strazactl apps install -f midpoint.yaml
  2. Each person connects their own account once, from the Credentials tab of their Straza self-service page. A call with no connection is denied.
  3. Create the suggested roles.
    shell
    strazactl roles create midpoint-read --app midpoint \
  --tools ping,whoami,search_users,get_user,get_user_assignments,list_roles,get_role,list_resources,get_resource,list_requestable_roles,list_my_requests,list_work_items,get_case,search_objects,search_audit,list_my_team,list_my_managers,list_my_teammates,get_my_access,list_expiring_access,list_recent_errors,list_tasks,get_task
strazactl roles create midpoint-write --app midpoint \
  --tools request_role,cancel_request,claim_work_item,release_work_item
strazactl roles create midpoint-admin --app midpoint \
  --tools create_user,enable_user,disable_user,assign_role,unassign_role,recompute_user,decide_work_item,run_task,suspend_task,resume_task,test_resource

The manifest

From Straza's eval stack, without its comment lines; its URL, sign-in provider and version are that stack's values.

yaml
apiVersion: straza.dev/v1beta1
kind: App
metadata:
  name: midpoint
  namespace: com.github.strazahq
  description: midPoint IGA operations, per-user identity (Switch-To-Principal) - reads allowed, writes approve-gated
server:
  name: strazahq/midpoint-mcp-server
  description: MCP server for midPoint identity governance - users, roles, orgs, audit over REST.
  repository:
    url: https://github.com/strazahq/midpoint-mcp-server
    source: github
  version: "0.3.1-dev"
straza:
  runtime:
    kind: remote
    remote:
      url: http://mcp-midpoint-http:3001/mcp
      auth: inject
  credential:
    kind: oauth
    oauth:
      provider: keycloak
      scopes: [openid]
    agents: sponsor
    inject:
      as: header
      name: Authorization
      template: "Bearer {{secret}}"
  exposure:
    tools: ["*"]
  limits:
    rps: 10

Credentials

What the server reads at start to reach Evolveum midPoint (identity governance) over its REST API:

  • MIDPOINT_URL: base URL of the midPoint instance (required)
  • MIDPOINT_USERNAME: midPoint login; the person's own in personal mode, a service account in shared mode (required)
  • MIDPOINT_PASSWORD: password for that login (required)
  • MIDPOINT_MCP_OIDC_ISSUER: shared mode only: OIDC issuer whose access tokens identify each caller
  • MIDPOINT_MCP_OIDC_AUDIENCE: shared mode only: expected token audience
  • MIDPOINT_INSECURE_TLS: optional: skip TLS verification toward midPoint
  • MIDPOINT_MCP_CONFIG: optional: path to the settings file

Server-side gates

Settings the server reads at start. Each one switches writes on or registers more tools, as listed; a tool the server does not register does not exist for any role.

  • MIDPOINT_MCP_ALLOW_WRITES: set to true to let the 15 gated tools act (every tool that changes midPoint, plus test_resource, which stores its outcome on the resource); unset, they stay listed and return a dry-run preview of the REST call instead. Each one that targets an existing object also takes its midPoint name next to the ID (userName, roleName, taskName or resourceName) and is refused on a mismatch before anything is written.