Orthanc SSO with Keycloak and access control

Why Orthanc SSO with Keycloak needs more than a login page

Single sign-on with Keycloak plus per-study access control is possible in Orthanc, but it is not a configuration switch. It is done through the advanced authorization plugin, which forwards each REST request's token to an external token-checking web service, and that service decides whether the request is allowed. The built-in RegisteredUsers list is not designed for this. It holds static user names and passwords inside the Orthanc configuration and does not give you central identity, group-based roles or per-study decisions. Teams that treat SSO as a login page will find that every authenticated user can still see more than they should.

The starting point matters. By default, Orthanc only accepts HTTP connections from localhost. Opening remote access means enabling RemoteAccessAllowed, and the Orthanc Book says AuthenticationEnabled should then be true with users defined in RegisteredUsers. That pairing is the documented baseline, and it is a baseline for local accounts, not for federated identity. Any SSO design has to replace or sit alongside that list without leaving a path where an unauthenticated request reaches the REST API. Confirm this on a test server by calling the REST API from a remote host with no token and checking that it is refused.

The authorization plugin changes the decision point. For each REST request, Orthanc passes the caller's token to the external service. That service must return an allow decision, and it returns HTTP 403 when access is denied. Your team owns the rules inside that service: which Keycloak roles or groups may see which studies, whether access depends on institution or modality, and what happens when a token is expired or malformed. Write these rules down before any build work, because the service is where per-study access control actually lives. Ask whether each rule is evaluated on every request or cached, since that affects both security and load.

The orthanc-auth-service reference project uses Keycloak-issued user tokens with Orthanc Explorer 2, which is a useful starting point for a proof of concept. It is not a finished permission model for your organization. Confirm how far its checks match your roles, how it handles DICOMweb and DICOM traffic that does not pass through the same route, and whether it covers the viewers and plugins you plan to run. Any gap found here is a design decision you need to own, not something the reference project will settle for you.

Plan for the risks before you build. A misconfigured service that fails open will expose patient images to any caller with a valid token, and a token check that is skipped on one route can leave data reachable through another. Test each REST route with users from every role, including denied cases, and keep the dangerous routes such as script execution and export disabled, as the Orthanc Security FAQ advises. Ask any partner to show these negative tests in the written scope, not only the successful login flow.

Which Orthanc settings, plugins and services make up the design

An Orthanc SSO design splits work across several components, and each one decides only part of who can see what. The cards below describe each component's role, what it decides and what it leaves to others, so that the team can confirm where a request is allowed or refused before any configuration begins.

Orthanc core settings

The Orthanc core is the DICOM and REST server that holds the studies. When RemoteAccessAllowed is enabled, AuthenticationEnabled should be set to true, as the Orthanc security FAQ advises, so that remote HTTP calls are not answered anonymously. The core decides whether a connection is authenticated at all, but it does not decide which studies a given user may read once an external authorization service is in place. Confirm the exact setting names and their defaults in the configuration reference for the release you deploy.

Advanced authorization plugin

This official plugin intercepts each REST request and forwards the caller's token to an external web service, then acts on the answer. It decides whether a request proceeds or receives HTTP 403, and it is the bridge between Orthanc and your identity design. It does not validate tokens or hold user roles itself. Because Orthanc ships several official plugins, confirm the plugin's configuration keys in the plugin documentation for the exact release you deploy.

Token-checking web service

This external service receives the forwarded token and returns the access decision, and the orthanc-auth-service reference project is a practical starting point for it. It decides which users may access which resources, including per-study rules, based on claims from the token. It does not issue tokens or store user passwords. Plan to adapt its mapping from Keycloak roles or groups to Orthanc permissions, and to test it with negative cases such as expired tokens and unrelated studies.

Keycloak identity provider

