Difference between revisions of "Rabora OAUTH2"
(→Clients) |
(→Introduction) |
||
| (12 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
| + | ==Introduction== | ||
| + | |||
| + | This page describes the important aspects of how OAUTH2 is employed within the Rabora environments. The initial effort to define and introduce scopes is undertaken in {{jira|id=RABSEC-10}}. | ||
| + | |||
==Clients== | ==Clients== | ||
| Line 8: | Line 12: | ||
!Scope!!Purpose | !Scope!!Purpose | ||
|- | |- | ||
| − | |rabora: | + | |rabora:external||The client is accessible via a public interface (such as a UI application or public API). |
|- | |- | ||
|rabora:internal||The client runs within the Rabora infrastructure. | |rabora:internal||The client runs within the Rabora infrastructure. | ||
|} | |} | ||
| + | |||
| + | ===Customer clients=== | ||
| + | |||
| + | Clients running at a customer premises are associated with a '''companyId'''. There is a virtual user associated with the '''client_details''' account, and is named the same as the customer's application. | ||
| + | |||
| + | * Primary settings | ||
| + | ** ClientId (generated by the SSO server) | ||
| + | ** Secret (generated by the SSO server) | ||
| + | ** Application name | ||
| + | ** (CompanyId is fixed) | ||
| + | * Optional settings | ||
| + | ** Token refresh interval | ||
| + | |||
| + | ===3rd-party clients=== | ||
| + | |||
| + | Customers can allow 3rd parties access to their data. In this instance, the '''companyId''' is locked to that of the user account that granted the access. The '''authorization_code''' is the only grant available. Again, a virtual user account is associated with the 3rd party application. | ||
| + | |||
| + | * Primary settings | ||
| + | ** ClientId (generated by the SSO server) | ||
| + | ** Secret (generated by the SSO server) | ||
| + | ** Application name | ||
| + | ** (CompanyId is fixed) | ||
Latest revision as of 13:03, 15 August 2017
Introduction
This page describes the important aspects of how OAUTH2 is employed within the Rabora environments. The initial effort to define and introduce scopes is undertaken in RABSEC-10.
Clients
Rabora clients
Rabora clients are automatically approved by the OAUTH2 Authentication & Authorisation server, giving the Single Sign-On (SSO) capability across the whole Rabora domain. The following scopes are relevant to Rabora clients:
| Scope | Purpose |
|---|---|
| rabora:external | The client is accessible via a public interface (such as a UI application or public API). |
| rabora:internal | The client runs within the Rabora infrastructure. |
Customer clients
Clients running at a customer premises are associated with a companyId. There is a virtual user associated with the client_details account, and is named the same as the customer's application.
- Primary settings
- ClientId (generated by the SSO server)
- Secret (generated by the SSO server)
- Application name
- (CompanyId is fixed)
- Optional settings
- Token refresh interval
3rd-party clients
Customers can allow 3rd parties access to their data. In this instance, the companyId is locked to that of the user account that granted the access. The authorization_code is the only grant available. Again, a virtual user account is associated with the 3rd party application.
- Primary settings
- ClientId (generated by the SSO server)
- Secret (generated by the SSO server)
- Application name
- (CompanyId is fixed)
