• 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 Security Recipes
  • 15.16 Two Factor Authentication
  • 15.17 Troubleshooting Security
    • 15.1    Authentication Protocols   
       Table of Contents

    Security in Smile CDR

    15.0.1Security in Smile CDR

     

    This page provides a quick overview of the concepts involved in setting up a secure deployment of Smile CDR. It would be a good idea to read the whole thing before moving on to more specific implementation pages.

    Security in Smile CDR has several components that work together to provide overall security. These are shown in the diagram below.

    Security Overview

    15.0.2Inbound Security Module

     

    An Inbound Security module is used to validate credentials in a request and associate them with a user. In a typical configuration, a single Inbound Security module is created and used to authorize all requests that come in.

    15.0.3FHIR Listener Module

     

    FHIR Listener modules are typically configured to require some sort of authorization information in each incoming request.

    For example, a FHIR endpoint configured with HTTP Basic Authentication would expect an Authorization header in each request, containing a username and password. The system can be configured to make access control decisions to block or allow access to specific groups of resources and operations based on the authenticated user. The system can also be configured to allow access to specific resources and operations by anonymous users (i.e. requests with no Authorization header).

    FHIR endpoints can also be configured to look for an OpenID Connect (OAuth2) bearer token, and can make security decisions based on that authentication.

    15.0.4Admin Modules

     

    Both the JSON Admin API and the Web Admin Console require authentication, and an Inbound Security module is used to provide that authentication. For the JSON Admin API, the Inbound Security module is used to verify credentials that arrive with each request. For the Web Admin Console, the Inbound Security module is used to authenticate the user that signs into the console.

    15.0.5Auth Directory

     

    In order to authenticate users, Smile CDR needs to be able to communicate with some sort of user store where credentials are stored. By default Smile CDR comes set up to use a Local Inbound Security module, which stores user credentials in the Smile CDR administration database. This is a good option and it works well; however, if you are integrating into an existing environment with existing user stores (e.g. a hospital with a corporate Active Directory database), you might want to integrate with that database in order to provide single sign-on capabilities. This is accomplished through the use of different types of Inbound Security modules.

    15.0.6Audit Database

     

    By default, all actions are audited in Smile CDR's audit database. The audit database is a set of tables in Smile CDR's administrative schema that record actions, including what was done, who did it, when they did it, and where on the network they came from.

    15.0.7Outbound Security Modules

     

    Outbound security modules are used to provide security to external applications. Currently the only Outbound Security module is the SMART on FHIR OpenID Connect module. This module can be used to sign users into a SMART on FHIR application that is integrated into Smile CDR. Optionally, this module could be paired with an external Inbound Security module in order to provide SMART on FHIR authentication via an external directory, such as a corporate Active Directory.

  • 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 Security Recipes
  • 15.16 Two Factor Authentication
  • 15.17 Troubleshooting Security
    • 15.1    Authentication Protocols