Git Product home page Git Product logo

openhim-core-js's Introduction

OpenHIM Core Component

Build Status Dependency Status devDependency Status codecov

The OpenHIM core component is responsible for providing a single entry-point into an HIE as well as providing the following key features:

  • Point of service client authentication and authorization
  • Persistence and audit logging of all messages that flow through the OpenHIM
  • Routing of messages to the correct service provider (be it an HIM orchestrator for further orchestration or the actual intended service provider)

To get started and to learn more about using the OpenHIM see the full documentation.

Some of the important information is repeated here, however, the above documentation is much more comprehensive.

See the development road-map for more details on what is to come!


Requirements

Currently supported versions of NodeJS LTS are

NodeJS (LTS) MongoDB
14.2x.x >= 3.6 || <= 4.2
15.x >= 3.6 || <= 4.2

Getting started with the OpenHIM-core

Docker Compose

  1. Ensure that you have Docker and Docker Compose installed.
  2. Navigate to the docker-compose.yml file found in the /infrastructure directory.
  3. Execute the Docker Compose file to pull the docker images and start the services in a detached mode:
docker-compose up -d
  1. Once the services have all started, you will be able to view the OpenHIM Console in your browser.

Developer guide

Clone the https://github.com/jembi/openhim-core-js.git repository.

Ensure you have the following installed:

  • Node.js v10(LTS) && != 10.15.1 || v12(LTS)
  • NPM
  • MongoDB (in Ubuntu run sudo apt install mongodb, in OSX using Homebrew, run brew update followed by brew install mongodb)

Navigate to the directory where the openhim-core-js source is located and run the following:

npm install

This will install all the required modules and then build the project files.

In order to run the OpenHIM core server, MongoDB must be installed and running. Please refer to the requirements table for accurate versions to use.

To run the server, execute:

npm start (this runs node lib/server.js behind the scenes)

The server will by default start in development mode using the mongodb database 'openhim-development'. To start the server in production mode use the following:

NODE_ENV=production npm start

This starts the server with production defaults, including the use of the production mongodb database called 'openhim'.

This project uses mocha as a unit testing framework with should.js for assertions and sinon.js for spies and mocks. The tests can be run using npm test.

Pro tips:

  • npm run lint - ensure the code is lint free, this is also run before an npm test
  • npm link - will symlink you local working directory to the globally installed openhim-core module. Use this so you can use the global openhim-core binary to run your current work in progress. Also, if you build any local changes the server will automatically restart.
  • npm test -- --grep <regex> - will only run tests with names matching the regex.
  • npm test -- --inspect - enabled the node debugger while running unit tests. Add debugger statements and use node debug localhost:5858 to connect to the debugger instance.
  • npm test -- --bail - exit on first test failure.

Creating CentOS RPM package

The build process for the RPM package is based off this blog. The reason for using vagrant instead of docker is so that we can test the RPM package by running it as a service using SystemCtl - similar to how it will likely be used in a production environment. SystemCtl is not available out the box in docker containers.

Refer to this blog for a more detailed description of a possible work-around. This is not recommended since it is a hack. This is where vagrant comes in since it sets up an isolated VM.

  1. Setup environment

    Navigate to the infrastructure folder: infrastructure/centos

    Provision VM and automatically build RPM package:

    vagrant up

    or without automatic provisioning (useful if you prefer manual control of the process):

    vagrant up --no-provision
  2. [Optional] The Vagrant file provisions the VM with the latest source code from master and attempts to compile the RPM package for you. However in the event an error occurs, or if you prefer to have manual control over the process, then you'll need to do the following:

    • Remote into the VM: vagrant ssh
    • Download or sync all source code into VM.
    • Ensure all dependencies are installed.
    npm i && npm i speculate
    • Run speculate to generate the SPEC files needed to build the RPM package.
    npm run spec
    • Ensure the directory with the source code is linked to the rpmbuild directory - the folder RPMBUILD will use.
    ln -s ~/openhim-core ~/rpmbuild
    • Build RPM package.
    rpmbuild -bb ~/rpmbuild/SPECS/openhim-core.spec
  3. Install & Test package

    sudo yum install -y ~/rpmbuild/RPMS/x86_64/openhim-core-{current_version}.x86_64.rpm
    sudo systemctl start openhim-core
    curl https://localhost:8080/heartbeat -k

    Note: In order for openhim-core to run successfully, you'll need to point it to a valid instance of Mongo or install it locally:

    sudo yum install mongodb-org
    sudo service mongod start
  4. How to check the logs?

    sudo systemctl status openhim-core
    sudo tail -f -n 100 /var/log/messages
  5. If everything checks out then extract the RPM package by leaving the VM.

    Install Vagrant scp plugin:

    vagrant plugin install vagrant-scp

    Then copy the file from the VM:

    vagrant scp default:/home/vagrant/rpmbuild/RPMS/x86_64/{filename}.rpm .

