Architecture

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, and identify particular use-cases:

• Client applications within Rabora, known as internal systems.
  • Not locked to any specific company.
• Front-end applications controlled by Rabora, but executing in the browser (for example), also known as internal systems.
  • Not locked to any specific company.
  • OAUTH2 tokens obtained from Single Sign On Centralised Authentication Server.
• Client applications running within customer environments, known as customer systems.
  • Clients locked to specific company.
• Client applications running at 3rd parties, known as integrator systems.
  • Clients associated with user accounts using grant authorisations, and managed by that user.