Keycloak authenticates users, issues the tokens that carry their identity, and holds the roles or groups that the authorization service reads. It decides who is a user and what claims a token contains, which makes its client, scope and role configuration part of your access model. It does not decide which Orthanc studies a user can open. Confirm the token lifetimes, client settings and claim names your authorization service expects before go-live.

Orthanc Explorer 2 interface

Orthanc Explorer 2 is the official web interface for browsing studies, and in the reference design it is the client that obtains a Keycloak token and sends it with each REST request. It decides how users sign in and which pages they see, but every access decision is still taken on the server side. Because the browser holds the token, check how it is stored and how sessions end. Confirm that the release you deploy supports the token flow you have chosen.

Reverse proxy for HTTPS

A reverse proxy terminates TLS in front of Orthanc, which keeps tokens and patient data off unencrypted connections when Orthanc is reachable beyond localhost. The Orthanc security FAQ recommends HTTPS and a reverse proxy for Internet exposure. The proxy decides how traffic reaches Orthanc and which paths are exposed, but it does not check the token's content or the study-level permissions. Block dangerous routes such as script execution and export at this layer as well as in Orthanc.

Choosing between RegisteredUsers, a proxy and the authorization plugin

This table compares three ways to control who can reach Orthanc: the built-in RegisteredUsers list, an authenticating reverse proxy, and the advanced authorization plugin with a token-checking service and Keycloak. Read each row against your own user count, per-study rules and the clients your staff use, since the operational cost of each option grows in different places.

Option	When it fits	What it costs operationally
RegisteredUsers with local accounts	A small, stable group of administrators or a lab with few users, where every account can see every study and no central identity system is required	Accounts are maintained in the Orthanc configuration on each server, so joiners, leavers and password resets are manual per instance; there is no per-study rule set and no single sign-on
Authenticating reverse proxy in front of Orthanc	Organizations that already run a web gateway with corporate sign-on and need to restrict who reaches the web interface, while accepting that access rules stay coarse	The proxy handles login and session checks, but user lists and group mappings live in the proxy or directory; the proxy sees HTTP requests and cannot see which study a request touches, so per-study rules are not enforced there
Advanced authorization plugin with a token-checking service and Keycloak	Teams that need single sign-on, per-user or per-group access to individual studies, and a central place to manage identities across Orthanc Explorer 2 and other clients	Requires building and running the token-checking web service, configuring Keycloak clients and roles, and testing each REST route; rule changes are code and configuration changes that need release control
Who maintains user lists	Administrators of each Orthanc instance	Directory or Keycloak administrators, with the authorization service mapping roles to studies; confirm who owns the Keycloak realm and its change process before build
Where per-study rules live	Not supported in RegisteredUsers; all authenticated users share the same access	Not visible to the proxy; enforced by the token-checking service on each REST request that the plugin forwards
Effect on Orthanc Explorer 2	Users sign in with local credentials in the browser session	Explorer 2 must send the Keycloak-issued token with its requests; confirm the token flow works for your Explorer 2 version before committing to this design
Effect on DICOM clients (C-STORE, C-FIND, C-MOVE)	DICOM traffic is not governed by the REST login model, so modality and workstation access is controlled through DICOM AE title and network rules	The authorization plugin covers REST requests, so DICOM association rules need separate controls; confirm how your DICOMweb and DIMSE clients authenticate and plan for both
What a proxy cannot see about individual studies	Not applicable as an access control layer for per-study decisions	Study identifiers, patient data and DICOM attributes inside the request body or response are invisible to the proxy, so it cannot decide access by study owner, department or patient

How to build Orthanc Keycloak single sign-on in the right order

This sequence adds Keycloak single sign-on and per-study access control to an Orthanc server through the advanced authorization plugin and a token-checking service. Each step closes with a check that proves the layer below it works before the next layer is added, so a denied study can be traced to a specific control.

