feat(lpms-server): role based authentication with videre / REST-API

[mfw78]

Problem
To map out clearly how the role based authentication works in lpms-server when interacting with roles in videre.

Roles

The following maps the roles in lpms-server with their corresponding roles in videre:

• lpms-server: API -> videre: API
• lpms-server: BIDDER -> videre: BIDDER
• lpms-server: MANAGER -> videre: MANAGER
• lpms-server: STAFF -> videre: STAFF

WARNING: THE lpms-server MUST NEVER HAVE THE ADMIN OR FINANCE ROLE. THESE ARE INTENTIONALLY NOT INCLUDED

Key handling

On instance deployment four (4) private keys are randomly generated corresponding to api, bidder, manager, and staff. These SHOULD be stored somewhere securely. They are NOT ephemeral, and therefore must be remembered across instance restarts.

The REST API then provides an endpoint allowing the public addresses corresponding to these keys to be queried, eg: /ethAccounts/api responds with the public address of the API key.

WARNING: INTERNALLY GENERATED PRIVATE KEYS MUST NEVER BE SENT OVER AN API OR OUTSIDE OF THE INSTANCE.

On-Chain

The only keys that are used on-chain are manager and staff. Other keys that are generated are ONLY used for off-chain signing that occurs on messaging within videre, or when signing data that is uploaded to IPFS/Swarm.

REST Authentication

A simple authentication mechanism is used to secure REST API endpoints. These usernames / passwords are allocated to either the MANAGER role, or the STAFF role, with the difference being:

1. MANAGER may add users to the REST Authentication, and trigger restricted REST API endpoints such as a 'refund' endpoint.
2. STAFF may only access REST API endpoints that are deemed more 'routine', such as checkin, checkout etc.

WARNING: WHEN IMPLEMENTING REST API AUTHENTICATION, THE UNDERLYING COMMUNICATION MUST USE AN ENCRYPTED PROTOCOL SUCH AS HTTPS.

CAUTION: CONSIDERATION SHOULD BE GIVEN TO FUTURE DEPLOYMENTS OF lpms-web WITH RESPECT TO CORS POLICIES.