Authorization and Consent - Smile CDR Documentation
Authorization and Consent
The concepts of consent and authorization in Smile CDR are related but distinct. When a FHIR request is being processed, there are two specific layers that are invoked to make decisions on whether the request can proceed and what data is ultimately disclosed: The Authorization Service and the Consent Service.
The following diagrams show the functionality provided by each of these layers.
Authorization Service
The following diagram shows the primary purpose of the Authorization Service.
The Authorization Service looks at every request (including both the details of the request, and any data being returned) and makes a determination about whether the operation should be permitted or blocked.
As inputs into its decision, the Authorization Service uses:
- Any Roles and Permissions granted to the user or their session
- Any SMART on FHIR scopes that have been approved for the requesting client (generally applies only to SMART on FHIR Interactive User Launch flows)
- Any Roles and Permissions granted to the client (generally applies only to SMART on FHIR Client Credentials flow)
- Any Roles and Permissions granted to the Anonymous user when invoking an anonymous operation.
The Authorization Service makes a simple binary determination: either the request is authorized, or it is blocked and the client will see an HTTP 403 Forbidden response.
Consent Service
The following diagram shows the primary purpose of the Consent Service.
The Consent Service looks at every request and makes a determination about whether any data being exposed is acceptable for the user to see, and optionally removes it from what is returned. This removal may include filtering out entire resources (i.e. blocking), and/or filtering out certain elements of resources being returned (i.e. masking).
The consent service is a very flexible mechanism, based entirely on programmed consent rules. Unlike the Authorization Service, which uses a fixed set of inputs (permissions and scopes) to make decisions, the consent script may use any of a number of inputs including but not limited to:
- Logged-in User and Session Details
- Consent Records (i.e. Consent resources that have been stored in the CDR)
- Local policies expressed in code or in 3rd-party formats
See Consent Service for information on setting up the consent service.
Authorization and Consent
Security
Authentication Protocols Authorization and Consent Inbound Security Module Local Inbound Security Module LDAP Inbound Security Module Scripted Inbound Security Module SAML Inbound Security Module Trusted Client Mode Roles and Permissions Callback Scripts Anonymous Access Consent Service Consent Service: JavaScript API Consent Service: Java API Security Recipes Two Factor Authentication Password Hashing Algorithms JWT Signature Algorithms Troubleshooting Security