Define the permission model first
Before touching any configuration, the security owner and the imaging lead agree on roles, groups and the study attributes that decide access, such as owning department, modality or patient-level labels. Write a matrix that maps each role to the studies it may read and to the REST routes it may call. The step is closed when the matrix is signed off and every study category in the archive has a named rule. Gaps found here are cheap to fix, while gaps found after cutover are not.
Create the Keycloak realm, clients and roles
The identity team creates a dedicated realm, a client for the token-checking service, a client for Orthanc Explorer 2 and the roles defined in the matrix. Test users are assigned groups that map to those roles. The step is closed when a test user obtains a token from the realm and the decoded token shows exactly the roles the matrix expects, with no extra roles inherited from other realms or default groups. Record the token lifetime setting, because it is tested in a later step.
Deploy and test the token-checking service
Deploy the token-checking web service that the authorization plugin will call for every REST request. Point it at the Keycloak realm so it can validate signatures and issuers. The step is closed when the service accepts a valid token for an entitled user and rejects a token with a bad signature, a token from the wrong issuer, and an expired token. Testing expiry at this stage confirms that the service enforces the lifetime set in Keycloak rather than caching access indefinitely.
Enable the authorization plugin on a test instance
Install the advanced authorization plugin on a separate test Orthanc instance, not the production server, and point it at the token-checking service. Confirm the plugin build matches the Orthanc release line in use, since plugin and core versions must align. The step is closed when a request with no token is refused, a permitted study returns its content, and a request for a study the user is not entitled to returns HTTP 403 from the plugin. Keep the test instance's data synthetic or de-identified.
Enable remote access with authentication over HTTPS
Set RemoteAccessAllowed and AuthenticationEnabled on the test instance, then place the server behind a reverse proxy that terminates HTTPS. Confirm with the vendor documentation how the built-in authentication settings interact with the plugin, because the built-in RegisteredUsers list is not the access control in this design. The step is closed when a plain HTTP connection from outside the network is refused, the HTTPS route through the proxy works, and an unauthenticated request is refused. Verify this from a machine outside the trusted network.
Disable script execution and the export route
Disable the /tools/execute-script route and the export route in the Orthanc configuration. The Orthanc security documentation warns that the first can let a malicious user run system commands and the second can overwrite files, so both stay off in production. Confirm the exact configuration keys for your Orthanc version in the official book. The step is closed when a call to each route is refused, and the refusal appears in the Orthanc log so it can be traced during testing.
Test Explorer 2 login and per-study denial
Test the full path as each role in the matrix. Each tester signs in to Orthanc Explorer 2 through Keycloak, checks that only entitled studies appear in the list, and attempts to open a study outside their entitlement. The step is closed when the denied study returns HTTP 403, the permitted studies open, and a session whose token has expired is sent back to sign-in. Keep the results in a test log, because this record becomes evidence for the access control design.

What drives effort in an Orthanc Keycloak access control project

This table lists the factors that change how much work an Orthanc Keycloak access control project takes, why each one matters, and how to keep it contained. Read it before requesting a quote, since each row maps to a question the scope document should answer. The main takeaway is that the permission matrix and the number of clients and identity sources usually matter more than the Keycloak setup itself.

