Security Tab

The Security tab provides options to secure the web services that are on the DINGO device.

The DINGO-Stack implements OAuth2 functions to protect its web services. The DINGO-Stack has an internal authorization server for generating access tokens and functions to validate access tokens.

OAuth2 is an authorization framework that enables applications, like the DINGO-Manager, to obtain limited access to HTTP services, like the web services in the DINGO-Stack.

OAuth defines four roles:

  1. Is in this case the user of the DINGO-Manager. He will be able to assign user name and passwords. OAuth definition...ClosedAn entity capable of granting access to a protected resource. When the resource owner is a person, it is referred to as an end-user.

  2. Is in this case the DINGO-Stack. OAuth definition...ClosedThe server hosting the protected resources, capable of accepting and responding to protected resource requests using access tokens.

  3. Is in this case the DINGO-Manager. OAuth definition...ClosedAn application making protected resource requests on behalf of the resource owner and with its authorization. The term "client" does not imply any particular implementation characteristics (e.g., whether the application executes on a server, a desktop, or other devices).

  4. Is in this case the internal authorization server inside the DINGO-Stack or an external server. OAuth definition...ClosedThe server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization.

The interaction between the four roles can be described in this abstract OAuth 2 flow illustration:

  1. The client requests authorization from the resource owner. The authorization request can be made directly to the resource owner (as shown), or preferably indirectly via the authorization server as an intermediary.
  2. The client receives an authorization grant, which is a credential representing the resource owner's authorization, expressed using one of four grant types defined by the OAuth 2 specification or using an extension grant type. The authorization grant type depends on the method used by the client to request authorization and the types supported by the authorization server.
  3. The client requests an access token by authenticating with the authorization server and presenting the authorization grant.
  4. The authorization server authenticates the client and validates the authorization grant, and if valid, issues an access token.
  5. The client requests the protected resource from the resource server and authenticates by presenting the access token.
  6. The resource server validates the access token, and if valid, serves the request.

The grant types implemented by the DINGO-Stack and its internal authorization server are:

The resource owner password credentials (i.e., username and password) can be used directly as an authorization grant to obtain an access token. The credentials are used when there is a high degree of trust between the resource owner (the user of the DINGO-Manager) and the client (the DINGO-Manager). The resource owner credentials are used for a single request and are exchanged for an access token.

The flow can be illustrated like this:

  1. The user of the DINGO-Manager (resource owner) provides the DINGO-Manager (client) with its username and password.
  2. The DINGO-Manager (client) requests an access token from the DINGO-Stack´s internal authorization server token endpoint by including the credentials received from the user of the DINGO-Manager. When making the request, the DINGO-Manager authenticates with the internal authorization server.
  3. The internal authorization server authenticates the DINGO-Manager and validates the users credentials, and if valid, issues an access token.
  4. The DINGO-Manager requests the protected resources from the DINGO-Stack and authenticates by presenting the access token.
  5. The DINGO-Stack validates the access token, and if valid, serves the request.

Client credentials are used as an authorization grant typically when the client is acting on its own behalf (the client is also the resource owner). The client credentials grant type MUST only be used by confidential clients.

An abstract flow can be illustrated like this:

  1. The client authenticates with the authorization server and requests an access token from the token endpoint.
  2. The authorization server authenticates the client, and if valid, issues an access token.
  3. The client requests the protected resource from the resource server and authenticates by presenting the access token.
  4. The resource server validates the access token, and if valid, serves the request.

The DINGO-Manager (client) only uses the Resource Owner Password Credentials grant when interacting with the DINGO-Stack (resource server).

The DINGO-Manager gives the user the possibility to configure the DINGO-Stack´s internal authorization server and other security management.