Skip to content

Latest commit

 

History

History
133 lines (97 loc) · 6.95 KB

README.md

File metadata and controls

133 lines (97 loc) · 6.95 KB
Raw

fhir-works-on-aws-authz-smart

Upgrade notice

Versions 3.1.1 and 3.1.2 of the fhir-works-on-aws-authz-smart package have been deprecated for necessary security updates. Please upgrade to version 3.1.3 or higher. For more information, see the fhir-works-on-aws-authz-smart security advisory.

Purpose

This package is an implementation of the authorization interface from the FHIR Works interface. It uses the Substitutable Medical Applications, Reusable Technologies (SMART on FHIR) specification v1.0.0 to authorize users. Requests are authorized if the requestor or the patient in context is referenced in the resource in question.

To use and deploy this component please follow the overall smart-mainline branch README

Assumptions

The following assumptions have been made while creating this package:

  • An OAuth2 OpenID Connect authorization server already exists and is used as, or in conjunction with, an identity provider.
    • The OAuth2 server complies with the SMART on FHIR specification
    • The OAuth2 server has a JSON Web Key Set endpoint used to get the key for verifying incoming access tokens
  • The identity provider has a user claim (either fhirUser or profile) representing who this user is in context to this FHIR server. This user must be represented by a fully qualified URL in the claim.
    • As an example, the fhirUser claim should look like: https://www.fhir.com/Patient/1234
    • When using user scopes it is assumed that the fhirUser will be in the access token to determine who the requestor is
  • launch scopes and contextual request will be handled by the authorization server.
  • Once launch context is given to the authorization server it will be included with a patient scope and the Patient's resourceType and id in the launch_response_patient claim within the access token.
    • As an example, the launch_response_patient claim should look like: Patient/id

Authorization

This packages uses SMART scopes and the references found in the resources as a way to determine access. Scopes are used to tell the authorization and resource server what access the requestor has. In addition, the references are used to do further authorization, in an attribute based access control model.

Scopes

This resource server supports SMART' v1.0.0 clinical scopes. There are some assumptions made on the authorization and resource server relationship:

  • For patient scopes, there must be a launch_response_patient claim in the access token. The access token with patient scopes but no launch_response_patient claim will be rejected.
  • For user scopes, there must be a fhirUser claim in the access token. The access token with user scopes but no fhirUser claim will be rejected.
  • The access modifiers read and write will give permissions as defined in the incoming SMARTConfig.

The resource server also supports SMART's Flat FHIR or Bulk Data system scope. system scopes have the format system/(:resourceType|*).(read|write|*)– which conveys the same access scope as the matching user format user/(:resourceType|*).(read|write|*).

Attribute Based Access Control (ABAC)

This implementation of the SMART on FHIR specification uses attribute based access control. Access to a resource is given if one of the following statements is true:

  • The fhirUser making the request is considered an Admin (default configuration makes a Practitioner an admin).
  • The fhirUser making the request or the patient in context is looking up their own resource (verified via the resourceType and id).
  • The fhirUser making the request or the patient in context is referenced in the resource in which they are taking action on.

As an example below, the Patient resource is accessible by:

  • Admins of the system
  • Requests with the usage of the system scope
  • Patient/example: via resourceType and id check
  • Patient/diffPatient: because it is referenced in the link field
  • Practitioner/DrBell: because it is referenced in the generalPractitioner field
// Example Patient resource with references
{
  "resourceType": "Patient",
  "id": "example",
  "generalPractitioner": [
    {
      "reference": "Practitioner/DrBell"
    }
  ],
  "link": [
    {
      "type": "seealso",
      "other": {
        "reference": "Patient/diffPatient"
      }
    }
  ],
  "address": [
    {
      "period": {
        "start": "1974-12-25"
      },
      "city": "London",
      "use": "home",
      "line": ["221b Baker St"],
      "district": "Marylebone",
      "postalCode": "6XE",
      "text": "221b Baker St, Marylebone, London NW1 6XE, United Kingdom",
      "type": "both"
    }
  ],
  "deceasedBoolean": false,
  "name": [
    {
      "family": "Holmes",
      "given": ["Sherlock"],
      "use": "official"
    }
  ],
  "gender": "male",
  "active": true
}

Usage

Add this package to your package.json file and install as a dependency. For usage examples please see the deployment component's package.json

Configuration

The SMART specification gives a lot of room for interpretation between the resource and authorization server relationship. With this in mind we developed our SMART implementation to be flexible. The configurations currently available can be viewed in the SMARTConfig.

SMART on FHIR scope rules

Within the SMARTConfig you can see an example implementation of a ScopeRule. The ScopeRule says which operations a scope gives access to. For example, the user/*.write scope provides access to 'create' resource but not 'update' resource.

For an example usage of the SMARTConfig, please see authZConfig.ts in the deployment package.

Dependency tree

This package is dependent on:

Known issues

You can track the issues on the GitHub repository.

Security

See CONTRIBUTING for more information.

License

This project is licensed under the Apache-2.0 License.