Difference between revisions of "Architecture"

Latest revision as of 13:41, 9 August 2017

Introduction

Security

Security between components will be managed via OAUTH2, as it has a very large support base and is common in many programming frameworks. Data-level access will be manage by the components themselves or indirectly by partitioning of data (restricting by the company associated with the user etc.). That said, we can be more specific in our requirements, define our terminology and identify particular use-cases:

• A user is associated with exactly one company.
• Client applications within Rabora, known as internal systems.
• Front-end applications controlled by Rabora, but executing in the browser (for example), known as internal front-end systems.
• Client applications running within customer environments, known as customer systems.
• Client applications running at 3rd parties, known as integrator systems.
• Client applications running on behalf of carriers, known as carrier systems.

From an OAUTH2 standpoint:

• Systems utilising Rabora APIs will make use of the refresh_token grants.
• Internal front-end systems will make use of a Central Authentication Server (CAS) and refresh_token and/or implicit grants.
• Only Rabora administrators can manage internal client credentials.
• Only customer administrators can grant access so that integrator systems can access their data.

Use cases

A customer makes use of the Rabora API to provide orders and ship parcels.

The client application is assigned credentials, held within the CAS, by an administrator of the customer's company, and makes use of the refresh_token grant.