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.
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.
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
FHIR endpoints can also be configured to look for an OpenID Connect (OAuth2) bearer token, and can make security decisions based on that authentication.
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.
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.
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.
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.