Skip to content

Releases

v0.6.1

Choose a tag to compare

@github-actions github-actions released this 06 Nov 09:17
v0.6.1
b7da1bc

This release fixes the tool list for clients built on the TypeScript MCP SDK.

Fixed

  • The tool list now loads in every client. In the output schema of the 15 write tools, the body field was typed as the bare JSON Schema true. That is valid JSON Schema, but the MCP schema wants an object there, and clients built on the TypeScript SDK, Glama's checker among them, refused the whole tool list. body now has a proper schema with a description, and a new test checks every property schema of every tool so it cannot come back.

v0.6.0

Choose a tag to compare

@github-actions github-actions released this 04 Oct 16:56
v0.6.0
834a81f

This release makes Get access offer what midPoint's own request rules allow each person, shows midPoint's reason when it refuses a change, and takes request fields from midPoint's schema.

What's new

  • Get access follows midPoint's request rules. midPoint can let different people request different roles, for different people, as different relations. The server now works this out from the same rules midPoint checks (the #assign authorizations of the person's roles):

    • "Request for" lists yourself and the people your rules let you request for, such as your reports;
    • the catalog lists only the roles your rules allow for that person;
    • a relation other than member, such as "Approve requests for it", appears only where a rule names it;
    • each role has "Why you can request this", naming the rule;
    • fields and dates follow what the rule allows.

    midPoint still decides when you send the request. A live test against midPoint 4.10.3 (73 real requests) found that every prediction the preview was sure of matched midPoint. The test is in the repository, so you can run it against your own midPoint. New tool list_request_targets; request_role takes relation.

  • midPoint's reason on refusals. When midPoint refuses a change, the person sees why. Examples are a policy rule's own message ("Requests for this role need a justification") and a missing permission. Before, they saw "unexpected status 409". HTTP 409 has its own error code, refused.

  • Request fields from midPoint's schema. The request dialog offers every assignment field in midPoint's schema, as midPoint's own Request access page does: choice lists from an enumeration or a lookup table, fields with several values, whole and decimal numbers, and required marks.

  • Approvers see what a request carried: every field, labelled as midPoint labels it, and the comment the requester typed in midPoint's own Request access page.

  • The demo reads like a chat app, every action in it completes, and it shows the request rules. Try it at strazahq.github.io/midpoint-mcp-server.

Fixed

  • My requests listed every request twice, once as "an item you can't see in midPoint". midPoint files a request as an "operation request" case with an approval case under it, and the server listed both. Each request is now listed once.
  • Searching roles by text (list_requestable_roles with query) failed with HTTP 500 on midPoint 4.10.3.

Breaking changes

  • The settings requests.formItems and requests.justificationItem are ignored, with a warning at startup. Request fields come from midPoint's schema instead.
  • On work items and cases, justification becomes requestDetails (every field the request carries) and requesterComment. server.requestReason is removed.

Before you upgrade a shared deployment

examples/role-mcp-rs-service.xml gains reads for the service account. They cover definitions only, not anyone's data:

  • rest-3#getObjects and rest-3#getExtensionSchema, plus model-3#read on schemas and lookup tables and model-3#getExtensionSchema: the request fields;
  • model-3#read on a few items of roles, orgs, services and archetypes (read-request-rules): the request rules.

Without the request-field reads the dialog has no fields, and the server says so at startup. Without read-request-rules, Get access lists the roles flagged requestable, as before. Both were verified on midPoint 4.10.3. To let approvers see the requester's comment, docs/authorization.md has the read to grant them.

midPoint versions

This release supports midPoint 4.10. Everything in it was verified against midPoint 4.10.3. midPoint 4.8, 4.9 and 4.11 are not tested and may not work. The README section "midPoint versions" lists the version-sensitive parts.

Install

  • Binaries for Linux, macOS and Windows are attached below.
  • Container image: ghcr.io/strazahq/midpoint-mcp-server:0.6.0, for amd64 and arm64.
  • Kubernetes: apply the attached midpoint-mcp-server-kubernetes.yaml after creating the Secret, as described in deploy/kubernetes/README.md.

