Sign-in and access control for the FerroHEALTH products, as Rust libraries.

Documentation · Quick start · What ships today · Licensing

Project

Quality and security

What FerroAUTH does

Every health application has to answer two questions on every request: who is asking, and may they do this? Getting either wrong exposes patient data. FerroAUTH answers both once, for every FerroHEALTH product, so each server checks sign-in and permissions the same tested way.

It does not run a login page or issue passwords. A hospital keeps the sign-in system it already has (such as Keycloak or Microsoft Entra ID), and FerroAUTH checks the access tokens that system hands out: is the token genuine, still valid, meant for this server, and does it grant this action on this patient's record? It speaks SMART, the standard health apps use to ask for access to openEHR and FHIR data.

Who it is for

• Hospital IT and security teams, who can connect every FerroHEALTH product to their own identity provider and see one audit line per request.
• Developers of health software in Rust, who need SMART access checks and machine-to-machine sign-in without writing them again.

Why you can trust what it claims

Every release is signed and carries SLSA build provenance, so you can check that the crate you use is the one built here. The source is public, and every function is in this repository: there is no paid edition with extra features. The OAuth 2.0, SMART and OpenID Connect specifications the crates implement are vendored in the repository at the versions docs/VERSIONS.md pins, so you can check each check against its standard.

Part of FerroHEALTH

FerroHEALTH is five servers, each its own product, that reach each other only over published standards: FerroEHR stores the record, FerroBRIDGE translates it to FHIR and the OMOP research model, FerroFED connects records across organisations and borders, FerroPIX matches patient identities, and FerroTERM serves the code systems (the shared lists of medical terms). Work that every server needs lives in three shared libraries: FerroAUTH for sign-in and access control, FerroAUDIT for the audit trail, and FerroUI for the web consoles. Every FerroHEALTH server checks its callers with FerroAUTH.

Quick start

Add the crate to a Rust project, with the web framework layer and the openEHR scopes:

cargo add ferrohealth-smart@=0.10.1 --features axum,openehr

Pin the version exactly. The crate documentation is the integration guide, and docs/architecture.md has the configuration model.

What ships today

• Token checks: the authorization server's keys read and rotated, every access token validated, and opaque tokens checked by introspection
• SMART on openEHR scopes for templates, compositions and AQL queries, with the patient's EHR from the launch context
• SMART on FHIR scopes with the patient compartment, beside the openEHR scopes in one token
• Roles and assurance levels read from the token, for a product's route table
• Machine sign-in: HTTP Basic against Argon2id hashes, and the OAuth 2.0 client credentials grant
• One audit line per request, never with the token or any content
• The SMART discovery document a product publishes for its clients
• The policy decision, ferrohealth-authz: attribute-based access with an embedded Cedar engine or a remote decision point
• The console sign-in, ferrohealth-session: the OpenID Connect sign-in with PKCE and the operator's session, with idle and absolute lifetimes and the session watch

Published crates (3)

Crate	What it does	Version	Docs	Downloads
ferrohealth-smart	SMART App Launch and OAuth 2.0 resource server: token checks, SMART on openEHR and FHIR scopes, machine sign-in and the audit line
ferrohealth-authz	The policy decision: attribute-based access over the authenticated caller, with an embedded Cedar engine or a remote decision point
ferrohealth-session	The operator consoles' OpenID Connect sign-in and session: PKCE, a memory or sealed-cookie store, idle and absolute lifetimes and the session watch

Learn more

• ferrohealth-smart on docs.rs and the FerroHEALTH book
• Architecture and the pinned specifications
• Changelogs of ferrohealth-smart, ferrohealth-authz and ferrohealth-session, and milestones
• Security policy
• Contributing, code of conduct, support, governance and maintainers

Licence

Business Source License 1.1 (LICENSE), with Apache License 2.0 as the Change License four years after each version; the licensing page says when you need a commercial licence from Cadasto B.V.