On this page:

13.6SMART on FHIR Outbound Security Module

 

The SMART Outbound Security module is a complete SMART on FHIR compliant Authorization Server. It is able to accept authorization requests from SMART Applications, grant access tokens on behalf of users, and manage these Applications.

13.6.1Setting Up This Module

 

Setting up this module requires several key configuration items.

Username/Password Authentication

This module uses an Inbound Security module such as the Local Inbound Security Module or the LDAP Inbound Security Module in order to actually validate user credentials. This module is specified as a dependency in the SMART on FHIR Outbound Security module configuration.

JSON Web KeySet (JWKS) for Signing Tokens

In order to generate OpenID Connect Access Tokens, this module requires a JSON Web Key Set (JWKS). This keyset is used to sign the tokens that are generated so that Resource Servers may verify and ultimately trust that they are legitimate.

Note that anyone who is in possession of the key used here is able to generate access tokens. For this reason it is very important that the key be safely stored.

There are a number of tools that can be used to generate JWKS files. One popular option is the MKJWK tool maintained by the MIT Kerberos and Internet Trust. The steps below show how to create a JWKS file using the online version of their tool; however, for increased security you may wish to download a copy and use it locally:

  • Navigate to https://mkjwk.org/
  • Select the RSA tab with a key size of 2048 (this is the default, which should be sufficient for most purposes)
  • Select a Key Use of Signing
  • Select an algorithm (the default of RS256 should be sufficient)
  • Enter a meaningful key ID ()e.g. my-openid-token-signature)
  • Click "Generate New Key"

Once a key is generated, copy its value from the "Keypair set" textbox and set it for use:

  • It may be stored in a file in the Smile CDR classes directory. In this case, the openid.signing.jwks_file (Signing JWKS (File)) property should be set to classpath://[filename].
  • The raw JWKS JSON document may be placed directly in the openid.signing.jwks_text (Signing JWKS (Text)) property.

Note that a JWKS file will have contents similar to the following:

{
  "keys": [
    {
      "kty": "RSA",
      "d": "cSYq2di [trimmed]",
      "e": "AQAB",
      "use": "sig",
      "kid": "test",
      "alg": "RS512",
      "n": "mVuJygm [trimmed]"
    }
  ]
}

Issuer URL

The security_out_smart.issuer.url (Issuer URL) property should be set to the outward facing URL at which this module will be accessible.

For example, if Smile CDR is deployed on a server named "myserver" and this module is configured to use port 9200 then this property might be set to https://myserver:9200.

13.6.2Terms of Service

 

When the terms-of-service feature is active, the login flow will include a separate page to present Terms of Service for the user to accept after login, but before scopes are authorized. The Terms of Service feature is activated by configuring the version string. Once accepted, the user will not be asked again on subsequent logins for that SMART client application until the version string is changed. The system records these user agreement actions per-client with a timestamp. They are also recorded in the audit log. A user's active Terms of Service agreements are revoked along with the access token on the Revocation Page.

The default terms of service page only includes sample text and is not appropriate for production use. Production usage should configure a custom skin to present the desired text. When the TOS text changes, the configured version string should be changed as well to prompt users to re-agree.

13.6.3Plain-language Developer Attestation

 

OIDC clients managed by App Management Tools will offer the plain-language version of the developer attestation on the approval page.

13.6.4Client Credentials Grant

 

When using the Client Credentials Grant, the client will be authenticated and authorized without any user being involved.

This grant type may be used to authorize FHIR operations and other Smile CDR functions as well.

Note that when using this grant type, clients will automatically be granted any scopes listed in the Scopes sectiopn of the client definition. These scopes will be combined with the permissions granted directly to the client in order to determine which operations the client should be permitted to perform.

For example, if the client is given the ROLE_FHIR_CLIENT_SUPERUSER permission and the patient/*.read scope, the client will be permitted to perform read operations but not write operations.

SMART Backend Services

The SMART Backend Services Authorization Guide describes a mechanism for using a cryptographically signed JWT as the credential for an authenticating client, instead of a client secret. See System Flow: Client Credentials with JWT Credential for a description of how this flow works.

For this flow to work, an OIDC Client Definition must be created in Smile CDR, with the Public JWKS Keystore (i.e. a copy of the keystore that does not contain private keys) included in the appropriate field.

13.6.5Cross-Organization Data Access Profile Grant

 

The SMART Cross-Organization Data Access Profile (CODAP) is a security specification that allows third-party systems such as EHRs and remote systems to authenticate a user implicitly, meaning that their identity and permission is asserted and trusted by the local authorization server.

This flow would typically be used when a local Smile CDR instance is providing access to clinical data, and you wish to allow users using systems at other organizations to make direct data access (i.e. FHIR API) requests without the need for these users to have an account already created in the local Smile CDR instance.

See CODAP Authorization Flow for a description of how this flow works.

Authorization Script

When performing a CODAP authorization flow, an Authorization script must be supplied to the module configuration. This authorization script is responsible for examining the supplied Authentication and Authorization tokens, and for determining the appropriate user permissions that should be granted. This permission process is critical to the implementation of the CODAP process: The CODAP specification supplies a mechanism for accepting tokens and the format that these tokens should take, but it does not spell out how an implementor might use these tokens to decide what the user should be allowed to do. This is always going to be implementation specific, which is why a script is used.

The authorization script for CODAP uses the function authenticate(...).

13.6.6SMART Callback Scripts

 

If needed, a callback script may be invoked during the authorization process.

Function Context for Use When Called Location
onAuthenticateSuccess(..)
Documentation
Federated OAuth2/OIDC Mode Only Called immediately after a token has been issued by the federated provider but before a local (to Smile CDR) user and session has been created. Federation Auth Script option in the OIDC Server Definition.
authenticate(..)
Documentation
CODAP Mode Only Called immediately after a token has been received from the CODAP token issuer. CODAP Authorization Script setting on SMART Outbound Security module.
onSmartLoginPreContextSelection(..)
Documentation
Any Interactive Flow Called immediately after the user has authenticated in order to determine whether a session context needs to be selected by the user, and to supply the options that will be presented to the user. Post-Authorize Script setting on SMART Outbound Security module.
onTokenGenerating(..)
Documentation
Any Called after authentication has succeeded and before a token is issued. Post-Authorize Script setting on SMART Outbound Security module.
onPostAuthorize(..)
Documentation
Any Called after a token has been issued and stored but before it is returned to the client. Post-Authorize Script setting on SMART Outbound Security module.

13.6.7User Self Registration

 
This feature has been added as a preview in Smile CDR 2021.05.R01. Additional functionality is planned. Please let us know if you have specific requirements you would like us to include.

If configured to do so, users can be permitted to self-register. In this flow, a user fills out a web form, and an account is created for them.

This flow requires an Inbound Security module with support for supplying the User Self Registration Provider module dependency. Currently, only the Local Inbound Security module supports this. See Self Registration for information on how to enable this feature on the Local Inbound Security module.

Enabling Self Registration

To enable user self registration:

  • Enable and configure self registration on the Inbound Security module that is supplying authentication services to the SMART Outbound Security module. This step determines the permissions that are granted to newly created users.

  • Set a User Self Registration Provider module dependency from the SMART Outbound Security module to the Inbound Security module providing registration services.

  • You may also wish to skin the registration pages to customize the UI that will be seen by users.