How to set up OpenEMR SSO with LDAP, Active Directory and Google
A clinic or organization that runs OpenEMR usually wants two things at once: staff should sign in with the directory they already use, and third-party applications should reach FHIR data only under grants the organization controls. These are different problems. Staff login decides who can open the EHR. App authorization decides which software can act for a user, with which scopes, and for how long. OpenEMR's FHIR API supports OAuth 2.0 and OpenID Connect, so both can be designed together, but they should be configured and reviewed as separate decisions. Start by writing down which identity source is authoritative for each population: employees, contractors, locums and any service accounts.
OpenEMR added LDAP and Active Directory login in version 6.0.0. In this model, the password is checked against the directory, but the user must still exist as a user record in OpenEMR. A directory account with no matching OpenEMR user cannot sign in. Google Sign-In arrived in version 6.1.0. Confirm the exact settings labels, the field names used to match users and the behavior for accounts that exist in the directory but not in OpenEMR in the version you run. OpenEMR 8 is the current major line, and setup pages in older wikis may describe earlier screens. Test against a non-production copy of your installed version before writing any runbook.
The harder part is provisioning and deprovisioning. Because OpenEMR keeps its own user records, someone must create those records when a person joins and disable them when the person leaves. Directory disablement alone may not stop access to OpenEMR if the local user remains active, so ask the implementer to show how a terminated employee loses access, and how that check is repeated after each directory change. Decide who owns the mapping between directory groups and OpenEMR roles, and how role changes are reviewed. Mapping is also a common failure point: a username that differs in format between the directory and OpenEMR, or a shared login name, can attach the wrong clinical role to a person.
Keep a break-glass local administrator account that does not depend on the directory, the Google identity provider or the network path to either. Store its credentials under dual control, test the procedure on a schedule, and log its use. Also decide which accounts are allowed to bypass SSO, and whether multi-factor authentication applies to them. The Securing OpenEMR guide recommends multi-factor authentication and strong password policies, so confirm which of these controls apply to directory-backed logins and which remain with OpenEMR.
Finally, keep staff sign-in and SMART on FHIR app access separate in your design. A clinician signing in through the directory does not automatically make a third-party app trustworthy, and an app registration should not be treated as a staff identity. Review which applications are registered, which scopes they request, whether public apps use PKCE, and who approves new registrations. Test each flow with a non-production patient and a revoked-user case before go-live.
Which OpenEMR components and settings are involved in SSO
An OpenEMR SSO setup touches more than one login screen. The directory supplies identities, the OpenEMR global settings decide which sign-in paths are active, and the user records and password policy decide what a signed-in person can do. The FHIR API and registered client records add a second authorization path for third-party apps, so each piece needs its own check before go-live.
OpenEMR login path and global settings
LDAP, Active Directory and Google Sign-In are enabled and configured through the Administration Globals settings, not through a separate SSO module. Each sign-in method is a setting that can be switched on, combined or left off, so the team should record which methods are active and which accounts can use each one. Confirm the exact menu path and field names against the documentation for the installed version, because these labels change between releases.
LDAP or Active Directory directory
OpenEMR validates passwords against the directory, but the user must still exist as an OpenEMR account. This means directory membership alone does not grant access, and a directory account with no matching OpenEMR record will fail to sign in. Agree with the directory owner which groups, search base and bind account OpenEMR will use, and test with a disabled or departed user to confirm access is refused.
Google identity and account matching
Google Sign-In, added in version 6.1.0, authenticates a person through their Google identity. The matching step between that identity and an existing OpenEMR user record is the main risk, because a mismatched or shared address can attach the wrong clinician to a session. Decide who may use Google sign-in, whether personal accounts are allowed, and how an account is removed when someone leaves the practice.
OpenEMR user records and roles
Every person who signs in, whether through LDAP, Active Directory or Google, needs an OpenEMR user record with a role and access settings. Those records, not the directory, control what each clinician, front-desk user or administrator can see and change. Plan a joiner, mover and leaver process that updates OpenEMR records as well as directory groups, and review active users on a schedule.
Password policy from version 6.0.0
Version 6.0.0 added password length limits, a strong password rule, reuse prevention, expiration settings and a choice of Bcrypt, Argon or SHA512 hashing. These settings apply to local OpenEMR passwords and affect how fallback or break-glass accounts behave when the directory is unavailable. Confirm each value with the security owner, and check which setting applies to directory-validated logins before writing the policy into a standard.
FHIR API authorization layer
OpenEMR's FHIR API uses OAuth 2.0 and OpenID Connect, with PKCE required for public apps and SMART on FHIR v2.2.0 scopes controlling what an app may read or write. This is a separate authorization path from clinician sign-in, so an app can be granted access even when the staff login design is unchanged. Review which scopes each app requests and confirm, in the installed version's documentation, how the API is enabled and which scopes are offered.
Registered client records for third-party apps
Each third-party app that uses the FHIR API needs a registered client record in OpenEMR that defines its identifier, redirect addresses, type and permitted scopes. A broad or stale client record gives an app more access than its purpose requires, and an unused record stays valid until someone removes it. Keep an inventory of registered clients, assign an owner to each, and confirm the registration steps in the documentation for the installed version.
Which login source and app access model fit your environment
This table compares the login sources OpenEMR can use (local passwords, LDAP or Active Directory, Google Sign-In, and a combined model with local fallback) and the app access choices for SMART and OAuth 2.0 clients. Read each row as a trade-off: find the option that matches where your staff accounts already live, then check the operational cost it adds before you commit.
| Option | When it fits | Operational cost to plan for | Confirm before you choose |
|---|---|---|---|
| Local OpenEMR passwords only | Small sites with few users and no central directory to integrate with | Every joiner, mover and leaver is managed by hand inside OpenEMR, and password policy must be set in the Administration Globals | Password policy, expiration and hashing options available in your release |
| LDAP or Active Directory validation | Staff already sign in to a directory and you want one password to govern access | OpenEMR still requires each user to exist locally, so accounts must be created and disabled in both places | How your directory groups map to OpenEMR users and whether disabled directory accounts stop access in practice |
| Google Sign-In | Organizations that run Google Workspace and whose staff all hold Google accounts | Staff without Google accounts cannot use this path alone, and access depends on Google availability | Whether your domain and account policies permit this sign-in path for clinical staff |
| Combined model with local fallback accounts | Sites that need directory or Google sign-in day to day but must keep access during an outage | Fallback accounts are a standing risk that must be tightly controlled, monitored and tested | Who holds fallback credentials, how they are stored, and how their use is logged and reviewed |
| Confidential server-side SMART apps | Third-party apps that run on a server you control and can keep a client secret safe | You manage client secrets, rotation and the server hosting the app, and scopes must be reviewed per app | Client registration steps and how secrets are stored in your own infrastructure |
| Public apps using PKCE | Browser or mobile apps that cannot hold a secret safely | No client secret to protect, but apps run on user devices, so scope and session limits need closer review | That PKCE is enabled for the app type you plan to use in your OpenEMR version |
| Granular scopes granted per app | Apps that need only some resources, such as read-only patient data | Each scope must be justified and reviewed as apps change, which takes ongoing governance time | Which FHIR scopes your chosen apps request and how consent is recorded for users |
Build sequence for OpenEMR directory login and SMART app access
This sequence moves OpenEMR from a standard local login to directory-backed sign-in, optional Google Sign-In, a password policy and scoped OAuth 2.0 and OpenID Connect access for FHIR and SMART on FHIR apps. Each step closes with a test or record that the next step depends on, so the team can prove the result before expanding access.
Confirm the version, PHP and database baseline
The platform team records the target OpenEMR release, the PHP version and the database engine and version in the test environment. Recent OpenEMR releases require PHP 8.3 or later and run on a MySQL- or MariaDB-compatible database, so confirm both against the release notes for the version you intend to run. Check the target release on the OpenEMR releases page before you install or upgrade. The step closes when the versions are written into the build record and a test login page loads over HTTPS.
Document and test a break-glass local admin
The security lead creates one local administrator account that does not depend on the directory, stores its credentials in the approved vault, and names the people allowed to use it. The owner writes the emergency procedure, including when it is used and how the use is logged. The administrator then signs in once in the test environment to confirm the account works. The step closes when the login is recorded in the test log and the procedure is approved by the owner.
Verify the directory service account and secure transport
The directory team creates a read-only service account for OpenEMR with only the permissions needed to search and authenticate users. They confirm that LDAPS or another encrypted transport is configured and that the directory certificate chain is trusted by the OpenEMR host. The team then runs a test bind with a sample user from the directory and records the result. The step closes when the bind succeeds over the encrypted channel and the service account credentials are stored with a named owner.
Map existing accounts, then enable directory login
Before turning on directory validation, the application owner lists every OpenEMR user account, its role and whether a matching directory identity exists. Accounts without a directory match are decided upon and documented, including shared or service accounts. The LDAP or Active Directory login is then configured and tested with three cases: a valid directory user with an OpenEMR account, a valid directory user without one, and an invalid password. The step closes when a valid directory password for a user with no OpenEMR account is refused.
Configure and test Google Sign-In only if required
The decision owner confirms whether Google Sign-In is needed, since the directory login may already meet the access requirement. If it is required, the administrator configures it on a version that includes the feature, which the project added in 6.1.0, and sets the allowed domain or specific account rules. The team tests a permitted account, a non-permitted account from the same provider and an account outside the allowed domain. The step closes when only the permitted accounts can sign in.
Apply and verify the password policy
The security owner applies the password policy available from 6.0.0 onward, which covers length limits, the strong password rule, reuse prevention, expiration and the hashing algorithm choice. The team confirms the rules against the current requirements in the organization's own security standard, since those requirements set the values. A tester then attempts a password that breaks each rule and a password reused from the recent history. The step closes when each attempt is refused and the settings are exported to the configuration record.
Enable OAuth 2.0 and OpenID Connect for FHIR apps
The integration engineer enables OAuth 2.0 and OpenID Connect for the FHIR API and sets the granted scopes to the minimum each test app needs. The team registers one confidential test app that uses a client secret and one public app that must use PKCE, then checks that each app receives only its approved scopes and that a request for an unapproved scope is refused. The step closes when both test apps authorize, return data limited to their scopes, and the results are recorded.
Document each setting and its owner
The project lead creates a configuration record that lists each setting from the previous steps, its current value, the business or technical owner, the review date and the test evidence that supports it. The record covers the break-glass procedure, the directory service account and its rotation owner, the Google rules, the password policy, the enabled scopes and the registered apps. The owners sign the record before production access is granted. The step closes when every setting has a named owner and a linked test result.
How the SSO setup differs by hosting and network model
When OpenEMR and Active Directory sit on the same internal network, the main work is reachability and trust. OpenEMR authenticates users by binding to the directory and validating the password, but the user must also exist in OpenEMR. The build therefore centers on which domain controllers the OpenEMR host can reach, whether traffic uses plain LDAP or LDAPS, and which account OpenEMR uses to search the directory.
- Protocol choice: Confirm whether the security team allows plain LDAP on the internal segment. Most directory owners will require LDAPS, which needs a certificate that the OpenEMR host trusts.
- Domain controller placement: Identify the domain controllers nearest the OpenEMR host and the firewall rules that permit the required ports. Test each controller separately so one failed controller does not go unnoticed.
- Service account: Ask for a read-only bind account with a password policy and rotation schedule agreed with the directory team.
- Verification: Test a valid user, an expired password, a disabled account and a user missing from OpenEMR, and record the result for each.
Confirm with the directory team which domain controllers will answer, how certificates are issued and renewed, and who approves changes to the bind account.
When OpenEMR runs in a cloud account and the directory stays on premises or in a separate network, the login path crosses a private link or VPN. The network path, certificate trust and failure behavior become the main design concerns. A login depends on the tunnel being up, so a network fault can lock out every clinician at once, even though OpenEMR itself is healthy.
- Network path: Document the route from the OpenEMR subnet to each domain controller, including DNS resolution for the directory domain. Name resolution often fails before connectivity does.
- Certificate trust: Confirm that the certificate presented on LDAPS chains to a root the OpenEMR container or host trusts, and plan how that trust is updated.
- Outage behavior: Decide whether a local break-glass administrator account exists, how it is protected, and who can use it during a tunnel outage.
- Redundancy: Ask whether more than one tunnel or domain controller route is available, and test failover for each.
- Verification: Simulate a tunnel drop and confirm the failure message shown to users and the logs recorded.
Confirm with the network and cloud teams the tunnel's availability design, the maintenance window for the directory, and whether private link traffic is logged for the audit trail.
In a Docker deployment, the directory settings and certificates live inside a container image or are mounted from the host. The build must decide how certificates reach the container, how bind credentials are supplied without being written into images, and what happens to a running container when configuration changes. The container lifecycle, not the directory, often determines how a change takes effect.
- Certificate mounting: Mount the trusted CA bundle read-only and document the path the container expects. Rebuilding an image to add a certificate makes later patching harder.
- Secrets injection: Pass the bind password through the orchestrator's secret mechanism or an external secret store, not an environment variable visible in the image history or compose file.
- Restarts: Confirm whether a changed setting or certificate needs a container restart, and schedule that restart so active sessions are handled deliberately.
- Image updates: Check that the mounted configuration survives a version upgrade, since OpenEMR releases change the files they ship.
- Verification: Restart the container from a clean state and repeat the login tests to confirm nothing depended on a value left in the running container.
Confirm with the platform team which secret store is in use, who can read mounted files on the host, and how configuration is version controlled.
In an air-gapped or tightly restricted network, Google Sign-In cannot be used because the OpenEMR host has no route to Google's sign-in services. The directory must be internal, and every dependency the login needs must also be internal, including time synchronization, DNS and certificate revocation checks. Authentication design becomes a question of what the isolated environment can reach.
- Google Sign-In: Treat it as unavailable in this model and document that decision for the security reviewers.
- Internal dependencies: List the DNS, time, directory and certificate sources the login depends on, and confirm each is reachable inside the enclosed network.
- Certificate revocation: Confirm how revocation status is checked where public endpoints are blocked, and whether a stapled or internally published status is available.
- Updates: Plan how new OpenEMR releases and certificate changes enter the network, since the normal download path may not exist.
- Verification: Block outbound traffic from the OpenEMR host and confirm the directory login still works, then confirm the Google option fails safely or is hidden.
Confirm with the security and infrastructure owners which internal services they operate, how media is transferred into the enclosed network, and who signs off on the offline update process.
What drives the effort of an OpenEMR SSO project
This table lists the factors that change how much work an OpenEMR SSO project takes, from directory condition to audit evidence. Each row explains why the driver matters and what your team can do to keep it contained. The main takeaway is that a clean directory structure, one group per OpenEMR role and a limited app catalog do more to reduce effort than any single configuration choice.
| Driver | Why it changes effort | How to keep it down |
|---|---|---|
| Number of user populations and roles | Each population (clinicians, front desk, billing, administrators) needs its own mapping from directory groups to OpenEMR access roles, and each mapping needs testing. | Define one directory group per OpenEMR role before the project starts, and limit the number of populations to those with distinct access needs. |
| State of the directory | Nested groups, legacy accounts, shared logins and inconsistent attributes take time to find, clean and map before login can work reliably. | Run a directory review first, retire stale accounts and confirm that group membership reflects current job roles. |
| Number of environments | Development, test and production each need their own identity provider settings, redirect URIs and directory bindings, and changes must be promoted between them. | Keep a test environment with a copy of the directory structure so that role mapping is verified before production changes. |
| Third-party SMART apps and their scopes | Each app that reads or writes patient data needs its own client registration, approved scopes and review of what it can access. | Limit the app catalog to the applications the clinic needs, and grant only the granular scopes each app requires. |
| MFA or conditional access in front of login | An identity provider policy that prompts for a second factor or blocks sign-in by location or device changes the login flow and must be tested with OpenEMR's session and API behavior. | Agree the MFA and access policy with the identity owner before configuration, and test both browser login and any API token flow. |
| Google domain rules | Google Sign-In depends on the Google Workspace domain, allowed account types and how users map to existing OpenEMR accounts, which can differ from the directory. | Confirm which domains are allowed and how Google accounts match existing OpenEMR users before enabling the option. |
| Audit and evidence requirements for HIPAA and Meaningful Use readiness | Assessors commonly ask for records of who has access, how access was granted and how changes were approved, which adds documentation and log review work. | Document the role mapping, access approval steps and configuration baseline as the project proceeds, and confirm the evidence format with your assessor. |
| Client identity owner | Someone on the client side must decide access rules, approve role mappings and accept changes, and that time is needed throughout the project. | Name an identity owner at the start with authority to approve role mappings, app scopes and cutover timing. |
How to harden OpenEMR login and app access
These six controls cover the paths into OpenEMR: the web entry point, the directory connection, the bind account, user passwords, third-party app access and the server itself. Work through them in order during SSO setup, then repeat the review after each security release. Each card names what to confirm in your own environment.
Serve only over HTTPS on port 443
The Securing OpenEMR guide says to allow only HTTPS and to consider opening only port 443. The Google sign-in redirect and the token exchanges depend on this entry point, so check that the web server, load balancer and firewall all match. Confirm that plain HTTP requests redirect or are blocked, and that no administrative port is reachable from outside the clinic network.
Validate LDAP certificates and encrypt transport
Directory logins send user credentials to the LDAP or Active Directory server, so the connection must be encrypted and the server certificate must be verified. Confirm that the OpenEMR host trusts the directory's certificate authority. Do not disable certificate checking to get a connection working. In a test environment, use a certificate with the wrong host name to confirm the connection is refused.
Scope and protect the directory bind account
OpenEMR uses a bind account to search the directory before it checks a user's password. Give that account read-only access to the users and groups it needs, with no write or password-reset rights. Keep its password out of version control and out of shared configuration exports. Agree a rotation process with the directory team so the account can be changed without an outage.
Enforce MFA and strong password rules
OpenEMR 6.0.0 added password length limits, a rule requiring all four character types, reuse prevention for up to five prior passwords and expiration settings. The Securing OpenEMR guide also recommends multi-factor authentication. Directory users authenticate against the directory, so confirm which rules and MFA controls apply to them and which apply only to local accounts.
Review OAuth clients, tokens and SMART scopes
Third-party apps that connect through the FHIR API use OAuth 2.0 and SMART on FHIR scopes. Review registered clients and active tokens on a set schedule, revoke clients that no longer have a named owner, and grant only the scopes each app needs. Public apps should use PKCE, which OpenEMR supports. Ask each vendor who maintains the client before approving it.
Remove install scripts and apply security releases
The Securing OpenEMR guide says to remove setup.php and other admin scripts after installation. OpenEMR 8.3.0 and 8.4.0 fixed security vulnerabilities in the FHIR APIs, and 8.4.1 followed on September 20, 2026. Track the release feed, test each release in staging against your SSO settings, and record the date each security release was applied.
How to test that OpenEMR SSO works and fails safely
The test plan for OpenEMR single sign-on should prove two things: that provisioned users can get in, and that every failure path ends in a refused login with no fallback. Start with the directory cases. A provisioned user in LDAP or Active Directory should sign in and land in the correct OpenEMR account. A valid directory user with no matching OpenEMR account should be refused, because OpenEMR requires the user to exist locally even when the password is checked against the directory. A disabled or removed directory account should also be refused, and the test should run after the directory change has replicated to the servers OpenEMR queries. Run the password cases against the policy you intend to enforce, both in the OpenEMR password settings and in the directory itself, and record which system enforces each rule.
If Google Sign-In is enabled, test one accepted account and at least two rejected ones. The accepted case is an account from an approved domain that already has a matching OpenEMR user. The rejected cases include an account outside the approved domain and an account with no OpenEMR user. For the API side, test the OAuth 2.0 flow for a confidential app and for a PKCE public app. Confirm that a token request without a valid code verifier fails for the public app, and that a scope revoked from a client is denied on new authorization requests and on any token issued afterward. Use a test patient record so a successful call returns data you can check against an expected result, not only an HTTP status code.
Next, test what happens when the directory fails. Break-glass admin access must still work when the directory is unreachable, which means the local emergency account has to be defined, tested and held under your own custody process before go-live. To simulate a directory timeout, block the path from the OpenEMR host to the directory server at the firewall and confirm that the login page returns a clear error and does not accept a cached or partial result. For expired certificates, present a test certificate with an expired date on the directory side, where your environment allows it, and confirm that OpenEMR refuses the connection and logs the failure. Record the lockout behavior you expect: how many failed attempts trigger a lock, how long it lasts, and who clears it. Confirm those values with the OpenEMR vendor documentation, your directory policy and your security team before testing, because they depend on your configuration.
Record evidence for every case: the test ID, the account used, the expected result, the observed result, the timestamp, the matching OpenEMR and directory log entries, and the name of the person who reviewed the outcome. Keep directory audit records and OpenEMR audit entries together so an assessor can trace a single sign-in across both systems. Retest after any change to the directory, certificates, OpenEMR version or password policy. Your security or compliance lead should decide who signs off each failure case, where the evidence is stored and how long it is retained. DeployOpen can prepare the test scripts and evidence template within a fixed-scope engagement, but the results belong to your organization, and independent auditors decide what those results demonstrate.
What to monitor, back up and document after go-live
This table lists the recurring checks for OpenEMR SSO, how often to run each one, and who owns it. Frequencies are placeholders to agree with your security and clinical operations leads before go-live. Use it to assign owners and confirm that each item has a named person and a written procedure.
| Area | What to do | Frequency and owner |
|---|---|---|
| Directory account and certificate expiry | Track the bind account used for LDAP or Active Directory lookups, its password expiry, and the TLS certificate expiry for the directory and OpenEMR endpoints | Agree the review interval with the client. Owner: directory administrator with the OpenEMR system owner |
| Login failure and lockout trends | Review failed sign-ins, directory lockouts and Google Sign-In rejections in OpenEMR and directory logs for unusual patterns | Agree the review interval with the client. Owner: security operations, with the OpenEMR administrator for escalation |
| OAuth client and token inventory | Confirm each registered OAuth 2.0 or SMART on FHIR client is still needed, its redirect URIs and scopes are current, and revoke any unused client | Agree the review interval with the client. Owner: OpenEMR administrator with the application owner for each client |
| Joiner and leaver process | Link directory group changes to OpenEMR user creation and disablement so that leavers lose access in both systems on the same working day | Each joiner and leaver event, with a periodic reconciliation the client sets. Owner: HR or access management with the OpenEMR administrator |
| Configuration and break-glass backups | Back up OpenEMR configuration and database on the client's schedule, and store the break-glass local credential separately from the directory and from the normal backup set | Schedule set by the client, with a restore test agreed in advance. Owner: infrastructure team; break-glass custodian named separately |
| Upgrades and SSO re-testing | Re-test LDAP, Active Directory and Google sign-in, plus any OAuth flows, after each OpenEMR release and after any PHP or web server change | After every upgrade or PHP change, and when security releases are applied. Owner: OpenEMR administrator with the implementation partner if retained |
| Runbook and ownership record | Keep a current runbook covering directory settings, Google Sign-In settings, break-glass use, and a named owner for each integration | Reviewed on each change and at a review interval the client agrees. Owner: service owner, with a named deputy |
Questions teams ask before building OpenEMR SSO
Does OpenEMR create user accounts automatically from LDAP or Active Directory?
No. The user must already exist in OpenEMR before the directory can authenticate them. OpenEMR added LDAP and Active Directory login in version 6.0.0, and it validates the password against the directory while still requiring a matching OpenEMR user record. Teams therefore need a plan for creating and deactivating OpenEMR users, either manually, through an agreed onboarding process, or through a scripted import. Confirm with your own OpenEMR version and configuration how new hires, role assignments and leavers are handled, because a directory account alone does not grant access to clinical data.
Illustrative example: a clinic creates a directory group for front desk staff, but a new hire without an OpenEMR user record still cannot log in until an administrator creates that record and assigns a role.
Does Google Sign-In replace LDAP or Active Directory in OpenEMR?
Not necessarily. Google Sign-In was added in OpenEMR 6.1.0 as a separate login option, so it can run alongside LDAP or Active Directory rather than substituting for them. Whether you need both depends on where your staff identities live and whether every user has a Google account under your control. Decide which identity is authoritative for each user population, how a user is matched to an OpenEMR record, and what happens when a person leaves the organization. Confirm the exact login flow and any restrictions in the configuration for your release before you design the policy.
What does an OpenEMR SSO project cost, and who pays for what?
The cost depends on scope, not on a license fee, because OpenEMR itself is free and licensed under the GNU GPL v3.0. The main cost components are internal staff time from identity, network and clinical operations teams, the effort to configure and test the directory integration, any work on directory group design, and ongoing maintenance when the directory or OpenEMR changes. If you engage a partner, the fee should follow a written scope covering directory types, the number of login methods, test cases and handover. Ask any vendor to separate one-time build work from recurring support, and to state what is excluded.
How long does it take to set up OpenEMR with LDAP, Active Directory or Google sign-in?
No general duration is published here, so treat any timeline as provisional until scope is agreed. The duration is driven by how many login methods you need, how clean your directory groups are, whether you need access controls mapped to OpenEMR roles, how many test users and environments are involved, and how long your change approval process takes. A single directory with a small group design is a very different project from a multi-domain environment with several login methods. Ask for a schedule that lists each phase, its dependencies and the points where your team must provide input.
What must our team provide before an OpenEMR SSO build starts?
Four things are needed before work begins: read access or a service account for the directory, a group design that maps directory groups to OpenEMR roles, a named identity owner who approves changes and handles leavers, and a set of test users covering each role and each login method. Directory access should follow least privilege, and the identity owner must be able to make decisions quickly during testing. Without test users across roles, you will not know whether permissions behave correctly until production. Confirm these inputs with your directory team early, since they often take the longest to arrange.
Can our internal team build OpenEMR SSO without an outside partner?
Often yes, if you have engineers who already run your directory service and can administer a PHP and database application. The work spans directory configuration, OpenEMR administration, testing and documentation, so the team needs skills in both identity and healthcare application operations. Check whether the people who would own the integration after go-live have the time and access to maintain it. A partner is most useful when the internal team lacks directory or OpenEMR experience, when the timeline is fixed, or when independent testing and a written handover are required. Compare the internal estimate with a fixed-scope quote before deciding.
When should we bring in a partner for OpenEMR SSO?
Consider a partner when your scope includes multiple directories, Google Sign-In alongside directory login, or application access for third-party apps. DeployOpen implements, integrates, hardens, documents and supports self-hosted open-source platforms in the client's own infrastructure, and most engagements are fixed-scope with deliverables and timelines agreed in writing before work starts. Ask any partner to show how they test each login path, how they handle role mapping, what documentation you receive and what ongoing support is available. Partner involvement does not transfer ownership of your identity decisions, so define who approves them.
How DeployOpen scopes, builds and hands over OpenEMR SSO
DeployOpen plans, builds and documents OpenEMR login integration inside your own infrastructure, covering LDAP, Active Directory and Google Sign-In alongside the OpenEMR local user model. Engagements are fixed-scope, so the directory sources, user mapping rules and app access requirements are agreed in writing before any configuration begins.
How we scope
- Inventory which directories, Google Workspace domains and OpenEMR user groups must sign in, and who owns each source.
- Confirm that every person who signs in already has an OpenEMR user record, since OpenEMR still requires that record.
- Agree in writing which third-party apps need OAuth 2.0, OpenID Connect or SMART on FHIR access, and which scopes they request.
How we build
- Configure the LDAP or Active Directory login settings in OpenEMR and test password validation against a staging directory.
- Set up Google Sign-In with the agreed domain restrictions and check how existing local accounts behave during the transition.
- Register and test FHIR client applications, including PKCE for public apps, and confirm granted scopes against the agreed list.
How we hand over
- Deliver a written configuration record covering each login source, attribute mapping, fallback local accounts and break-glass procedure.
- Provide test evidence for successful logins, rejected logins, disabled users and each registered app's token and scope behavior.
- Walk your identity and clinical operations staff through onboarding, offboarding and password policy ownership before sign-off.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover, if your team wants that coverage.
- Re-test login paths after each OpenEMR security release, since the project publishes releases on its own schedule.
- Confirm with your directory and identity teams which changes need a retest, such as certificate rotation or new Google domains.