Driver	Why it changes effort	How to keep it down
User groups and roles	Each group and role must map to a set of permitted actions in the authorization service, and every combination needs a test case. Overlapping roles multiply the number of rules to verify.	Consolidate roles before the build starts. Agree on a short list of named roles and document which actions each one allows.
Study-level rules and their source	Rules that derive access from DICOM attributes such as institution, modality or referring physician require parsing and matching logic. Rules tied to site or ownership depend on data held outside Orthanc, which needs its own sync path.	Prefer rules based on attributes already present and consistently populated in your studies. Confirm which attributes are reliable before scoping.
Number of clients	Each client, such as Orthanc Explorer 2, a DICOM-facing tool, a script or a viewer, needs its own token flow, scopes and tests. DICOM-facing tools may not send bearer tokens, which adds a separate access path to design.	List every application that touches Orthanc, including scripts and integrations, and state whether each one can send a token. Retire unused clients early.
Existing identity sources to federate	Each directory or identity provider connected to Keycloak adds attribute mapping, group synchronization and failure cases. Users with duplicate accounts across sources need a defined resolution rule.	Name the directories in scope and the attributes Orthanc needs. Federate only the user populations that will actually log in to Orthanc.
Environments (test, staging, production)	Each environment needs its own Keycloak realm or configuration, Orthanc instance, authorization service and test data. Promotion steps and configuration drift checks add work at each stage.	Keep environment differences in configuration files. Ask for a defined promotion path and confirm whether test data can resemble production without containing real patient images.
Compliance evidence requirements	Assessors often expect documented access rules, change records, access review output and logs showing denied and granted requests. Producing and retaining this evidence adds design and reporting work.	Agree on the controls and evidence formats up front. DeployOpen prepares systems and evidence for assessments, but independent auditors issue any audit outcome.
Current permission matrix and existing setup	A permission matrix that already exists and is accurate shortens discovery. Without one, the build includes reverse-engineering current access from RegisteredUsers entries, shared accounts and local practice.	Supply the current permission matrix, the RegisteredUsers list with roles, and the Orthanc version in use. The quote follows the written scope, so these inputs are the main basis for it.
Keycloak instance details	Whether Keycloak is already running, its version, hosting model, high availability design and admin access model determine whether the project includes installation and hardening or only configuration.	Share the Keycloak version, hosting location, realm layout and who administers it. Confirm these before the scope is written.

How the design changes for single node, high availability and air-gapped sites

On a single Orthanc server, the design is the simplest of the three. One token-checking service runs beside Orthanc, and a local Keycloak instance issues user tokens. The advanced authorization plugin forwards each REST request's token to the service, which returns an allow or deny decision.

One token-checking service: runs on the same host or a nearby host, with its rule set loaded from a single controlled source.
Local Keycloak realm: holds users, groups and client settings for Orthanc Explorer 2 or any other viewer that uses the same login.
Local database: the built-in SQLite index can suit small archives, but the scalability FAQ recommends an enterprise database engine once the archive grows to several hundred thousand instances.
Reverse proxy: terminates HTTPS in front of Orthanc and Keycloak so tokens never travel in clear text.
Backups: the rule files, the Keycloak realm export and the Orthanc database must be backed up together so a restore returns users and permissions to the same state.

Before you build, ask the vendor to confirm which Keycloak and token-service versions they support with your Orthanc release and plugin versions.

Securing tokens, the authorization service and disabled REST routes

With SSO and per-study permissions in place, the security of the design depends on a short chain of controls: the token the user presents, the service that decides access, the transport between components, and the Orthanc routes that must stay closed. Each card below is a control your team should confirm in its own environment before go-live, and each one names what to check.

Token validation rules

The advanced authorization plugin forwards each request's token to your token-checking service, so that service must reject tokens with an invalid signature, a wrong audience or an expired lifetime. Confirm which Keycloak realm and client the audience claim names, that the service checks the signature against the realm's published keys, and that a token issued for another client is refused. Test each rule with a deliberately bad token.

Authorization service credentials

The authorization service holds credentials to reach Keycloak and possibly database or directory lookups. Store those credentials in a dedicated secrets store, not in configuration files or container images, and limit who can read them. Confirm how the secret is rotated, which service account it belongs to, and that its permissions cover only the lookups the service needs.

TLS between proxy, Orthanc and service

Users reach Orthanc through a reverse proxy, and each request passes between the proxy, Orthanc and the token-checking service. Encrypt each of these hops, not only the connection from the browser. Confirm which certificates each component presents, which certificate authority it trusts, and that plain HTTP is not reachable on any internal port.

Dangerous REST routes stay disabled

The Orthanc security FAQ warns that /tools/execute-script can let a malicious user run any system command, and that the export route can overwrite files. Both should stay disabled, and the proxy should refuse them even if Orthanc is misconfigured. Confirm by requesting each route through the proxy with a valid token and checking that it is refused.

