Security Architecture

Authentication Architecture

The figure below illustrates how a remote client can obtain a token from a federated security token service (STS) representing an IPrincipal and pass it to the SanteDB HDS. The creation of a local IPrincipal is controlled by a local IIdentityProviderService implementation. It is imperative that the ACS generate a token format which is suitable for the HDS messaging interface to consume (i.e. the configurations match), otherwise the HDS will have no mechanism for verifying tokens.

Any ACS service can be used with SanteDB, however it is recommended that the ACS being used support the OAuth token service’s password grant and provide client/device authentication via TLS and/or HTTP basic auth.

Principals and Identities

When a authentication request is made against the ACS, depending on the type of authentication request (see OpenID Connect) the ACS will call the identity providers to authenticate the identity information provided. The identity providers called are one of:

• Application Identity Provider - Authenticates a single piece of software to establish an ApplicationIdentity which identifies the scope of grants permitted to the application identity.

• Device Identity Provider - Authenticates the physical device (computer, server, phone, etc.) using either:

  • Node Based Authentication -> Like an X509 Client Certificate , or

  • Shared Secret Authentication -> Such as those generated by the secret generator (typically a signed, random 128 bit key)

• Identity Provider - Which authenticates the human user which is attempting to establish an interactive session with the server.

The three identities (which are standalone principals in their own right) is then passed to the session provider service which establishes a principal as a combination of the three identities. The session principal contains:

• The final list of grants (policies) that the session is permitted to access

• The purpose of use, and elevation data (if applicable)

• The expiration, establishment time

Depending on the configuration of the iCDR or dCDR the session identity is serialized as either a JSON Web Token (http://jwt.io) or a simple web token which consists of the session identifier and a digital signature (used to validate the session id is not tampered with or guessed).

Interactive Sessions

An interactive session is established when a user enters their username, password and MFA secret. An interactive session will have three identities within the principal:

• User Identity representing the authenticated user account

• Application Identity representing the authenticated secure client the user used to obtain the session

• Device Identity representing the authenticated secure node from which the user authenticated

Non-Interactive Sessions

A non-interactive session is established when a device or application authenticates without the intervention of a user. Non-interactive session may carry either an Application Identity and a Device Identity or simply an Application Identity.

Credential Storage

Secrets for all objects in the SanteDB iCDR and dCDR (applications, devices, and users) are peppered.

A pepper is a secret value added to a password before hashing. It can be considered a second salt — another input to change the hash outcome completely. Yet, unlike a salt, it’s not stored in the database along with the hashes.

Whenever you generate a secret (like creating a device, resetting your password, etc.) in SanteDB the authentication architecture will grab a random series of password pepper characters and will add it to your secret, then hash it using the configured hasher, and store the result.

When you authenticate in SanteDB, all possible combinations of pepper are added to your entered credential and hashed, the SanteDB server then compares the peppered hashes with the stored hash to verify your login credentials.

Additionally, your password is re-peppered and re-hashed. This means that the password hashes in SanteDB's security tables change with each authentication.

Policy / Access Control Architecture

The enforcement of privacy and policies is handled through a series of services within the SanteDB solution. From a high level, three different types of services are involved:

• Policy Information Provider (PIP) - IPolicyInformationService – Is responsible for storing information related to the policies. The information point is responsible for maintaining a list of IPolicy objects which contain the name, oid, handler (C# class which is executed upon policy decision), and elevation control.

• Policy Decision Provider (PDP) - IPolicyDecisionService – Is responsible for making a decision related to a policy (or series of policies) for a given securable. The decision outcome is one of the following options:

  • Deny – The principal has no authorization to access the requested securable or policy.

  • Elevate – The principal can access the securable or policy however they require additional authentication (such as 2nd level password, TFA, etc.)

  • Grant – The principal is granted access to the specified securable or policy.

• Policy Enforcement Provider (PEP) - IPolicyEnforcementService – Is responsible for listening to events from the SanteDB system and leveraging the decision and information points to enforce the policy decision. This implementation can vary between jurisdictions however by default involves either the masking (i.e. there is something here you can’t see), redaction (i.e. removal of information), or partial disclosure of records.

The process for enforcement is illustrated below.

Most-Restrictive Policy Enforcement

SanteDB’s default policy decision service provider operates on a basis of most-restrictive with default DENY. In this evaluation scheme policy decisions are created as follows:

• If the principal has no data associated with the policy, the result of the decision is DENY,

• If the principal has one rule associated with the policy via role, device, or application then the result of the decision is the rule’s configuration,

• If the principal has multiple rule instances configured via role, device or application then the result of the decision is the most restrictive option.

For example, if user jsmith is a member of USERS, CLINICAL and is accessing SanteDB from application ReaderApp.

Policy	From USERS	From CLINICAL	From ReaderApp	Effective Set
Access Administrative Function				DENY
Change Password				DENY
Create Role				DENY
Alter Role				DENY
Create Identity				DENY
Login	GRANT		GRANT	GRANT
Unrestricted Clinical Data		GRANT		GRANT
Query Clinical Data		GRANT (implied)		GRANT (implied)
Write Clinical Data		GRANT (implied)	DENY	DENY
Delete Clinical Data		GRANT (implied)	DENY	DENY
Read Clinical Data		GRANT (implied)		GRANT (implied)
Override Disclosure		GRANT	DENY	DENY