Why open source SSO for healthcare starts with shared workstations
For a clinical IT leader, the function in question is identity for shared clinical devices: one workstation in a ward or emergency bay serves many clinicians, each of whom must sign into the EHR and clinical applications quickly, switch users without leaving patient data open, and remain individually identifiable in the audit trail. The short answer for self-hosted candidates is that Keycloak and authentik are the main options to evaluate, with ZITADEL and FreeIPA fitting specific cases such as multi-tenant deployments or Kerberos-centered Windows and Linux estates. Whichever platform is chosen, the design starts from the HIPAA technical safeguards in 45 CFR 164.312, which require unique user identification, an emergency access procedure, automatic logoff as an addressable specification, and person or entity authentication.
The HIPAA Security Rule applies to covered entities and business associates for all electronic protected health information they create, receive, maintain or transmit, so an SSO design must be documented as part of that obligation. There is no HIPAA certification to point to. HHS states that no Security Rule standard requires certification, so evidence has to come from your own configuration exports, access logs, audit records and risk analysis. Ask your implementation partner which of these artifacts they will produce during the rollout and in what format, and confirm with your privacy and compliance leads which log retention period your organization applies. In the EU, NIS2 Annex I lists healthcare providers as a sector of high criticality, so the same identity platform may also need to meet national NIS2 obligations for multi-factor authentication and access control.
Clinical SSO also has a regulatory reason to get the care-team model right. France's CNIL fined Hopital Prive de la Loire EUR 500,000 under GDPR Articles 32 and 34 on 3 September 2026, citing external access to a patient record system without VPN or multi-factor authentication and access control that ignored the care team's need to know. Before selecting a platform, define how roles map to clinical units, which applications need SAML and which need OIDC, and how a break-glass account is issued, logged and reviewed. Those decisions shape the Keycloak or authentik realm and client design far more than the choice between the two products.
Which HIPAA and clinical rules shape the SSO build
This table maps each HIPAA technical safeguard that touches workforce login to its source rule and the build consequence for a self-hosted SSO deployment. Read it as a checklist of design decisions to settle before configuration starts, and note where the rule is required versus addressable. The main takeaway is that most of the safeguards depend on identity design choices, and a hosted identity service also brings a business associate contract obligation.
| Requirement | What the rule asks for | Build consequence for SSO |
|---|---|---|
| Unique user identification (45 CFR 164.312(a)(2)(i)) | Required. Assign a unique name or number to each user tracking access to ePHI. | Ban shared clinician accounts at the identity provider; model shared workstations with individual credentials and fast user switching per person. |
| Emergency access procedure (45 CFR 164.312(a)(2)(ii)) | Required. Establish procedures to obtain necessary ePHI during an emergency. | Design break-glass accounts outside normal SSO flows, with documented activation, strong authentication, and alerts on every use. |
| Automatic logoff (45 CFR 164.312(a)(2)(iii)) | Addressable. Terminate sessions after a period of inactivity. | Set idle and absolute session lifetimes per client and per workstation type, and test logoff behavior on shared devices. |
| Audit controls (45 CFR 164.312(b)) | Record and examine activity in systems containing ePHI. | Forward login, MFA, session and admin events from the identity provider to the central log store, and retain them where assessors can review them. |
| Person or entity authentication (45 CFR 164.312(d)) | Verify that a person or entity seeking access is who they claim to be. | Define login policy, MFA enrollment and recovery flows, and document the authentication method each clinical application relies on. |
| Transmission security (45 CFR 164.312(e)) | Guard ePHI in transit against unauthorized access. | Enforce TLS for all SAML and OIDC endpoints, and confirm that each EHR connection and token flow uses encrypted channels. |
| Business associate contract (45 CFR 164.314(a)(2)(i)) | Require the business associate to comply with the Security Rule, flow terms to subcontractors handling ePHI, and report incidents. | If the identity service is hosted by a vendor or managed provider that touches ePHI-linked identity data, confirm the contract terms before go-live. |
| Access control and need to know (GDPR Articles 32 and 34, CNIL decision of 3 September 2026) | Access control must match the care team's need to know. The CNIL fined Hopital Prive de la Loire EUR 500,000 for external access without VPN or MFA. | Where European patients or staff are in scope, bind role assignments to care team membership and require VPN plus MFA for all external access paths. |
Which open source identity platforms fit a hospital's clinical access
Four identity platforms cover most hospital SSO scenarios, but each makes different trade-offs on protocols, directory integration and shared-workstation behavior. The choice depends on which EHR and clinical applications must sign clinicians in, where your directory lives and how much of the stack your team can operate.
Keycloak for multi-protocol clinical SSO
Keycloak is Apache-2.0 licensed and supports OpenID Connect, OAuth 2.0 and SAML 2.0, so it can front EHR modules, imaging viewers and legacy web apps from one realm. It federates LDAP and Active Directory, which suits hospitals with an existing AD forest. Confirm the supported production database (PostgreSQL, SQL Server, Oracle and others are listed), the high availability design needed for clinical login, and how the EHR vendor documents its SAML or OIDC support. The current release is 26.8.1.
authentik for flexible provider mapping
authentik is MIT licensed for most of its code, with the authentik/enterprise directory under a separate enterprise license. It offers OAuth2/OIDC, SAML, LDAP, proxy and RAC providers, which helps when a few older clinical apps need a proxy or remote access pattern. Since 2025.10 it runs on PostgreSQL alone without Redis, which simplifies the stack. Confirm which features your hospital needs fall in the enterprise directory, such as mTLS or privileged access controls, and test session timeouts on shared workstations before committing to a design.
ZITADEL for passkeys and SCIM provisioning
ZITADEL is AGPL-3.0 licensed and lists SSO, MFA, FIDO2 and WebAuthn passkeys, OpenID Connect certification, SAML 2.0 and SCIM. Passkeys can reduce reliance on shared passwords at badge-in workstations, and SCIM can automate account changes from an HR or staffing source. The AGPL license has network-use obligations that legal teams should review before modification. Confirm whether your EHR accepts the SAML or OIDC flow ZITADEL issues, and whether passkey enrollment works on the hospital's shared hardware and kiosk policies.
FreeIPA for Kerberos-centric estates
FreeIPA fits hospitals whose Windows and Linux workstations, clinical servers and SSH access already depend on Kerberos and an internal certificate authority. It combines directory, Kerberos, certificate and policy services in one system, which can simplify logon for staff on managed Linux thin clients. Its web and SAML reach to cloud-hosted EHR modules is narrower than the OIDC-first platforms, so confirm which browser-based clinical applications can use Kerberos or a federated front end, and how ticket lifetimes behave on shared terminals.
Matching the platform to EHR protocol support
Before choosing a platform, list each clinical application and the protocol its vendor supports for workforce login, such as SAML 2.0, OIDC, LDAP bind or Kerberos. A platform that speaks every protocol still fails if the EHR vendor only certifies one flow in your version. Ask the EHR vendor to confirm supported SSO methods in writing, the identity provider versions they test, and how they handle session handoff between modules. This check often decides the platform more than feature lists do.
Directory and license constraints to confirm
Clinical identity usually draws from an Active Directory forest, an HR feed or both, and the choice affects whether the platform federates or mirrors accounts. Keycloak, authentik and ZITADEL differ in license terms for code you may modify, and enterprise directories in some projects carry separate licenses. Confirm the license for each component you will run, who will support it after go-live, and whether your security policy requires a specific license class for the identity provider.
How shared workstations, badge tap and break-glass change the design
On shared nursing and emergency department workstations, the main pressure is speed. Several clinicians may sign in to the same machine during a shift, and each handover has to be quick without leaving the previous user's session open. The identity design has to balance short session timeouts and fast user switching against the HIPAA requirement that each person has a unique user identification and that activity can be traced back to that person.
- Session timeouts: Short idle timeouts reduce exposure at the bedside, but very short timers interrupt charting and push staff toward workarounds such as sharing credentials.
- Fast user switching: Switching should keep each clinician's identity separate. Confirm whether your EHR and workstation stack support it natively, or whether the identity provider must broker a new session for each user.
- Proximity badge or kiosk sign-in: Badge tap and kiosk flows depend on the EHR and the endpoint management layer, not only on the identity provider. Confirm proximity badge or kiosk support with your EHR vendor before you commit to a design.
- Session storage: Decide whether sessions are held in the browser, on the endpoint or on the server, because this determines how a lock or logoff reaches every open application.
- Audit linkage: Each badge or password login should record the individual user, the workstation and the time, so audit logs can answer who accessed which record.
Before a pilot, ask the EHR vendor which session and switching modes it certifies and how those modes map to the identity provider's session model.
Clinicians who use their own laptops or tablets, or devices assigned to one person, can carry stronger authentication without slowing a shared floor. The trade-off moves away from speed and toward assurance: the identity provider can require multi-factor authentication, and the endpoint can hold a device identity that the login flow checks. The design question is how far to push assurance without forcing a second factor on every quick lookup.
- MFA at sign-in: Requiring a second factor on personal devices is a strong control, but it adds steps for clinicians who sign in many times a day. Consider step-up prompts only for sensitive applications.
- Phishing-resistant options: Passkeys or WebAuthn-capable hardware keys resist credential replay better than one-time codes. Keycloak and authentik both document WebAuthn-related support, so confirm the exact passkey and key types your chosen version supports in your own test environment.
- Device posture: If your endpoint management tool reports device health, decide whether the identity provider should use that signal or whether it should remain separate.
- Enrollment burden: Plan how staff register a second factor, who helps with lost devices and how long a replacement takes.
- Session length: Longer sessions on assigned devices are easier to justify than on shared machines, but the policy should still set an idle limit.
Confirm with your security and clinical leads which applications need step-up assurance and which can rely on single sign-on with standard MFA.
Remote clinicians, contract staff and external care team members reach the EHR from networks you do not control. The regulatory signal here is direct: the CNIL fined Hopital Prive de la Loire EUR 500,000 under GDPR Articles 32 and 34 on 3 September 2026, finding that external access to its patient record system lacked VPN and multi-factor authentication and that access control ignored the care team's need to know. The design has to put identity and network controls in front of every external session, and limit each account to the records its role needs.
- Network path: Decide whether remote access goes through a VPN, a zero trust access layer or a published application behind the identity provider. Each option changes where authentication happens.
- MFA for every external login: External access should never depend on a password alone. Set a policy that applies MFA to all remote and contractor accounts.
- Role-based access: Map roles to the care team and the patient relationship, so that an external user cannot browse records outside their assignment.
- Account lifecycle: Contractor and locum accounts need clear expiry dates and fast removal at the end of an assignment.
- Logging of external sessions: Record sign-ins, MFA events and record access for every external account so reviews can be carried out later.
Ask your counsel and privacy team which laws apply to external access in each country where your clinicians work, because GDPR, HIPAA and national health rules can impose different duties.
Break-glass access lets a clinician reach patient information during an emergency when normal authorization paths fail, such as an identity provider outage or an account that has been locked. HIPAA lists emergency access procedure as a required implementation specification under 45 CFR 164.312, so the design must provide a working route, while still keeping the access accountable. The hard part is making the path fast enough for an emergency and strict enough that it cannot become an everyday shortcut.
- Separate emergency path: Keep a documented fallback that does not depend on the primary identity provider being online. Decide whether it uses local accounts, a secondary directory or offline credentials, and test each option.
- Strong control on the account: Shared or standing emergency credentials are hard to attribute. Consider individual emergency accounts or sealed credentials that are released only under a defined procedure.
- Alerting and review: Every break-glass use should raise an alert to security staff and produce a record for after-the-event review.
- Time-bound access: Set a limited validity period and require a reason to be entered at the point of use.
- Regular testing: Test the procedure on a schedule so that staff know it works and the credentials stay current.
Ask your compliance lead how your organization documents emergency access and whether your EHR vendor supports a break-glass workflow that matches your procedure.
How a healthcare SSO rollout moves from pilot to break-glass tested
The sequence runs from application inventory to tested emergency access, with each phase producing a artifact that the next phase depends on, so clinical access is moved unit by unit without losing a working fallback. It also gives the security and clinical leads evidence they can review before any unit goes live.
Inventory applications, protocols and shared workstations
Start by listing every clinical and administrative application that needs workforce login, including the EHR, medication tools, imaging viewers, scheduling and reporting. For each one, record whether it supports SAML 2.0, OpenID Connect or only local accounts, and whether it runs on shared or kiosk workstations. The working team includes the application owners, clinical informatics and the identity lead. This step is done when every application has a protocol, an owner and a workstation type recorded, and the list of applications that cannot use SSO at all is agreed and assigned a compensating control.
Decide directory sources and identity ownership
Decide which directory is the source of truth for clinician identities, such as Active Directory, an HR feed or a FreeIPA domain, and whether Keycloak or authentik federates it through LDAP or is fed by provisioning. Confirm which team owns the identity provider, who approves changes to clinical roles, and how contractors and locum staff are represented. The output is a written identity source decision, a mapping of directory attributes to application roles, and an agreed owner for each attribute. Confirm the supported federation options for your chosen product in its current documentation before committing.
Pilot on one clinical unit
Run a pilot with one clinical unit that uses a small set of applications and shared workstations. Test badge or username-based fast user switching where the chosen product and workstation setup support it, and confirm that each clinician signs in with a unique identifier. The pilot team records session behavior, lockouts and help desk tickets. The step closes when the pilot unit completes a full shift cycle of sign-ins and sign-outs without shared credentials and the open issues are logged with owners.
Test EHR and clinical application integrations
Test each clinical application against the identity provider using a defined script covering login, role mapping, logout, token expiry and access revocation. Include the EHR, integrated medical devices viewers where they support SAML or OIDC, and any reporting tools. Verify that the application enforces the role claims it receives and that revoking a user in the directory removes access in each application. The output is a signed-off integration test record per application, with failures and workarounds documented.
Configure MFA and automatic logoff rules
Set authentication policy for each user group, including the MFA method, the session lifetime and the idle timeout that triggers automatic logoff on shared workstations. Test that idle timeouts apply to every application session, not only the portal, and that a clinician signing in at a new workstation is challenged appropriately. Confirm with clinical leadership how timeouts affect active patient documentation before setting values. The output is an exported policy configuration and a test log showing each rule was exercised.
Test break-glass access and document the procedure
Build a separate emergency access path that does not depend on the normal identity provider flow, such as a tightly controlled local administrative account or a documented fallback, with credentials held under dual control. Test it in a controlled exercise: confirm that the procedure works when the identity provider is unavailable, that each use is logged, and that access is revoked afterward. Document the trigger conditions, approvers and review steps. Reviewers should check the result against the emergency access requirement in 45 CFR 164.312, and an independent reviewer should confirm the test evidence.
Cut over unit by unit with rollback ready
Move each remaining clinical unit in sequence, using the pilot and integration records as the checklist. Keep the previous authentication path available until the unit has completed its cutover checks, and keep a documented rollback for each application. Brief staff on the new sign-in and logoff behavior before the switch. The step closes for each unit when its clinicians sign in through the new path, the help desk log shows no unresolved access blockers, and the rollback path is either retired or formally retained.
Monitor authentication after cutover
After each unit moves, review authentication logs, failed sign-in trends, lockouts, account changes and break-glass usage on a set schedule agreed with the security team. Forward identity logs to the central log platform so that audit controls under 45 CFR 164.312 can be shown for systems holding ePHI. Track upgrades to the identity product and test them in a non-production environment first. The sequence is complete when monitoring alerts are tested, the audit record of access reviews is in place, and the operating owner has accepted the runbook.
Evidence a HIPAA assessor or auditor will ask for from the identity layer
This table maps each evidence artifact an assessor is likely to request from the SSO layer to the component that produces it and the gaps teams often find. HIPAA has no certification, so these records support an assessment by HHS or an independent reviewer rather than a badge. DeployOpen prepares the evidence, but auditors and HHS decide whether the controls meet the rule.
| Evidence artifact | Produced by | What the assessor checks | Where it usually falls short |
|---|---|---|---|
| Exported realm and client configuration | Keycloak realm export or authentik blueprints, stored in version control | Login flows, MFA requirements, client redirect URIs and token lifetimes match documented policy | Exports taken by hand after changes, with no record of who changed what |
| User-to-account mapping showing unique IDs | Keycloak user store or authentik directory, joined to the HR source | Each workforce member maps to one account, with no shared or generic logins (164.312(a)(2)(i)) | Shared kiosk or badge accounts created for clinical workstations without a named owner |
| Admin and login event logs forwarded to the SIEM | Keycloak event listeners or authentik event log, shipped to Wazuh or another SIEM | Logins, failures, admin changes and session events are recorded and reviewed (164.312(b)) | Events stored only on the identity server, or retention shorter than the team's review cycle |
| Session timeout and automatic logoff settings | Keycloak realm session settings or authentik session policy, plus workstation lock settings | Idle sessions end on shared devices, consistent with the addressable automatic logoff specification | Timeouts set on the identity provider but not applied to EHR sessions that keep their own tokens |
| Break-glass account register and test records | Identity provider emergency accounts, recorded in a sealed register and tested on a schedule | Emergency access procedure is documented, accounts are restricted, and each use is logged and reviewed | Emergency accounts never tested, password held by one person, or use not tied to a ticket |
| Authentication method and MFA enrollment records | Keycloak or authentik credential store and MFA enrollment reports | Person or entity authentication is verified for each login path, including remote access | Legacy clinical apps still accepting local passwords outside the identity provider |
| Application integration inventory (SAML or OIDC) | Project record maintained by the implementation team, with client configuration exports | Every clinical application that uses single sign-on is listed, with its protocol and owner | EHR modules or reporting tools connected through side channels that are not inventoried |
| Business associate agreements for hosting and support | Contracts held by the covered entity or business associate, reviewed against 45 CFR 164.314(a)(2)(i) | Vendors that handle ePHI, including the implementation partner, agree to Security Rule terms and incident reporting | Support engineers with access to the identity store but no agreement on file |
What do healthcare teams ask before a self-hosted SSO project?
What drives the cost of a self-hosted SSO project for a hospital?
The main cost drivers are the number of applications to integrate, the number of EHR and clinical integrations, how many directories must be federated, the scope of the MFA and shared-workstation rollout, and the high availability design. Infrastructure and database hosting recur, while integration and rollout work is usually one-time. Keycloak and authentik are free under their open source licenses, so the software license itself is rarely the largest line. Ask any partner for a quote that lists each application, directory and integration as a separate line, and states which items are one-time and which recur.
What recurring costs should we expect after go-live?
Recurring costs include infrastructure, database operations, upgrades, security patching, monitoring and support. Keycloak plans four minor releases a year, and the Keycloak Operator documentation recommends manual approval for operator updates, so upgrade testing is an ongoing task. If you choose authentik, its Open Source edition is free, but the Enterprise tier lists $5 per user per month billed annually plus $0.02 per external user per month, and it adds features such as mTLS client certificate authentication, enhanced audit logging and Microsoft Entra ID integration. Confirm which enterprise features your HIPAA controls need before you budget for them.
How long does a healthcare SSO rollout take?
Duration depends on the written scope, so there is no standard timeline that applies to every hospital. The variables that matter most are the number of clinical applications, whether each one supports SAML or OIDC, how many shared-workstation and badge or fast-user-switching scenarios must be tested, and how much clinical staff time is available for testing. Most engagements are fixed-scope, and a partner should agree on scope, deliverables and timelines in writing before work starts. Ask for a phased plan that puts the highest-risk applications in the first phase.
What does our hospital team need to provide?
Your team needs to supply an application inventory with the protocol each application uses, the directories that hold staff identities, the access model that defines which roles can open which records, and named owners for clinical and security decisions. You also need a test environment that resembles production, access to EHR and clinical vendors for integration testing, and a plan for clinician communication and training. Break-glass procedures, logoff timing and audit retention must be decided by your compliance and clinical leaders, because the identity build implements those decisions rather than making them.
Can our internal IT staff run a self-hosted identity provider?
Internal staff can run it if they have skills in identity protocols, directory services, database operations, container or Kubernetes platforms and security hardening, and if they have time for upgrades and on-call response. Many teams combine internal ownership with an external partner for the initial build, integration testing and upgrade planning. Keycloak has a supported Operator and a documented high availability design, and authentik documents a server, worker and PostgreSQL architecture. Assess the staffing for ongoing operations, not only the first deployment, and confirm the skills gap before choosing an ownership model.
How do HIPAA penalties relate to our identity build?
The HIPAA Security Rule requires access control with unique user identification, audit controls, person or entity authentication and an emergency access procedure, so the identity system is directly within the rule's technical safeguards. HHS enforces the rule through complaints, compliance reviews and audits, and civil money penalties are inflation-adjusted, with a current range from $145 to $2,190,294 per violation for penalties assessed on or after 28 January 2026 (45 CFR 102.3). There is no HIPAA certification, so the goal is documented, tested controls that you can show to HHS or an auditor. A proposed Security Rule revision was published in January 2025, and no final rule had been published as of October 2026, so confirm its status with counsel.
Does a self-hosted SSO project make us HIPAA compliant?
No single product or project makes an organization HIPAA compliant. A self-hosted identity provider can support the access control, unique user identification, audit control and authentication requirements in 45 CFR 164.312, but compliance also depends on risk analysis, policies, workforce training, physical safeguards and business associate contracts under 45 CFR 164.314. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies do that work, and you should confirm with your privacy and security officers which evidence they need.
Which open source identity provider fits a hospital best?
The right choice depends on the protocols your clinical applications use, your Kubernetes or VM operations skills, and whether you need enterprise support. Keycloak, under Apache-2.0, supports OpenID Connect, OAuth 2.0 and SAML 2.0, LDAP and Active Directory federation, and a documented high availability design. authentik, with most code under MIT and an enterprise directory under a separate license, is simpler to deploy at small scale but requires Redis-free PostgreSQL planning and careful edition choice. Run a proof of concept against your most difficult EHR integration before you commit.
Questions to ask an implementation partner for clinical SSO
Start with the questions that decide whether clinicians can work at all. Ask how the partner handles shared-workstation session behavior: how fast user switching works between badge or PIN-style re-authentication and a full login, whether a previous user's session and cached tokens are cleared on switch, how idle timeouts map to the automatic logoff specification in 45 CFR 164.312, and how the Keycloak session settings and the EHR's own session timers interact. Ask for a written test plan that runs these scenarios on the actual workstation image, not a lab laptop.
Next, ask how EHR and clinical application integrations are tested with the vendor. A credible answer names the protocol each application uses (SAML 2.0 or OpenID Connect), who supplies the metadata or client registration, which claims or attributes carry the unique user ID and role, and whether the vendor has signed off on the configuration in a non-production tenant. Ask who owns the KeycloakSAMLClient or KeycloakOIDCClient definitions if the Keycloak Operator is used, and how they are reviewed before promotion.
For break-glass access, ask how emergency accounts are designed, where their credentials are held, how each use is alerted and reviewed, and how the procedure is tested without waiting for a real outage. For high availability, ask the partner to show how the database is synchronously replicated, since Keycloak documents that both supported multi-site designs need one, and how a failed node or database failover is rehearsed. For upgrades, ask how they plan for the opt-in breaking changes that Keycloak places in minor releases, how they pin and approve operator updates, and whether they use manual schema migration for large deployments. Finally, ask how audit evidence is produced, which events are retained and for how long, and whether the partner will sign a business associate agreement that flows the Security Rule terms down to any subcontractor touching ePHI.
Deployment patterns for hospital networks and data centers
A hospital identity provider has to stay up through clinical shifts, survive a site outage and fit the network segments the hospital already runs. The four patterns below differ in how they handle state, failover and patching, so the choice depends on the existing directory and the team that will operate it. Each pattern needs confirmation against the hospital's own network design before it is chosen.
Two-site clustered Keycloak
Run a Keycloak cluster across two on-premises sites, with the database synchronously replicated between them. Keycloak documents this as one of its supported high availability designs, and the same guidance requires the synchronous database in both supported designs. Ask the hospital's network team how the two sites are linked, what happens to replication when the link degrades, and whether a clinical workstation can still authenticate when one site is unreachable. Confirm the design with the vendor documentation before committing to it.
Keycloak on Kubernetes with the Operator
The Keycloak Operator manages the Keycloak, KeycloakRealmImport, KeycloakOIDCClient and KeycloakSAMLClient resources, so realm and client configuration can live in version control. Install it through Operator Lifecycle Manager, which the project recommends. Keep the operator in manual approval mode so that updates reach clinical systems only after the hospital's change board has tested them. Confirm which Kubernetes platform the hospital already supports and who owns cluster patching.
authentik with server and worker containers
An authentik deployment runs a server container with an embedded outpost, a worker container for background tasks, and PostgreSQL, which holds all configuration and data except uploaded files. Since the 2025.10 release, authentik no longer depends on Redis, so PostgreSQL is the single stateful dependency to back up and make highly available. Plan for the higher PostgreSQL connection count that the release notes describe. Confirm with the vendor how the hospital's chosen topology handles failover of the database and the containers.
Compose for test and small production only
The authentik Docker Compose guide positions Compose for test setups and small-scale production, and calls for a host with at least 2 CPU cores and 2 GB of RAM. It is not a design for a hospital that needs clustered failover across sites. Use Compose for a proof of concept or a non-clinical pilot, and move to an orchestrated deployment before any clinical application depends on it. Ask the implementation partner to document the migration path in the written scope.
FreeIPA where Kerberos is central
Where the hospital already runs Active Directory or an LDAP directory with Kerberos-based workstation logon, FreeIPA can serve as the identity source with its own Kerberos realm and certificate authority. It suits sites that need Kerberos ticketing for shared workstations and host-based access control. Confirm how FreeIPA will coexist with Keycloak or authentik for SAML and OIDC applications, and which system holds the authoritative user record. Verify its support for the hospital's replication topology before design sign-off.
Confirming HA against the hospital network
Every pattern above depends on latency between sites, the placement of the database, DNS, time sources and firewall rules between clinical and administrative segments. Document the expected behavior when a site or link fails, and test it before go-live, including what a clinician sees at a shared workstation. Ask the partner to produce a written failover test plan, and confirm each high availability claim against the hospital's own network diagrams and the vendor documentation.
How DeployOpen scopes SSO for clinical environments
DeployOpen starts with a written scope that names the identity provider, the clinical applications in each phase, the directories to federate and the workstation types in use. The build runs inside the client's own cloud account, data center or isolated network, so authentication data, session records and audit logs stay under the client's control. Before any configuration, the team agrees on which applications use SAML or OIDC, how fast user switching must work on shared workstations, and how break-glass access is approved, logged and reviewed. Those decisions shape the realm, client and session settings that follow.
During the build, DeployOpen prepares the configuration and the evidence that goes with it. For a Keycloak deployment, that means realm and client definitions managed as code, role mappings that follow care team membership rather than a flat directory group, session and idle timeout settings that support automatic logoff, and a documented break-glass account process with its own monitoring. Clinical application integrations are tested with named clinical users on the actual workstation models, and each integration is signed off against the requirement it supports. Hardening covers database access, administrative console exposure, logging, and upgrade procedures. Every setting is documented so the client's auditors and HIPAA reviewers can trace it to a control.
DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations, and HIPAA has no certification, so the evidence DeployOpen prepares is input to the client's own risk analysis and compliance program. After handover, ongoing support, upgrades and testing can run under a retainer, which suits clinical identity because Keycloak patch and minor releases need tested rollouts. Most engagements are fixed-scope, and the scope, deliverables and timeline are agreed in writing before work begins. Ask for the written scope to list each application, its protocol, the test cases and the evidence artifacts, so changes after kickoff go through a documented change request.
How DeployOpen delivers healthcare SSO
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source identity platforms inside the client's own infrastructure. For healthcare SSO, that means clinical access rules, unique user identification and break-glass procedures are settled in writing before any build starts, then tested and handed over with the evidence a compliance review will ask for.
How we scope
- Written scope lists each clinical application, its SAML or OIDC support and its owner before work starts.
- Scope defines shared workstation behavior, fast user switching expectations and session timeout settings for each unit.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing, and ongoing support available as a retainer.
How we build
- Deployment runs in your cloud account, data center or isolated network, with the identity provider and its database under your control.
- Integrations with EHR and clinical applications are configured over SAML or OIDC, tested against agreed login and logout flows.
- Break-glass accounts, emergency access procedures and audit logging are configured and tested as part of the build, not after go-live.
How we hand over
- Documentation covers realm or tenant configuration, client registrations, MFA policy and recovery steps for your administrators.
- Configuration exports and access review evidence are prepared so your compliance team and auditors can examine them.
- Handover includes runbooks for break-glass use, identity provider outages and rotation of emergency credentials.
How we support
- Security testing of the identity layer and integrated applications can be scoped alongside the rollout.
- Upgrades, patching and backups are planned as a recurring service, with changes tested before they reach clinical systems.
- Ongoing support, upgrades and continuous testing are available as retainers, scoped in writing with your team.