Auditing allowed and denied requests

Access decisions are only useful as evidence if they are recorded. Log every allowed and denied request with the user identity, the study or resource, the route and the outcome, and keep those logs outside the Orthanc host. Confirm that denied requests return HTTP 403, that the logs capture both outcomes, and that retention and access to the logs match your policy.

Fail-closed behavior

If the token-checking service is unreachable or times out, Orthanc must deny the request rather than fall back to open access. Test this by stopping the service in a non-production environment and confirming that study retrieval and viewer requests fail. Also confirm what users see, and that the failure is logged and alerted.

How to test that denied studies stay denied

The most important test for this design is not that an authorized clinician can open a study. It is that a user without a matching role cannot reach that study by any route. Every test in this section is a negative test, and the plan should be agreed before the authorization plugin goes live. In the reference pattern, the advanced authorization plugin forwards each REST request's token to an external token-checking service, which decides access and returns HTTP 403 when access is denied. The test team should confirm that behavior in their own build rather than assume it, because the answer depends on how the service maps Keycloak roles to studies in their environment.

Start with the REST layer. Create test users in Keycloak who hold no role that maps to a test study, then call study-level endpoints directly with their tokens: study metadata, instance retrieval, series listing, and export-related routes. Each call should return HTTP 403, and the response should contain no study identifiers, counts or partial metadata. Repeat the same calls with a valid token belonging to a user whose role maps to a different study, since cross-study access is the failure most likely to slip through a misconfigured mapping. Also test requests with no token at all and with a token whose audience does not match the Orthanc client. Expired tokens and tokens signed by an untrusted issuer should be refused as well. Record the exact status code and body for each case.

DICOM is a separate attack path. Decide, and write down, whether C-FIND and C-MOVE are covered by the same access rules or are explicitly out of scope for this release. If they are covered, test that a query from a non-permitted user returns no matching studies and that a C-MOVE for a denied study is refused. If they are out of scope, the risk must be accepted by the named owner and the DICOM listener should be restricted by network rules and calling-AE allowlisting. Then test Orthanc Explorer 2 as a non-permitted user: the study list, search results, thumbnails and direct study URLs should show only permitted studies. Finally, test fail-closed behavior by stopping or blocking the authorization service and confirming that study access is denied, not open. Restarting Orthanc during this outage should not change the result.

Turn these cases into a checklist that the test owner can sign off: each case, the user and role used, the expected result, the observed result, the tester and the date. Keep the results with the configuration version of Orthanc, the plugin, the authorization service and the Keycloak realm, because a later upgrade or role change can reopen a path that was closed. Results belong in the handover pack, alongside the list of accepted exceptions such as any DICOM path left out of scope. Confirm with the team who will own the checklist after go-live and how often it is rerun, especially after Orthanc upgrades.

A test plan shows what the team checked. It does not replace an independent assessment, which tests the design and its implementation from the outside and reports its own findings. Ask the independent tester to start from your checklist and then add attempts you did not think of, including role-escalation and token-replay attempts. Their findings and your remediation records are what a compliance reviewer will ask for, so plan for both before the system holds real patient images.

What to monitor, back up, upgrade and document after go-live

Once single sign-on and per-study permissions are live, the Orthanc server, the token-checking service and Keycloak must be watched, restored and changed together. The cards below cover what to monitor, what to back up, how to test upgrades and which records keep access decisions explainable to auditors and clinical leads.

Token and authorization failure rates

The advanced authorization plugin forwards each REST request's token to an external web service, which returns HTTP 403 when access is denied. Track token validation failures and 403 responses separately, and break them down by user group and site. A sudden rise in 403s after a role change usually points to a mapping error, not a user problem. Set alert thresholds from your own risk assessment and baseline traffic.

Keycloak availability and login health

