diff --git a/README.md b/README.md index dccaa7c0..b887f4a3 100644 --- a/README.md +++ b/README.md @@ -22,10 +22,10 @@ The requests to the access proxy should have the access token as a Bearer Authorization header. Based on that, the proxy decides whether to grant access for a FHIR query. -Modules involved in FHIR authorization/access-control +Modules involved in FHIR authorization/access-control For more information on the technical design, -[see the design doc](doc/design.md). +[see the design doc](doc/docs/design.md). # Modules @@ -177,7 +177,7 @@ accessing the proxy from an Android emulator, which runs on a separate network. GCP note: if this is not on a VM with proper service account (e.g., on a local host), you need to pass GCP credentials to it, for example by mapping the `.config/gcloud` volume (i.e., add `-v ~/.config/gcloud:/root/.config/gcloud` to -the above command). +the docker command). # How to use this proxy diff --git a/doc/.gitignore b/doc/.gitignore new file mode 100644 index 00000000..a7ca9005 --- /dev/null +++ b/doc/.gitignore @@ -0,0 +1 @@ +site/** diff --git a/doc/README.md b/doc/README.md new file mode 100644 index 00000000..0e264637 --- /dev/null +++ b/doc/README.md @@ -0,0 +1,2 @@ +To generate the documentation web-site content from `docs/` see instructions +[here](https://github.com/google/fhir-data-pipes/tree/master/doc#documentation-site). \ No newline at end of file diff --git a/doc/docs/concepts.md b/doc/docs/concepts.md new file mode 100644 index 00000000..41848328 --- /dev/null +++ b/doc/docs/concepts.md @@ -0,0 +1,201 @@ +# Concepts + +## Common Terminologies + +These are some common terminologies that are important when dealing with access +control in general: + +| Term | Description | +|---------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------| +| Authentication and Identity Provider (IDP) | Who the user is. Establishing the identity can be done through a shared service (e.g., Google, GitHub) or a special one. | +| Authorization (AuthZ) | Given the identity, what can a user access? Has context specific pieces (e.g., scopes) | +| Access-control | How to make sure users access authorized resources only. This is the **core focus of the info gateway**. | +| Client app | An app which needs to access FHIR resources on behalf of a user. | +| User | The user that is using the app; this is the identity being "authenticated". | +| Access Token | A JWT that is provided as a Bearer token when accessing FHIR resources. | +| OAuth2.0 | A standard to grant access to an application on behalf of a user. | +| [SMART-on-FHIR](https://hl7.org/fhir/smart-app-launch/) | Defines workflows that an application can use to securely request and access FHIR data. | + +The following picture helps to visualise the relationship of these concepts. +A client app (e.g., a SMART-on-FHIR app) should first use a process to fetch an +_"access token"_ from the IDP+AuthZ service. For example, this process might +be OAuth's +[Authorization Code Flow](https://auth0.com/docs/get-started/authentication-and-authorization-flow/authorization-code-flow). +This token is then provided on each request to the access-control gateway when +accessing FHIR resources. + +![FHIR Info Gateway](images/Info_Gateway_Overview.png) + +## Info Gateway Modules + +The Info Gateway consists of a core, which is in +the [`server`](https://github.com/google/fhir-gateway/tree/main/server) module, +and a set of _access-checker_ plugins, which can be implemented by third parties +and added to the proxy server. Two sample plugins are implemented in the +[`plugins`](https://github.com/google/fhir-gateway/tree/main/plugins) module. + +There is also a sample +[`exec`](https://github.com/google/fhir-gateway/tree/main/exec) module which +shows how all pieces can be woven together into a single Spring Boot app. It +also has examples for implementing custom end-points. + +**Notes:** + +* [1] Spring Boot is not a requirement for using FHIR Info Gateway; we just use + it to simplify the + [MainApp](https://github.com/google/fhir-gateway/tree/main/exec/src/main/java/com/google/fhir/gateway/MainApp.java). +* [2] The only Spring-related requirement is to do a + [@ComponentScan](https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/context/annotation/ComponentScan.html) + to find all access-checker plugins in the classpath. + +## Configuration parameters + +The configuration parameters are provided through environment variables: + +- `PROXY_TO`: The base url of the FHIR server e.g.: + ```shell + export PROXY_TO=https://example.com/fhir + ``` + +- `TOKEN_ISSUER`: The URL of the access token issuer, e.g.: + ```shell + export TOKEN_ISSUER=http://localhost:9080/auth/realms/test + ``` + The above example is based on the default config of a test IDP+AuthZ + [Keycloak](https://www.keycloak.org/) server. To see how this server is + configured, check the + [docker/keycloak](docker/https://github.com/google/fhir-gateway/tree/main/docker/keycloak) + directory. If you want to use a SMART-on-FHIR (SoF) app use this realm instead + which is based on Keycloak's + [SoF extension](https://github.com/Alvearie/keycloak-extensions-for-fhir): + ```shell + export TOKEN_ISSUER=http://localhost:9080/auth/realms/test-smart + ``` + +- `ACCESS_CHECKER`: The access-checker to use. Each access-checker has a name + (see [plugins](https://github.com/google/fhir-gateway/tree/main/plugins) for + details) and this variable should be set to the name of the plugin to use. For + example, to use one of the sample plugins use one of: + ```shell + export ACCESS_CHECKER=list + export ACCESS_CHECKER=patient + ``` + For more information on how access-checkers work and building your own, + see [section on access checkers](#access-checkers). + +- `ALLOWED_QUERIES_FILE`: A list of URL requests that should bypass the access + checker and always be allowed. + [`AllowedQueriesChecker`](https://github.com/google/fhir-gateway/blob/main/server/src/main/java/com/google/fhir/gateway/AllowedQueriesChecker.java) + compares the incoming request with a configured set of allowed-queries. The + intended use of this checker is to override all other access-checkers for + certain user-defined criteria. The user defines their criteria in a config + file and if the URL query matches an entry in the config file, access is + granted. [`AllowedQueriesConfig`](https://github.com/google/fhir-gateway/blob/main/server/src/main/java/com/google/fhir/gateway/AllowedQueriesConfig.java) + shows all the supported configurations. An example config file is + [`hapi_page_url_allowed_queries.json`](https://github.com/google/fhir-gateway/blob/main/resources/hapi_page_url_allowed_queries.json). + To use this file with `ALLOWED_QUERIES_FILE`: + ```shell + export ALLOWED_QUERIES_FILE="resources/hapi_page_url_allowed_queries.json" + ``` + +- `BACKEND_TYPE`: The type of backend, either `HAPI` or `GCP`. `HAPI` should be + used for most FHIR servers, while `GCP` should be used for GCP FHIR stores. + +## Access Checkers + +FHIR Info Gateway uses _access checker plugins_ to define the logic it uses to +make decisions for access requests. Most users should create an access checker +plugin to implement the access control logic for a specific use case. You can +learn about access checker plugins by looking at the sample access checker +[plugins](https://github.com/google/fhir-gateway/tree/main/plugins/src/main/java/com/google/fhir/gateway/plugin). + +See tutorial on +[creating an access checker plugin](tutorial_first_access_checker.md). The core +of FHIR Info Gateway, provides libraries that make it easier to create +access-checkers. For example, +[PatientFinder](https://github.com/google/fhir-gateway/blob/main/server/src/main/java/com/google/fhir/gateway/interfaces/PatientFinder.java) +can be used to limit access to a certain set of patients. + +### Patient access checker plugin +The [`PatientAccessChecker` plugin](https://github.com/google/fhir-gateway/blob/main/plugins/src/main/java/com/google/fhir/gateway/plugin/PatientAccessChecker.java) +can be used if the client is a SMART-on-FHIR app that uses the +[standalone app launch flow](https://www.hl7.org/fhir/smart-app-launch/app-launch.html#launch-app-standalone-launch). +It expects a `patient_id` claim in the access-token and limits access to FHIR +resources that belong to that patient. It supports +[SoF scopes](https://www.hl7.org/fhir/smart-app-launch/scopes-and-launch-context.html#scopes-for-requesting-clinical-data) +(both v1 and v2). + +### Explore the List access checker plugin + +The [`ListAccessChecker` plugin](https://github.com/google/fhir-gateway/blob/main/plugins/src/main/java/com/google/fhir/gateway/plugin/ListAccessChecker.java) +is a simple example of list-based access control. It works by assigning each +user a [FHIR `List` resource](https://www.hl7.org/fhir/list.html) which contains +a list of references of `Patient` resources that the user should have access to. +When a client makes a request to FHIR Information Gateway, +the `ListAccessChecker` grants access if all patients that are referenced in +the query are on the user's patient access list. + +The plugin expects the patient `List` resource's ID to be included as the value +to a claim named `patient_list` in the access token used to authorize requests +to the FHIR Information Gateway server. For example, following the +[test Docker deployment](https://github.com/google/fhir-access-proxy/wiki/Try-out-FHIR-Information-Gateway) +you may get a decoded JWT like the following (note if you use the default +settings you will get more claims that are not relevant to the access-checker +logic; so they are removed in this example): + +```json +{ + "header": { + "alg": "RS256", + "typ": "JWT", + "kid": "MnXk25Vp_W6X_UMi4sA3_iEMwuumZkwhOuE8eMY8LFo" + }, + "payload": { + "exp": 1673990497, + "iat": 1673990197, + "jti": "5bb2b1a0-e9c6-442f-abfd-a22f1798fd11", + "iss": "http://localhost:9080/auth/realms/test", + "aud": "account", + "sub": "76315cd1-9681-4a4e-b733-e6d811058e40", + "typ": "Bearer", + "azp": "my-fhir-client", + "session_state": "967e82a2-0188-4774-abbc-6bb4ce26536f", + "acr": "1", + "scope": "email profile", + "sid": "967e82a2-0188-4774-abbc-6bb4ce26536f", + "email_verified": false, + "patient_list": "patient-list-example", + "preferred_username": "testuser", + "group": [ + "fhirUser" + ] + } +} +``` + +Here `patient_list` equals `patient-list-example`, so if your FHIR server is +at `http://localhost:8099/fhir/` then this user's patient access list resource +is `http://localhost:8099/fhir/List/patient-list-example`. + +The decoded JWT is passed to the +[`AccessCheckerFactory`](https://github.com/google/fhir-gateway/blob/main/server/src/main/java/com/google/fhir/gateway/interfaces/AccessCheckerFactory.java) +implementation's `create()` function. The `ListAccessChecker` implementation +extracts the patient list ID from the JWT and saves it internally. Custom JWT +claims in the access token can be a good way to pass additional information to +your access checker beyond what your authentication server provides. + +`ListAccessChecker`'s +[`checkAccess`](https://github.com/google/fhir-gateway/blob/19447d7152804d2b790f22cc44ad3b1ca21c7040/plugins/src/main/java/com/google/fhir/gateway/plugin/ListAccessChecker.java#L157) +function splits access logic according to the HTTP method. Simple yes/no access +decisions like `processGet()` use the +[`NoOpAccessDecision`](https://github.com/google/fhir-gateway/blob/main/server/src/main/java/com/google/fhir/gateway/interfaces/NoOpAccessDecision.java) +class which you may also use in your own implementations. Alternatively, you may +have more complex decision needs, such as doing additional processing after the +data access like +[`processPost()`](https://github.com/google/fhir-gateway/blob/19447d7152804d2b790f22cc44ad3b1ca21c7040/plugins/src/main/java/com/google/fhir/gateway/plugin/ListAccessChecker.java#L202). +In this case, implement your own version of +[`AccessDecision`](https://github.com/google/fhir-access-proxy/blob/main/server/src/main/java/com/google/fhir/gateway/interfaces/AccessDecision.java). +The `ListAccessChecker` allows clients to create new `Patient` resources without +restriction (always allow access), and then as a post-processing step adds the +new Patient id to the client's patient access list. You can see this implemented +in [`AccessGrantedAndUpdateList`](https://github.com/google/fhir-access-proxy/blob/main/plugins/src/main/java/com/google/fhir/gateway/plugin/AccessGrantedAndUpdateList.java). diff --git a/doc/docs/contribute.md b/doc/docs/contribute.md new file mode 100644 index 00000000..d3aa0674 --- /dev/null +++ b/doc/docs/contribute.md @@ -0,0 +1,31 @@ +# How to Contribute + +We'd love to accept your patches and contributions to this project. There are +just a few small guidelines you need to follow. + +## Contributor License Agreement + +Contributions to this project must be accompanied by a Contributor License +Agreement (CLA). You (or your employer) retain the copyright to your +contribution; this simply gives us permission to use and redistribute your +contributions as part of the project. Head over +to to see your current agreements on file +or to sign a new one. + +You generally only need to submit a CLA once, so if you've already submitted +one (even if it was for a different project), you probably don't need to do it +again. + +## Code reviews + +All code changes require review. We use GitHub pull-requests for this purpose. + +* Consult [GitHub Help](https://help.github.com/articles/about-pull-requests/) + for more information on using pull requests. + +* We use GitHub for issue tracking. + +## Community Guidelines + +This project +follows [Google's Open Source Community Guidelines](https://opensource.google/conduct/). \ No newline at end of file diff --git a/doc/design.md b/doc/docs/design.md similarity index 99% rename from doc/design.md rename to doc/docs/design.md index 7f47e551..80f43bae 100644 --- a/doc/design.md +++ b/doc/docs/design.md @@ -21,7 +21,7 @@ For more context, please see the [Introduction](#introduction) section. Here is a summary of proposals and decisions in this design document, for the first version (V1) of the FHIR gateway: - +![High-level Architecture](images/summary.png) - There are three main components responsible for access decisions: an Identity Provider (IDP) which authenticates the user, an Authorization server (AuthZ) @@ -198,8 +198,6 @@ sometimes referred to as the Identity and Access Management (IAM) or simply We also have an "access gateway" which is responsible for processing any access request for the FHIR server and is the main focus of this design doc. - - ### Authentication and authorization flow Before the user can access data, their identity should be established and based @@ -226,7 +224,7 @@ to use [PKCE](https://auth0.com/docs/authorization/flows/authorization-code-flow-with-proof-key-for-code-exchange-pkce) which is not shown in this diagram)[^1]: - +![flow](images/flow.png) Here is a brief description of each step: @@ -265,7 +263,7 @@ to AuthZ which in turn maps the user identity to some access rules to FHIR resources. Popular IAM servers like [Keycloak](https://www.keycloak.org/), support separate/3rd party IDPs. - +![separate](images/separate.png) **Integrated AuthZ+Gateway** @@ -277,7 +275,7 @@ simplifies the deployment architecture significantly, however we note that the elimination of the access token might be incompatible with some use-cases like SoF apps. - +![integrated](images/integrated.png) ## Access gateway diff --git a/doc/docs/getting_started.md b/doc/docs/getting_started.md new file mode 100644 index 00000000..de113993 --- /dev/null +++ b/doc/docs/getting_started.md @@ -0,0 +1,124 @@ +# Getting Started + +!!! tip "Quick Start Guide" + + The easiest way to get started is to follow the ["Run the Info Gateway in Docker" guide](tutorial_docker.md). + +## Building from source + +To build all modules, from the root run (if you are a developer, do _not_ use +`spotless.apply.skip=true`): + +```shell +mvn package -Dspotless.apply.skip=true +``` + +The `server` and `plugins` modules can be run together through this executable +jar (`--server.port` is just one of the many default Spring Boot flags): + +```shell +java -jar exec/target/exec-0.1.0.jar --server.port=8081 +``` + +Note that extra access-checker plugins can be added through the `loader.path` +property (although it is probably easier to build them into your server): + +```shell +java -Dloader.path="PATH-TO-ADDITIONAL-PLUGINGS/custom-plugins.jar" \ + -jar exec/target/exec-0.1.0.jar --server.port=8081 +``` + +The plugin library can be swapped with any third party access-checker as +described in +the [plugins](https://github.com/google/fhir-gateway/tree/main/plugins) +directory. Learn more about [AccessCheckers](concepts.md#access-checkers). + +## Gateway to server access + +The proxy must be able to send FHIR queries to the FHIR server. The FHIR server +must be configured to accept connections from the proxy while rejecting most +other requests. + +If you use +a [GCP FHIR store](https://cloud.google.com/healthcare-api/docs/concepts/fhir) +you have the following options: + +- If you have access to the FHIR store, you can use your own credentials by + doing [application-default login](https://cloud.google.com/sdk/gcloud/reference/auth/application-default/login). + This is useful when testing the proxy on your local machine, and you have + access to the FHIR server through your credentials. + +- Use a service account with required access (e.g., "Healthcare FHIR Resource + Reader", "Healthcare Dataset Viewer", "Healthcare FHIR Store Viewer"). You can + then run the proxy in the same GCP project on a VM with this service account. + +- [not-recommended] You can create and download a key file for the above service + account, then use it with: + ```shell + export GOOGLE_APPLICATION_CREDENTIALS="PATH_TO_THE_JSON_KEY_FILE" + ``` + +## Running the gateway + +!!! tip "Configuration Parameters" + + Take a moment to review the [configuration parameters](concepts.md#configuration-parameters). + +Once you have set all the above, you can run the proxy server. The sample `exec` +module uses [Apache Tomcat](https://tomcat.apache.org/) +through [Spring Boot](https://spring.io/projects/spring-boot) and the usual +configuration parameters apply, e.g., to run on port 8081: + +```shell +java -jar exec/target/exec-0.1.0.jar --server.port=8081 +``` + +!!! tip "Android Emulator" + + If the `TOKEN_ISSUER` is on the `localhost` and you are accessing the gateway from an Android emulator (which runs on a separate network), you may need to bypass proxy's token issuer check by setting `RUN_MODE=DEV` environment variable. + +## Using the Info Gateway + +In this section we assume that a Keycloak instance is set up using the sample +docker setup provided +[here](https://github.com/google/fhir-gateway/blob/main/docker/keycloak/config-compose.yaml). +If you have a different IDP+AuthZ setup, you need to adjust the parameters +below accordingly. + +Once the gateway is running, we first need to fetch an access token from +the `TOKEN_ISSUER`; you need the test server's `username` and `password` plus +the `client_id`: + +```shell +$ curl -X POST -d 'client_id=CLIENT_ID' -d 'username=testuser' \ + -d 'password=testpass' -d 'grant_type=password' \ +"http://localhost:9080/auth/realms/test/protocol/openid-connect/token" +``` + +We need the `access_token` of the returned JSON to be able to convince the +gateway to authorize our FHIR requests (there is also a `refresh_token` in the +above response). Assuming this is stored in the `ACCESS_TOKEN` environment +variable, we can access the FHIR store: + +```shell +$ curl -X GET -H "Authorization: Bearer ${ACCESS_TOKEN}" \ +-H "Content-Type: application/json; charset=utf-8" \ +'http://localhost:8081/Patient/f16b5191-af47-4c5a-b9ca-71e0a4365824' +``` + +```shell +$ curl -X PUT -H "Authorization: Bearer ${ACCESS_TOKEN}" \ +-H "Content-Type: application/json; charset=utf-8" \ +'http://localhost:8081/Patient/f16b5191-af47-4c5a-b9ca-71e0a4365824' \ +-d @Patient_f16b5191-af47-4c5a-b9ca-71e0a4365824_modified.json +``` + +Of course, whether a query is accepted or denied, depends on the access-checker +used and the `ACCESS_TOKEN` claims. + +For example: + +* For `ACCESS_CHECKER=list` there should be a `patient_list` claim which is the + ID of a `List` FHIR resource with all the patients that this user has access + to. +* For `ACCESS_CHECKER=patient`, there should be a `patient_id` claim with a valid Patient resource ID. \ No newline at end of file diff --git a/doc/docs/images/Info_Gateway_Overview.png b/doc/docs/images/Info_Gateway_Overview.png new file mode 100644 index 00000000..5cb081af Binary files /dev/null and b/doc/docs/images/Info_Gateway_Overview.png differ diff --git a/doc/docs/images/Info_Gateway_Use_Cases.png b/doc/docs/images/Info_Gateway_Use_Cases.png new file mode 100644 index 00000000..d0be0d7e Binary files /dev/null and b/doc/docs/images/Info_Gateway_Use_Cases.png differ diff --git a/doc/flow.png b/doc/docs/images/flow.png similarity index 100% rename from doc/flow.png rename to doc/docs/images/flow.png diff --git a/doc/integrated.png b/doc/docs/images/integrated.png similarity index 100% rename from doc/integrated.png rename to doc/docs/images/integrated.png diff --git a/doc/separate.png b/doc/docs/images/separate.png similarity index 100% rename from doc/separate.png rename to doc/docs/images/separate.png diff --git a/doc/summary.png b/doc/docs/images/summary.png similarity index 100% rename from doc/summary.png rename to doc/docs/images/summary.png diff --git a/doc/docs/index.md b/doc/docs/index.md new file mode 100644 index 00000000..cebbaf8f --- /dev/null +++ b/doc/docs/index.md @@ -0,0 +1,55 @@ +# FHIR Info Gateway + +The Info Gateway is a reverse proxy which controls client access to FHIR +resources on a server. It works by inspecting FHIR requests and verifying that +the client is authorized to access the requested resources. + +It makes it easier for developers to enforce various forms of authorization +policies including organizational role based access control (RBAC) policies +when working with FHIR data. + +* To enable authorization and access-control (ACL) policy enforcement between a + client application and a FHIR server, the Info Gateway is used along with an + Identity Provider (IDP) and Authorization server (AuthZ). +* The IDP can be a generic OpenID Connect (OIDC) compliant service or a special + purpose one. +* The IDP+AuthZ should provide a JSON Web Token (JWT) to the client. The client + uses this as a Bearer access-token (AT) when sending FHIR requests. +* A sample end-to-end implementation with Keycloak as the IDP+AuthZ service is + provided and has been tested with HAPI FHIR and Google Cloud Healthcare + FHIR-store as the FHIR server. + +![FHIR Info Gateway](images/Info_Gateway_Overview.png) + +## Key Features +Key features of the Info Gateway include: + +* A stand-alone service that can work with any FHIR compliant servers. +* A pluggable architecture for defining an access-checker to allow for + implementation configurability. +* Query filtering to block/allow specific queries. +* Post-processing of the results returned by the FHIR-server, for example to + remove sensitive information. +* A generic interface for implementing custom endpoints, e.g., a sync endpoint + to return updates for all patients assigned to a health-worker. + +## Common use cases + +The Info Gateway is designed to solve for a generic problem, that is, access +control for **any client** and **any FHIR server**. + +Common access-check use-cases include: + +1. For a mobile app used by community based front-line health workers possibly + with offline support +2. Web based dashboard used by program admins +3. For a personal health record app used by patients or caregivers +4. To enable SMART-on-FHIR apps for patient or system level scopes + +FHIR Info Gateway is implemented as a "FHIR facade", i.e., it is a FHIR server +itself which is implemented using the +[HAPI FHIR Plain Server](https://hapifhir.io/hapi-fhir/docs/server_plain/introduction.html) +library: + +![FHIR Info Gateway](images/Info_Gateway_Use_Cases.png) + diff --git a/doc/docs/release_process.md b/doc/docs/release_process.md new file mode 100644 index 00000000..32b97669 --- /dev/null +++ b/doc/docs/release_process.md @@ -0,0 +1,44 @@ +# Semantic versioning + +FHIR Info Gateway artifacts are released on +[Maven](https://central.sonatype.com/namespace/com.google.fhir.gateway). A +docker image is also published on +[GCP Artifact Registry](https://console.cloud.google.com/artifacts/docker/fhir-proxy-build/us/stable/fhir-gateway?project=fhir-proxy-build). + +Versioning across all Open Health Stack components is based on the +major.minor.patch scheme and respects Semantic Versioning. + +Respecting Semantic Versioning is important for multiple reasons: + +* It guarantees simple minor version upgrades, as long as you only use the + public APIs. +* A new major version is an opportunity to thoroughly document breaking changes. +* A new major/minor version is an opportunity to communicate new features + through a blog post. + +## Major versions + +The major version number is incremented on every breaking change. + +Whenever a new major version is released, we publish: + +* a blog post with feature highlights, major bug fixes, breaking changes, and + upgrade instructions. +* an exhaustive changelog entry via the release notes + +## Minor versions + +The minor version number is incremented on every significant retro-compatible +change. + +Whenever a new minor version is released, we publish: + +* an exhaustive changelog entry via the release notes. + +## Patch versions + +The patch version number is incremented on bugfixes releases. + +Whenever a new patch version is released, we publish: + +* an exhaustive changelog entry. \ No newline at end of file diff --git a/doc/docs/support.md b/doc/docs/support.md new file mode 100644 index 00000000..fe6e8ea3 --- /dev/null +++ b/doc/docs/support.md @@ -0,0 +1,46 @@ +# Support + +On this page we've listed some ways you can get technical support along with +Open Health Stack communities and forums that you can be a part of. + +Before participating please read +our [code of conduct](https://opensource.google/conduct) that we expect all +community members to adhere too. + +## Developer calls + +There are weekly Open Health Stack developer calls that you are welcome to join. + +* Calls are on Thursdays and **alternate** between Android FHIR SDK and OHS + server side components (FHIR Data Pipes and Info Gateway). +* See the schedule below for more details. +* To be added to the calls, please email: `hello-ohs[at]google.com`. + +**Developer call schedule** + +| OHS Developers Call | GMT | East Africa | India | +| :------------ | :-: | :---------: | :---: | +| Android FHIR SDK | 10:00 UK | 12:00 Nairobi | 14:30 Delhi | +| Analytics and Info Gateway | 13:00 UK | 15:00 Nairobi | 17:30 Delhi | + +## Discussion forums + +We are in the process of setting up a dedicated discussion forum for Open Health +Stack. In the meantime, you can reach out to `hello-ohs[at]google.com`. + +## Stack Overflow + +Stack Overflow is a popular forum to ask code-level questions or if you're stuck +with a specific error. It would be nice to tag your question with +`open-health-stack`! + +## Bugs or Feature requests + +Before submitting a bug or filing a feature reqeust, please review the open +issues on +our [github repository](https://github.com/google/fhir-data-pipes/issues). + +If your issue is there, please add a comment. Otherwise, create a new issue to +file a bug or submit a new feature request. + +Please review the [contributing section](contribute.md). \ No newline at end of file diff --git a/doc/docs/tutorial_docker.md b/doc/docs/tutorial_docker.md new file mode 100644 index 00000000..0a10e03f --- /dev/null +++ b/doc/docs/tutorial_docker.md @@ -0,0 +1,148 @@ +# Run the Info Gateway in Docker + +In this guide, you will learn how to run FHIR Info Gateway in a Docker +image, and see it work in concert with a sample Keycloak and HAPI FHIR server +running on your local machine. We assume that +[Docker](https://docs.docker.com/get-docker/) and +[Docker Compose](https://docs.docker.com/compose/) are installed. The sample +commands are shown on a Linux/shell environment and may need to be adjusted for +your environment. + +!!! tip "Important" + + The setup used in this guide **should not be used in a production environment**. It is designed to get things up and running quickly for demonstration or testing purposes only. The FHIR Information Gateway Docker image might be used in a production environment if deployed appropriately, however the example access-checker plugins may not satisfy real-world use cases. + +## Start the Docker images + +1. Clone + the [FHIR Info Gateway repo from GitHub](https://github.com/google/fhir-gateway). +2. Open a terminal window and `cd` to the directory where you cloned the repo. +3. Bring up the sample Keycloak service using `docker compose`. + ```shell + docker compose -f docker/keycloak/config-compose.yaml up + ``` + This runs an instance of [Keycloak](https://www.keycloak.org/) with + [SoF extension](https://github.com/Alvearie/keycloak-extensions-for-fhir), + preloaded with a test configuration. It is accessible at + `http://localhost:9080`. + +4. Run the sample HAPI FHIR server Docker image. + ```shell + docker run -p 8099:8080 us-docker.pkg.dev/fhir-proxy-build/stable/hapi-synthea:latest + ``` + The server is preloaded with synthetic patient data and a FHIR + `List/patient-list-example` resource. + +5. Run the FHIR Information Gateway Docker image with the `list` access + checker. + ```shell + docker run \ + -e TOKEN_ISSUER=http://localhost:9080/auth/realms/test \ + -e PROXY_TO=http://localhost:8099/fhir \ + -e BACKEND_TYPE=HAPI \ + -e RUN_MODE=PROD \ + -e ACCESS_CHECKER=list \ + --network=host \ + us-docker.pkg.dev/fhir-proxy-build/stable/fhir-gateway:latest + ``` + +Several environment variables are used to configure FHIR Information Gateway: + +* `TOKEN_ISSUER`: The URL of the token issuer. For Keycloak this is typically + `http://{keycloak-host}:{keycloak-port}/auth/realms/{realm-name}`. +* `PROXY_TO`: The [Service Base URL](https://build.fhir.org/http.html#root) of + the FHIR server that FHIR Access Proxy communicates with. +* `BACKEND_TYPE`: One of `HAPI` for a HAPI FHIR Server or `GCP` for a Cloud + Healthcare FHIR-store. +* `RUN_MODE`: One of `PROD` or `DEV`. DEV removes validation of the issuer URL, + which is useful when using the docker image with an Android emulator as the + emulator runs on its own virtual network and sees a different address than + the host. +* `ACCESS_CHECKER`: The access-checker plugin to use. The Docker image includes + the [`list`](https://github.com/google/fhir-gateway/blob/main/plugins/src/main/java/com/google/fhir/gateway/plugin/ListAccessChecker.java) + and [`patient`](https://github.com/google/fhir-gateway/blob/main/plugins/src/main/java/com/google/fhir/gateway/plugin/PatientAccessChecker.java) + example access-checkers. + +!!! tip "GCP Note" + + If the FHIR server is GCP FHIR-store and the gateway is not run on a VM with proper service account (e.g., running on a localhost), you need to pass GCP credentials to it, for example by mapping the `.config/gcloud` volume (i.e., add `-v ~/.config/gcloud:/root/.config/gcloud` to the above command). + +## Examine the sample Keycloak configuration + +In this section you will review the Keycloak settings relevant to the FHIR +Information Gateway with the sample `list` access checker plugin. + +1. Open a web browser and navigate to `http://localhost:9080/auth/admin/`. +2. Login using user `admin` and password `adminpass`. +3. Select the `test` realm. +4. From the left menu, find the **Manage** section and click **Users**. Click + **View all users**, then click the **ID** of the only result to view the + user `Testuser`. +5. Select the **Attributes** tab. Note the attribute `patient_list` with value + `patient-list-example`. The client `my-fhir-client` has a corresponding + [User Attribute + mapper](https://www.keycloak.org/docs/latest/server_admin/#_protocol-mappers) + to add this as a claim to the access token JWT, which you can see under + **Clients > my-fhir-client > Mappers > list-mapper**. +6. `patient-list-example` is the ID of a FHIR List resource which lists all the + Patient resources the user can access. Open + `http://localhost:8099/fhir/List/patient-list-example` to see the list + referencing two Patients: + + ```json + ... + "entry": [ { + "item": { + "reference": "Patient/75270" + } + }, { + "item": { + "reference": "Patient/3810" + } + } ] + ... + ``` + +## Get a FHIR resource using FHIR Information Gateway + +1. Get an access token for the test user. This command uses + [jq](https://stedolan.github.io/jq/) to parse the access token from the JSON + response. + + ```shell + ACCESS_TOKEN="$( \ + curl -X POST \ + -d 'client_id=my-fhir-client' \ + -d 'username=testuser' \ + -d 'password=testpass' \ + -d 'grant_type=password' \ + "http://localhost:9080/auth/realms/test/protocol/openid-connect/token" \ + | jq .access_token \ + | tr -d '"' \ + )" + ``` + + You will need to rerun this command when the access token expires after 5 + minutes. In a real application, implement your Identity Provider's + authentication flow, including refresh tokens. + +2. Send a request to FHIR Information Gateway using the access token. + + ```shell + curl -X GET -H "Authorization: Bearer ${ACCESS_TOKEN}" \ + -H "Content-Type: application/json; charset=utf-8" \ + 'http://localhost:8080/fhir/Patient/75270' + ``` + + You should get a response containing the Patient resource. + +3. Send a second request for a patient the user does not have access to. + + ```shell + curl -X GET -H "Authorization: Bearer ${ACCESS_TOKEN}" \ + -H "Content-Type: application/json; charset=utf-8" \ + 'http://localhost:8080/fhir/Patient/3' + ``` + + You should get a response of `User is not authorized to GET + http://localhost:8080/fhir/Patient/3`. \ No newline at end of file diff --git a/doc/docs/tutorial_first_access_checker.md b/doc/docs/tutorial_first_access_checker.md new file mode 100644 index 00000000..0aa539dc --- /dev/null +++ b/doc/docs/tutorial_first_access_checker.md @@ -0,0 +1,99 @@ +# Create an access checker plugin + +In this guide you will create your own access checker plugin. + +## Implement the `AccessCheckerFactory` interface + +To create your own access checker plugin, create an implementation of +the [`AccessCheckerFactory` interface](https://github.com/google/fhir-gateway/blob/main/server/src/main/java/com/google/fhir/gateway/interfaces/AccessCheckerFactory.java) +annotated with a `@Named(value = "name")` annotation defining the name of the +plugin. + +The most important parts are to implement a +custom [`AccessChecker`](https://github.com/google/fhir-gateway/blob/main/server/src/main/java/com/google/fhir/gateway/interfaces/AccessChecker.java) +to be returned by the factory and its `checkAccess` function which specifies if +access is granted or not by returning +an [`AccessDecision`](https://github.com/google/fhir-gateway/blob/main/server/src/main/java/com/google/fhir/gateway/interfaces/AccessDecision.java). + +## Create a new class + +The simplest way to create your own access checker is to make a new class file +in the `plugins/src/main/java/com/google/fhir/gateway/plugin` directory, next to +the existing sample plugins. The following code can be used as a starting +template for a minimal access checker: + +```java +package com.google.fhir.gateway.plugin; + +import ca.uhn.fhir.context.FhirContext; +import com.auth0.jwt.interfaces.DecodedJWT; +import com.google.fhir.gateway.FhirUtil; +import com.google.fhir.gateway.HttpFhirClient; +import com.google.fhir.gateway.JwtUtil; +import com.google.fhir.gateway.interfaces.AccessChecker; +import com.google.fhir.gateway.interfaces.AccessCheckerFactory; +import com.google.fhir.gateway.interfaces.AccessDecision; +import com.google.fhir.gateway.interfaces.NoOpAccessDecision; +import com.google.fhir.gateway.interfaces.PatientFinder; +import com.google.fhir.gateway.interfaces.RequestDetailsReader; +import javax.inject.Named; + +public class MyAccessChecker implements AccessChecker { + + private final FhirContext fhirContext; + private final HttpFhirClient httpFhirClient; + private final String claim; + private final PatientFinder patientFinder; + + // We're not using any of the parameters here, but real access checkers + // would likely use some/all. + private MyAccessChecker( + HttpFhirClient httpFhirClient, + String claim, + FhirContext fhirContext, + PatientFinder patientFinder) { + this.fhirContext = fhirContext; + this.claim = claim; + this.httpFhirClient = httpFhirClient; + this.patientFinder = patientFinder; + } + + @Override + public AccessDecision checkAccess(RequestDetailsReader requestDetails) { + // Implement your access logic here. + return NoOpAccessDecision.accessGranted(); + } + + // The factory must be thread-safe but the AccessChecker instances it returns + // do not need to be thread-safe. + @Named(value = "sample") + public static class Factory implements AccessCheckerFactory { + + static final String CLAIM = "sub"; + + private String getClaim(DecodedJWT jwt) { + return FhirUtil.checkIdOrFail(JwtUtil.getClaimOrDie(jwt, CLAIM)); + } + + @Override + public AccessChecker create( + DecodedJWT jwt, + HttpFhirClient httpFhirClient, + FhirContext fhirContext, + PatientFinder patientFinder) { + String claim = getClaim(jwt); + return new MyAccessChecker(httpFhirClient, claim, fhirContext, patientFinder); + } + } +} + +``` + +## Rebuild to include the plugin +Once you're done implementing your access checker plugin, rebuild using +`mvn package` from the root of the project to include the plugin, set the +access-checker using e.g. `export ACCESS_CHECKER=sample` + +## Run the gateway +Run the gateway using e.g. +`java -jar exec/target/exec-0.1.0.jar --server.port=8080`. \ No newline at end of file diff --git a/doc/docs/tutorials.md b/doc/docs/tutorials.md new file mode 100644 index 00000000..6a087c64 --- /dev/null +++ b/doc/docs/tutorials.md @@ -0,0 +1,2 @@ +# Tutorials +Explore the developer resources to learn how to get started with the Info Gateway \ No newline at end of file diff --git a/doc/mkdocs.yml b/doc/mkdocs.yml new file mode 100644 index 00000000..d37a3704 --- /dev/null +++ b/doc/mkdocs.yml @@ -0,0 +1,81 @@ +site_name: FHIR Info Gateway Docs +theme: + name: material + features: +# - navigation.tabs + - navigation.tabs.sticky + - navigation.section + - toc.follow +# - toc.integrate + - navigation.top + - navigation.path + - search.suggest + - search.highlight + - content.tabs.link + - content.code.annotation + - content.code.copy + - navigation.footer + language: en + palette: + - scheme: default + toggle: + icon: material/toggle-switch-off-outline + name: Switch to dark mode + primary: indigo + accent: purple + - scheme: slate + toggle: + icon: material/toggle-switch + name: Switch to light mode + primary: indigo + accent: lime + icon: + repo: fontawesome/brands/github + +font: + text: inter + + +plugins: + - search + +site_url: https://example.com/info-gateway/ + +repo_url: https://github.com/google/fhir-gateway + +repo_name: FHIR Info Gateway + +nav: + - Home: 'index.md' + - Concepts: 'concepts.md' + - Getting Started: 'getting_started.md' + - Tutorials: + - 'Run the Info Gateway in Docker' : 'tutorial_docker.md' + - 'Create an access checker' : 'tutorial_first_access_checker.md' + - Design: 'design.md' + - Community: + - 'Support' : 'support.md' + - 'Contributing': 'contribute.md' + - 'Release process': 'release_process.md' + +markdown_extensions: + - pymdownx.highlight: + anchor_linenums: true + - pymdownx.inlinehilite + - pymdownx.snippets + - admonition + - pymdownx.arithmatex: + generic: true + - footnotes + - pymdownx.details + - pymdownx.superfences + - pymdownx.tabbed: + alternate_style: true + - pymdownx.mark + - attr_list + - pymdownx.emoji: + emoji_index: !!python/name:materialx.emoji.twemoji + emoji_generator: !!python/name:materialx.emoji.to_svg + +copyright: | + © 2024 Google Health Open Health Stack \ No newline at end of file diff --git a/doc/requirements.txt b/doc/requirements.txt new file mode 100644 index 00000000..9a8a4ca4 --- /dev/null +++ b/doc/requirements.txt @@ -0,0 +1,2 @@ +mkdocs +mkdocs-material