On this page:

7.0Security 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

7.0.1Inbound 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.

7.0.2FHIR 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.

7.0.3Admin 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.

7.0.4Auth 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.

7.0.5Audit 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.

7.0.6Outbound 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.