If Keycloak is unreachable, users cannot obtain tokens and the viewer stops working, while the Orthanc core may still be running. Monitor the Keycloak endpoints that the authorization service and Orthanc Explorer 2 depend on, along with login error rates and response times. Confirm with your own architecture whether Keycloak sits in a separate failure domain and what happens to active sessions during an outage.

Certificate expiry for HTTPS and Keycloak

The HTTPS endpoints in front of Orthanc, the authorization service and Keycloak each carry certificates that expire on their own schedules. An expired certificate can block token validation or browser access without any change to Orthanc itself. Keep an inventory of every certificate in the chain, record its expiry date and assign an owner. Set renewal reminders from your own change policy rather than a default interval.

Keycloak realm export

The realm holds the clients, roles, groups and user mappings that the authorization rules depend on. Export it on a schedule you set from your recovery objectives, store the export under the same access controls as patient data, and test restoring it into a non-production Keycloak. Note that a realm export may exclude some secrets and user credentials, so confirm with your Keycloak version what the export contains and how to recover the rest.

Authorization rule source and service code

The rules that map roles and groups to studies, sites and actions live in the authorization service, not in Orthanc's own configuration. Keep them in version control, back up the deployed configuration and record the exact service build running in each environment. Without this, a rollback after a rule change may restore the wrong permissions. Confirm with your team who approves changes to these rules before they reach production.

Orthanc configuration and plugin settings

The orthanc.json file, the authorization plugin settings and the reverse proxy configuration determine whether authentication and remote access behave as intended. Back up each file with its version, and compare the backup against the running configuration after every change. Disable routes that can run scripts or overwrite files, and confirm that the backup captures those settings as well as the database.

Testing Orthanc 1.13.0 with the authorization service

Orthanc 1.13.0 was released on 2026-08-15 with a complete rewrite of storage-area access and DICOM parsing and transcoding. Because the authorization plugin and the token service both sit on the request path, test the 1.13.0 core and each plugin version against your authorization service in a staging environment before changing production. Check that 403 responses, token handling and study retrieval behave as before, and keep the previous version available for rollback.

Permission matrix and access records

A permission matrix lists each role, the sites and studies it can reach, and the actions it allows, such as view, export or delete. Keep it current with every change and use it as the reference when an auditor or clinical lead asks why a user could or could not open a study. Pair it with a change record for each role or site change that states who requested it, who approved it and when it took effect.

Runbook for adding a site or role

Adding a hospital site or a clinical role touches Keycloak groups, authorization rules, Orthanc configuration and sometimes DICOM connections. Write a runbook that lists each step in order, the person responsible for each, and a test that confirms the new site or role sees only the studies it should. Rehearse the runbook in staging so that the first production change does not depend on memory.

Questions buyers ask before bringing in an implementation partner

Can our team build Orthanc SSO with Keycloak without outside help?

Yes, a capable team can build this in-house, and the open-source components are available to do so. The work combines three parts: Orthanc with the advanced authorization plugin, a token-checking web service that decides access for each REST request, and a Keycloak realm that issues the user tokens. The plugin forwards each request's token to that external service, which returns HTTP 403 when access is denied. The reference project orthanc-auth-service shows one way to connect these parts with Orthanc Explorer 2. The main risk for an in-house team is not the software but the access model: mapping clinical roles and per-study rules correctly, and testing every denial path. Ask yourself whether your engineers have spare capacity to own the permission logic and the test cases over time.

What does our team need to provide for an Orthanc access control project?

The work depends on decisions only your organization can make, so the engagement needs your people from the start. Identity owners confirm the source of users, groups and roles in your directory and how Keycloak should federate with it. A permission matrix lists which roles may view, export, upload or delete studies, and under which conditions, such as by department, patient relationship or modality. Test users covering each role, including users who must be denied, are needed to verify results. A test Orthanc instance that holds non-production data lets the team check authorization changes without touching patient records. Without these inputs, the build tends to stall at the first permission question that nobody can answer.

