15.1    Authentication Protocols
  • Security
  • 15.0 Security in Smile CDR
  • 15.1 Authentication Protocols
  • 15.2 Authorization and Consent
  • 15.3 Inbound Security Module
  • 15.4 Local Inbound Security Module
  • 15.5 LDAP Inbound Security Module
  • 15.6 Scripted Inbound Security Module
  • 15.7 SAML Inbound Security Module
  • 15.8 Trusted Client Mode
  • 15.9 Roles and Permissions
  • 15.10 Callback Scripts
  • 15.11 Anonymous Access
  • 15.12 Consent Service
  • 15.13 Consent Service: JavaScript API
  • 15.14 Consent Service: Java API
  • 15.15 Consent Module: Overview
  • 15.16 Consent Module: Examples
  • 15.17 Security Recipes
  • 15.18 Two Factor Authentication
  • 15.19 Troubleshooting Security
    • 15.3    Inbound Security Module   
       Table of Contents

    Authorization and Consent

    15.2.1Authorization 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.

    15.2.2Authorization Service

     

    The following diagram shows the primary purpose of the Authorization Service.

    Authorization Svc

    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:

    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 Unauthorized response.

    15.2.3Consent Service

     

    The following diagram shows the primary purpose of the Consent Service.

    Consent Svc

    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.

       15.1    Authentication Protocols
  • Security
  • 15.0 Security in Smile CDR
  • 15.1 Authentication Protocols
  • 15.2 Authorization and Consent
  • 15.3 Inbound Security Module
  • 15.4 Local Inbound Security Module
  • 15.5 LDAP Inbound Security Module
  • 15.6 Scripted Inbound Security Module
  • 15.7 SAML Inbound Security Module
  • 15.8 Trusted Client Mode
  • 15.9 Roles and Permissions
  • 15.10 Callback Scripts
  • 15.11 Anonymous Access
  • 15.12 Consent Service
  • 15.13 Consent Service: JavaScript API
  • 15.14 Consent Service: Java API
  • 15.15 Consent Module: Overview
  • 15.16 Consent Module: Examples
  • 15.17 Security Recipes
  • 15.18 Two Factor Authentication
  • 15.19 Troubleshooting Security
    • 15.3    Inbound Security Module