Contributing

You may view/add issues here: https://github.com/jembi/openhim-core-js/issues

To contribute code, please fork the repository and submit a pull request. The maintainers will review the code and merge it in if all is well.

Data Privacy Disclaimer

All users downloading and using OpenHIM should note the following:

  • All message data sent to the OpenHIM is retained indefinitely within the OpenHIM’s MongoDB database. By default, this data is stored indefinitely in line with the function of a middleware software with audit & transaction replay capabilities.
  • All message data is stored in OpenHIM's MongoDB and is only accessible or viewable by a) An authorized admin-level user or a user that has been explicitly allowed to do so or; b) An authorized system administrator staff member having access to the server itself.
  • Access to the message data stored in OpenHIM’s MongoDB database is controlled by the organization hosting OpenHIM. This organisation must know its responsibilities as a ‘Data Controller’ and potentially other roles, as defined in standard data privacy regulations, such as the General Data Protection Regulation (GDPR) and the South African Protection of Personal Information Act (POPIA). The organisation using OpenHIM is responsible for having the required policies in place to ensure compliance with the applicable laws and regulations in the country where the software is being operated.
  • All message data stored in OpenHIM's MongoDB may be purged at any time by direct commands to the MongoDB database or the use of the data retention feature of OpenHIM channels.
  • Basic data about OpenHIM users (name and email) is stored indefinately so that they may access the OpenHIM console. These users may be removed at any time if they are no longer needed.

openhim-core-js's People

Contributors

arran-standish avatar bausmeier avatar bluephone avatar bmartinos avatar bradsawadye avatar brett-onions avatar de-laz avatar debonair avatar dependabot[bot] avatar drizzentic avatar greenkeeperio-bot avatar hnnesv avatar ishmaelmakitla avatar itsmurumba avatar johanvanzyl avatar lindajembi avatar litlfred avatar marrouchi avatar mattyj007 avatar michaelloosen avatar napiergit avatar nour-borgi avatar nthfloor avatar psbrandt avatar rcrichton avatar rmrlangford avatar tmvumbi2 avatar trevorgowing avatar tumijacob avatar zooloo2014 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

openhim-core-js's Issues

In the message store middleware we should store the results of each route

When a incoming request is received it is sent out to 1 or more routes. Currently we only store the result from the primary route in the transaction metadata. We should also store the responses from other routes. In the transaction metadata, there is a 'routes' property that should contain the request and response information for these other routes.

A good way to implement this would be to store the responses in the koa context, then in the messageStore middleware store these to mongo.

Switch the client and channels model to key off IDs not names

The current implementation of the channel and applications about requires us to refer to then by the channelName and applicationID respectively. We should rather key of the _id properly that mongo gives us as we run into problems where we can't update these fields as they are used to fetch the object to update. Using IDs that never change like the _id would solve this.

This is related to #28

Update is by ChannelName, should it be by ID?

Because we are updating a channel by channelname, the channelname on the update json must match the channelname in the db. THis means we cannot update the channelname. Should we be able to update it?