How is the cost of an Orthanc SSO engagement structured?

Most DeployOpen engagements are fixed-scope, meaning the scope, deliverables and timeline are agreed in writing before work starts. DeployOpen does not publish a price list. A quote follows from the written scope, so the cost depends on the number of roles, the complexity of the per-study rules, the identity systems to connect, the environments to build, and the testing and documentation required. Ask for the quote to separate one-time build work from any recurring support or upgrade retainer, and to list what the client must provide. Compare quotes on the same written scope, not on headline totals.

How long does Orthanc SSO and per-study access control take to deliver?

Duration depends mainly on how well the permission model is defined when the work starts. Clear role definitions and a complete permission matrix shorten the build. Other drivers include the number of identity sources to connect, whether Keycloak already exists in your environment, how many Orthanc environments need the same setup, and how long your identity owners take to review and approve access rules. Testing with real role combinations usually takes more time than the configuration itself. Ask any partner for a timeline tied to the written scope and to the inputs you must supply, and confirm which dates depend on your approvals.

Does Orthanc have a paid enterprise edition with SSO features?

No. There is no paid edition of Orthanc. The core is licensed GPLv3 or later, and the scalability and cloud plugins are licensed AGPLv3 or later, so the software itself carries no license fee. Orthanc Team SRL, one of the copyright holders, sells deployment, configuration and development services, including pre-paid dedicated support hours that are valid for 12 months and quoted on request. Those hours are a service purchase, not a software license. Confirm the licensing terms of any plugin you plan to use, and ask your vendor directly about the support hours and what they cover.

Will DeployOpen certify that our Orthanc deployment is compliant?

No. DeployOpen does not issue audit reports, attestations or certifications. DeployOpen plans, implements, hardens and documents systems and prepares the controls and evidence that a compliance assessment will examine. For access control, that can include the permission matrix, role mappings, configuration records and test results. Independent auditors and certification bodies perform the assessment and issue any report. Ask your assessor early which evidence they expect, so the access control design and test records are built to match that expectation.

Which Orthanc settings must stay locked down when SSO is added?

Adding SSO does not secure the server on its own. By default Orthanc accepts HTTP connections only from localhost. When remote access is enabled, the Orthanc documentation says authentication should be turned on, and it recommends HTTPS and a reverse proxy for any Internet exposure. The security FAQ also warns that the /tools/execute-script route can run system commands and that the export route can overwrite files, so both should stay disabled. Check these settings in every environment, including the test instance, and confirm them again after each upgrade.

How DeployOpen works on this

DeployOpen plans, implements, integrates, hardens and documents self-hosted open-source platforms inside the client's own infrastructure. For Orthanc SSO with Keycloak and access control, that means connecting Keycloak-issued tokens to the advanced authorization plugin and a token-checking web service, then testing per-study permissions before any user gets remote access.

How we scope

Engagements are fixed-scope, with scope and deliverables agreed in writing before work starts.
The written scope names the Keycloak realm, clients, roles and the study-level rules Orthanc must enforce.
It also states which Orthanc viewers, modalities and network paths the integration covers and which it excludes.

How we build

Deploy Keycloak and Orthanc in the client's own environment, with the authorization plugin configured against them.
Build the token-checking web service that receives each REST request's token and returns allow or HTTP 403 decisions.
Test access by user group and by study, including denied requests, before enabling remote access for any user.

How we hand over

Documented configuration covering Keycloak clients, realm roles, plugin settings and the authorization service code.
Test evidence showing the access matrix and results for each role, study scenario and denied request.
A runbook for adding users, changing roles, rotating signing keys and confirming the script and export routes stay disabled.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer covering Orthanc and its plugins.
Retest the access matrix after each Orthanc release, such as the 1.13.0 line, before upgrading production systems.
Confirm with each vendor and in your own environment how Keycloak upgrades affect token claims the service relies on.