...
The are two possible combinations of authentication that the interoperability layer should provide to determine a users applications identity:
- HTTP basic authentication
- ATNAs Node Authentication (PKI)
Once identify has been established the IL core component should check if that user application has the authority to access the requested service.
The HIM should also provide a single-sign-on (SSO) facility to allow users of the HIE management application to have a single identity that they may used to access these applications. To do this the HIM should also act as an openid provider and provide functions to manage SSO users.
The two main workflows that we wish to enable for authentication and authorization are described in the following workflows:
Authentication
User 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 usersapplications.
| Code Block | ||
|---|---|---|
| ||
{
"userIDapplicationID": "Musha_OpenMRS",
"name": "OpenMRS Musha instance",
"roles": [ "OpenMRS_PoC", "PoC" ],
"password-hash": "",
"cert": ""
} |
When authentication is set to HTTP basic auth then connect middleware is setup to intercept the request as soon as it enters the HIM as shown above. This middleware will read user application details out of the MongoDB store to determine if the user application can be authenticated. If the user application is rejected an error is returned else the request is considered authenticated and is then passed onto the authorization step.
...
The OpenHIM only performs simple authorization based on the path that is being requested. It should be able to restrict access to certain paths to users applications with particular roles. The channel description shown in the router section below shows that each path has one or more allowed roles or user applications associated with it. The authorization component will check if the authenticated user application has the authority to access the current path. It authorized the request will be passed on, else, the request will be denied and a HTTP 401 message will be returned.
...
| Code Block | ||
|---|---|---|
| ||
{
"transactionId": "123",
"status": "Processing|Failed|Completed",
"userIdapplicationId": "Musha_OpenMRS",
"request": {
"path": "/api/test",
"headers": [
{ "header1": "value1" },
{ "header2": "value2" }
],
"requestParams": [
{ "param1": "value1" },
{ "param2": "value2" }
],
"body": "<HTTP body>",
"method": "POST",
"timestamp": "<ISO 8601>"
},
"response": {
"status": 201,
"body": "<HTTP body>",
"headers": [
{ "header1": "value1" },
{ "header2": "value2" }
],
"timestamp": "<ISO 8601>"
},
"routes": [
{
"name": "<route name>"
// Same structure as above
"request": { ... },
"response": { ... }
}
]
"orchestrations": [
{
"name": "<orchestration name>"
// Same structure as above
"request": { ... },
"response": { ... }
}
]
"properties": [ // optional meta data about a transaction
{ "prop1": "value1" },
{ "prop2": "value2" }
]
} |
...