Verify what you downloaded

Every artifact is signed with Sigstore by this repository's release workflow, and each comes with an SPDX SBOM and a build provenance attestation.

cosign verify-blob checksums.txt \
  --bundle checksums.txt.sigstore.json \
  --certificate-identity-regexp '^https://github\.com/Strazahq/midpoint-mcp-server/\.github/workflows/release\.yml@refs/tags/v' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com
sha256sum -c checksums.txt --ignore-missing

The complete list of changes is in CHANGELOG.md.

v0.5.0

Choose a tag to compare

@github-actions github-actions released this 04 Oct 04:28
v0.5.0
f1ac75f

This release makes the four views readable, puts names next to IDs everywhere a person approves a change, and adds self-service, operator and group-approval tools.

What's new

  • Readable views. Requests to approve, Get access, My requests and My team's access are redesigned after two independent reviews:

    • colour means status only;
    • people show as initials and roles, teams and accounts as icons;
    • each status is a pill with a word;
    • facts read as label and value ("Asked by", "How long", "Why you");
    • every action is a real button;
    • full screen shows a table of rows.

    My team's access says where each role came from ("approved by you") and when it ends.

  • Names you can check before you allow a change. Every write tool takes the midPoint name of the user, role, task or system next to its ID. A chat app that asks "Allow this tool?" then shows "carol" and "End user", not two IDs. The server refuses a name that doesn't match its ID before writing anything. Results also start with names, for example "Would assign role End user to Carol Jensen (carol).", with the IDs on a separate line.

  • Approvals offered to a group. When an approval step names a group, any member can claim the request in the inbox and then decide it, or release it back to the group. New tools claim_work_item and release_work_item.

  • New tools:

    • get_my_access: your own roles, with who requested and approved each.
    • list_expiring_access: access of you and your team that ends soon.
    • list_recent_errors: what failed in the last hours. It checks failed tasks, accounts with failed operations, broken accounts, systems that are down, and audit errors where allowed.
    • list_tasks, get_task, run_task, suspend_task, resume_task and test_resource for operators.
  • get_user_assignments reports where each assignment came from: who created, requested and approved it, and the approval comment.

Breaking changes

  • decide_work_item, cancel_request, assign_role and unassign_role require userName and roleName. recompute_user, enable_user and disable_user require userName. request_role requires roleName, and also userName with userOid. These are midPoint's unique name values, such as a login, not display names. The views send them already.
  • The text of write results changed: names first, then Case: and Request: lines. Clients that parse that text need updating. The structured results are unchanged.

Before you upgrade a shared deployment

  • examples/role-mcp-rs-service.xml is now the complete role for the service account:

    • the REST entry actions, including #claimWorkItem, #releaseWorkItem and #cancelCase;
    • #proxy;
    • one read authorization, so the server can find the user behind a token.

    It holds no other rights over data. Every call runs on the person's own midPoint rights, and people need no REST rights of their own. Verified on midPoint 4.10.3.

  • If the service account still holds a personal-mode role with broad rights over data, such as examples/role-mcp-direct-service.xml, remove it. In shared mode those rights only let the account change data by itself.

  • Withdrawing a request also needs model-3#cancelCase on the person's own cases. To show requests offered to a group, approvers need a read authorization for those items. midPoint's stock roles have neither. docs/authorization.md has both as XML.

midPoint versions

This release supports midPoint 4.10. Everything in it was verified against midPoint 4.10.3. midPoint 4.8, 4.9 and 4.11 are not tested and may not work. The README section "midPoint versions" lists the version-sensitive parts.

Install

  • Binaries for Linux, macOS and Windows are attached below.
  • Container image: ghcr.io/strazahq/midpoint-mcp-server:0.5.0, for amd64 and arm64.
  • Kubernetes: apply the attached midpoint-mcp-server-kubernetes.yaml after creating the Secret, as described in deploy/kubernetes/README.md.

