...
The are two possible combinations of authentication that the interoperability layer should provide to determine a applications client's identity:
- HTTP basic authentication
- ATNAs Node Authentication (PKI)
Once identify has been established the IL core component should check if that application client has the authority to access the requested service.
...
Authentication
Application Client 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 applicationsclients.
The OpenHIM application should allow new applications clients to be added and managed with the following details:
| Code Block | ||
|---|---|---|
| ||
{
"applicationIDclientID": "Musha_OpenMRS",
"domain": "him.jembi.org",
"name": "OpenMRS Musha instance",
"roles": [ "OpenMRS_PoC", "PoC" ],
"passwordHash": "",
"cert": ""
} |
...
When authentication is set to HTTP basic auth then Koa middleware is setup to intercept the request as soon as it enters the HIM as shown above. This middleware will read application details client details (username and password-hash) out of the MongoDB store to determine if the application client can be authenticated. If the application client is rejected an error is returned else the request is considered authenticated and is then passed onto the authorization step.
...
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 clients that have a certificate that it knows of (is stored in an applications a client's details). The domain of an application a client (identified in its certificate) will be used to map a request received from an application a client to its details as stored by the OpenHIM (shown above).
...
The OpenHIM only performs simple authorisation based on the path that is being requested. It should be able to restrict access to certain paths to applications clients with particular roles. Roles are identified in each applications client's details. The channel description shown in the router section below shows that each path has one or more allowed roles or applications clients associated with it. The authorisation component will check if the authenticated application client has the authority to access the current path. If authorized the request will be passed on, else, the request will be denied and a HTTP 401 message will be returned.
...
| Code Block | ||
|---|---|---|
| ||
{
"_id": "123",
"status": "Processing|Failed|Completed",
"applicationIdclientID": "Musha_OpenMRS",
"request": {
"path": "/api/test",
"headers": {
"header1": "value1",
"header2": "value2"
},
"querystring": "param1=value1¶m2=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"
}
} |
...
- transaction logs
- transaction channels
- application client details
It should also allow for the following actions:
...