Develop authentication functionality that supports HTTP basic-auth

This functionality requires Koa middleware so be developed that ensures that application are authenticated using basic auth when they make a request of the OpenHIM. If they are not, then the request should be denied.

The user should be able to choose if they want to enable basic auth (see #12) or the PKI functionality or both.

More details about how this should work can be found here

Allow batch transaction to be re-run

To do this, we should provide a new API endpoint that a list of transaction to re-run. We should also be able to see the results of the re-run transactions.

One way to do this is the expose an endpoint like /reruntasks

POST - a JSON object to this endpoint containing a list of transaction IDs to re-run.
GET - a list of past and current reruntasks
GET - /reruntasks/:taskID - return the details of a single task

The OpenHIM core should use the details in transaction.request property to reconstruct each request and resent it.

Develop the message persistence middleware to store a response

For this issue, the storeResponse method in the messageStore.coffee file need to be implemented. This method should lookup the transaction object that was stored for the corresponding request and updated this object to store all relevant information about the response as defined in transaction.json here: https://wiki.ohie.org/display/SUB/Design+of+the+Interoperability+Layer+core+using+Node.js

The transaction object should be updated in a mongodb database.

Develop an authentication mechanism for the REST API

Requirements:

  • A user should be able to log into the OpenHIM console.
  • When a user is logged in, the web console should be able to authenticate and communicate with the OpenHIM-core REST API (backend).
  • The console cannot be pre-configured with any secrets as it is an Angular app so everything can be visible client side, if would have to request these only once the user is authenticated and authorised.

Should we allow multiple channels to be matched for a single request?

Matching multiple channels causes problems when thinking about authorisation. Each channel can allow certain people to have access. If one matched channel allows the request but another matched channel denies the request then how should we proceed? Do we just fail with unauthorised or do we send requests on to only the authorised channels?

Duplicate key error when saving a transaction

I get the following error when trying to send to requests to the HIM in close succession:

/home/ryan/git/openhim-core-js/node_modules/mongodb/lib/mongodb/connection/base.js:242
        throw message;      
              ^
Error: E11000 duplicate key error index: openhim.transaction.$_id_  dup key: { : ObjectId('5322ff1b14070a662c094092') }
    at Object.toError (/home/ryan/git/openhim-core-js/node_modules/mongodb/lib/mongodb/utils.js:110:11)
    at /home/ryan/git/openhim-core-js/node_modules/mongodb/lib/mongodb/collection/core.js:212:24
    at Server.Base._callHandler (/home/ryan/git/openhim-core-js/node_modules/mongodb/lib/mongodb/connection/base.js:442:41)
    at /home/ryan/git/openhim-core-js/node_modules/mongodb/lib/mongodb/connection/server.js:485:18
    at MongoReply.parseBody (/home/ryan/git/openhim-core-js/node_modules/mongodb/lib/mongodb/responses/mongo_reply.js:68:5)
    at null.<anonymous> (/home/ryan/git/openhim-core-js/node_modules/mongodb/lib/mongodb/connection/server.js:443:20)
    at EventEmitter.emit (events.js:104:17)
    at null.<anonymous> (/home/ryan/git/openhim-core-js/node_modules/mongodb/lib/mongodb/connection/connection_pool.js:191:13)
    at EventEmitter.emit (events.js:107:17)
    at Socket.<anonymous> (/home/ryan/git/openhim-core-js/node_modules/mongodb/lib/mongodb/connection/connection.js:418:22)

Develop authentication functionality that supports mutual TLS

An authentication middleware must be developed that allows applications to be authenticated using mutual TLS (ie. client and server certificates).

The user should be able to choose if they want to enable basic auth (see #11) or the PKI functionality or both.

More details about how this should work can be found here

Restrict users to only seeing certain types of transactions

We should restrict which user can edit and view to various API resources. Here is how these could be restricted:

  • Channels: Only the user in the 'admin' group can view, add and edit channels.
  • Transactions: Users can only view or re-run transaction for the channels which they are allowed to view.
  • Client: Only the user in the 'admin' group can view, add and edit clients.
  • Users: Only the user in the 'admin' group can view, add and edit users.
  • Monitoring data: Users can only view monitoring data for the channels which they are allowed to view.

In order to enable this, we will need to add two properties to both the channels model:

  • txRerunable - an array of usernames or group names, with a special value of * to allow anyone
  • txViewable - an array of usernames or group names, with a special value of * to allow anyone

We will also need user to have a 'groups' property which contains an array of groups that they are a part of.

The 'admin' is a special group which designated that those user have access to anything.

Develop authorisation middleware

After an application is authenticated, authorisation middleware must be introduced that determines if they have the correct authority to make this request. This authority is determined by inspecting the path of the request and the channel's details of who is allowed to invoke that channel.

If an application is not authorised a 401 status should be returned else the request should carry on as usual.

More details about how this should work can be found here

Create an endpoint and stub module for the RESTful API

The OpenHIM needs to use a separate http endpoint for it REST API so that we can avoid collisions with http request that actually need to be routed. For this issue a new module should be developed that creates a new http server and provides the stub where the API can be configured and REST API functionality can be developed.

Path redirection for channels

Channels should have two extra options, path and pathTransform:

  • path should specify a target path for the channel, e.g. if path is /target, transactions should be routed to the path /target.
  • pathTransform should allow for a sed-like substitution of the path, e.g. if the transform is s/foo/bar and the request's endpoint is /endpoint/foo, transactions should be routed to /endpoint/bar.

The options are mutually exclusive.

See the original HIM issue: jembi/openhim-legacy#211

Add support for basic auth for routes

When a request is being routed to a specific route in a channel, the ability to forward that request with basic auth should be supported. The route config (in a channel object) should contain the basic auth username and password to use.

Authorisation error when testing against preprod

How to repeat:

From the openhim-core-js directory run:

curl -v --insecure --key test/resources/client-tls/key.pem --cert test/resources/client-tls/cert.pem https://openhim-preprod.jembi.org:5000/sample/api -H "JsonStub-User-Key: 0582582f-89b8-436e-aa76-ba5444fc219d" -H "JsonStub-Project-Key: 1a841ebc-405e-474e-a8fa-9c401c823ae6"

You should see the following error appear in the logs:

info: Storing request metadata for inbound transaction

/root/openhim-core-js/node_modules/mongodb/lib/mongodb/connection/base.js:242
        throw message;      
              ^
TypeError: Object PoC has no method 'filter'
    at /root/openhim-core-js/lib/middleware/authorisation.js:18:38
    at /root/openhim-core-js/lib/middleware/router.js:107:16
    at /root/openhim-core-js/node_modules/mongodb/lib/mongodb/cursor.js:162:16
    at commandHandler (/root/openhim-core-js/node_modules/mongodb/lib/mongodb/cursor.js:706:16)
    at /root/openhim-core-js/node_modules/mongodb/lib/mongodb/db.js:1806:9
    at Server.Base._callHandler (/root/openhim-core-js/node_modules/mongodb/lib/mongodb/connection/base.js:442:41)
    at /root/openhim-core-js/node_modules/mongodb/lib/mongodb/connection/server.js:485:18
    at MongoReply.parseBody (/root/openhim-core-js/node_modules/mongodb/lib/mongodb/responses/mongo_reply.js:68:5)
    at null.<anonymous> (/root/openhim-core-js/node_modules/mongodb/lib/mongodb/connection/server.js:443:20)
    at EventEmitter.emit (events.js:104:17)

Enable HTTPS access to the HIM via mutual TLS

The HIM should allow HTTPS access and it should authenticate this access by using mutual TLS (both client and server need to provide a cert). The client's cert is only considered valid if the HIM has this certificate added to its trusted list of certificates else any request that is make must be refused.

The client application certificates should be stored in mogodb along with details about that application. See #4

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.