Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Authentication

User Application details for authentication are stored in the MongoDB database is the following format. Either a password or a certificate (in binary form) is stored in this structure depending on whether the user chooses to use PKI or HTTP basic auth to authenticate applications.

The OpenHIM application should allow new applications to be added and managed with the following details:

Code Block
titleapplication.json
{
	"applicationID": "Musha_OpenMRS",
	"domain": "him.jembi.org",
	"name": "OpenMRS Musha instance",
	"roles": [ "OpenMRS_PoC", "PoC" ],
	"password-hash": "",
	"cert": ""
}

Basic auth

When authentication is set to HTTP basic auth then connect Koa middleware is setup to intercept the request as soon as it enters the HIM as shown above. This middleware will read application details (username and password-hash) out of the MongoDB store to determine if the application can be authenticated. If the application is rejected an error is returned else the request is considered authenticated and is then passed onto the authorization step.

PKI - mutual TLS

When the authentication method is set to PKI then the node http server must be setup to use https and it must be set to trust only applications that have a certificate that it knows of (is stored in an applications details). The domain of an application (identified in its certificate) will be used to map a request received from an application to its details as stored by the OpenHIM (shown above).

To help perform the authentication the passport.js module will be use. This provides us with middleware for a number of different authentication schemes.  Passport.jsThere is also Koa middleware available for passport.

Authorization

The OpenHIM only performs simple authorization authorisation based on the path that is being requested. It should be able to restrict access to certain paths to applications with particular roles. Roles are identified in each applications details. The channel description shown in the router section below shows that each path has one or more allowed roles or applications associated with it. The authorization authorisation component will check if the authenticated application has the authority to access the current path. It If authorized the request will be passed on, else, the request will be denied and a HTTP 401 message will be returned.

...

  • transaction logs
  • transaction channels
  • usersapplication details

It should also allow for the following actions:

...