Verify what you downloaded

Every artifact is signed with Sigstore by this repository's release workflow, and each comes with an SPDX SBOM and a build provenance attestation.

cosign verify-blob checksums.txt \
  --bundle checksums.txt.sigstore.json \
  --certificate-identity-regexp '^https://github\.com/Strazahq/midpoint-mcp-server/\.github/workflows/release\.yml@refs/tags/v' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com
sha256sum -c checksums.txt --ignore-missing

The complete list of changes is in CHANGELOG.md.

v0.4.0

Choose a tag to compare

@github-actions github-actions released this 03 Oct 07:38
v0.4.0
55892d2

This release adds interactive approval and access views, safer approvals, support for agents that sign in as themselves, and signed release artifacts with Kubernetes manifests.

What's new

  • Four interactive views for MCP clients that support MCP Apps: Requests to approve, Get access, My requests and My team's access. They are built into the binary and use no network or storage of their own. They pass their browser test suites but have not yet been tried against a live midPoint.
  • A new decide_work_item tool approves or rejects a work item. Before writing anything it checks that the item is open and assigned to the caller, and afterwards it reports what midPoint recorded.
  • Agents and services that sign in with the OAuth client credentials grant can now act as a midPoint user, limited to the archetypes you list.
  • The first part of team self-service: list_my_teammates and whoami.
  • Every error result carries a stable error code, and errors no longer reveal midPoint's address.
  • An optional settings file for non-secret configuration, OIDC discovery from a separate URL, and optional anonymous discovery of the tool list.
  • The server now stops cleanly on SIGTERM and lets requests in flight finish, so Kubernetes, Docker and systemd restarts no longer cut them off.

Breaking changes

  • approve_work_item and reject_work_item are removed. Call decide_work_item with decision set to approve or reject.
  • request_role now refuses roles that midPoint does not offer for request.
  • The Go module path is now github.com/strazahq/midpoint-mcp-server. This only matters if you import the code.

Before you upgrade a shared deployment

  • The service account must be able to search users on the attributes the server matches tokens against. The example role examples/role-mcp-rs-service.xml does not grant that on its own. See docs/authorization.md.
  • Read docs/misconfigurations.md. It lists the settings that can let one caller act as another, or lock everyone out.

New documentation

  • Step-by-step setup with Keycloak and with Microsoft Entra ID as the identity provider, with midPoint as the system that owns the users: docs/identity-providers.md.
  • Ready-to-fill configuration files: examples/keycloak.env and examples/entra.env.

Install

  • Binaries for Linux, macOS and Windows are attached below.
  • Container image: ghcr.io/strazahq/midpoint-mcp-server:0.4.0, for amd64 and arm64.
  • Kubernetes: apply the attached midpoint-mcp-server-kubernetes.yaml after creating the Secret, as described in deploy/kubernetes/README.md.

Verify what you downloaded

Every artifact is signed with Sigstore by this repository's release workflow, and each comes with an SPDX SBOM and a build provenance attestation.

cosign verify-blob checksums.txt \
  --bundle checksums.txt.sigstore.json \
  --certificate-identity-regexp '^https://github\.com/Strazahq/midpoint-mcp-server/\.github/workflows/release\.yml@refs/tags/v' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com
sha256sum -c checksums.txt --ignore-missing

The complete list of changes is in CHANGELOG.md.

v0.3.0

Choose a tag to compare

@github-actions github-actions released this 16 Jul 07:05

Full Changelog: v0.2.1...v0.3.0

v0.2.1

Choose a tag to compare

@github-actions github-actions released this 15 Jul 08:43

Full Changelog: v0.2.0...v0.2.1

v0.2.0

Choose a tag to compare

@github-actions github-actions released this 15 Jul 08:29

Full Changelog: v0.1.0...v0.2.0

v0.1.0

Choose a tag to compare

@github-actions github-actions released this 15 Jul 06:50