This GitHub repository has been migrated. You can now find FHIR Works on AWS at https://github.com/aws-solutions/fhir-works-on-aws.
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.
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
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
fhirUserorprofile) 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
fhirUserclaim should look like:https://www.fhir.com/Patient/1234 - When using
userscopes it is assumed that thefhirUserwill be in the access token to determine who the requestor is
- As an example, the
launchscopes 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
patientscope and the Patient's resourceType and id in thelaunch_response_patientclaim within the access token.- As an example, the
launch_response_patientclaim should look like:Patient/id
- As an example, the
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.
This resource server supports SMART' v1.0.0 clinical scopes. There are some assumptions made on the authorization and resource server relationship:
- For
patientscopes, there must be alaunch_response_patientclaim in the access token. - For
userscopes, there must be afhirUserclaim in the access token. - The access modifiers
readandwritewill 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|*).
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
resourceTypeandid). - 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
systemscope Patient/example: viaresourceTypeandidcheckPatient/diffPatient: because it is referenced in thelinkfieldPractitioner/DrBell: because it is referenced in thegeneralPractitionerfield
// 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
}Add this package to your package.json file and install as a dependency. For usage examples please see the deployment component's package.json
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.
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.
This package is dependent on:
- interface component
- This package defines the interface we are trying to use
You can track the issues on the GitHub repository.
See CONTRIBUTING for more information.
This project is licensed under the Apache-2.0 License.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent