REST API Usage Usage Other

RBAC(Role Based Access Control) Usage

The K2HR3 system provides ROLE-based access control to RESOURCE RBAC(Role Based Access Control).

USER needs to set ROLE, POLICY-RULE, RESOURCE, SERVICE in order to use the RBAC feature. These settings are described in K2HR3 Usage.

RBAC Overview

The access source to RESOURCE controlled as RBAC is managed by ROLE.
The access source HOST is registered as a member in ROLE.

Access control as RBAC is managed by POLICY-RULE.

+SERVICE is a feature that controls access to RESOURCE owner (OWNER) and user(MEMBER) RESOURCE.
SERVICE is data managed by the K2HR3 system used with the +SERVICE feature.

This section explains how to use the RBAC feature of the K2HR3 system.

Access to RESOURCE

There are two ways to access RESOURCE by the K2HR3 system.
They are access with token(TOKEN) specified and unspecified access. TOKEN also has TOKEN granted to USER and TOKEN granted to ROLE(HOST).

For information about accessing with TOKEN to the K2HR3 system, please also refer to REST API Usage.

Access RESOURCE without TOKEN

RESOURCE data can be acquired without TOKEN.
For TOKEN, please see REST API Usage.

RESOURCE can be accessed without TOKEN when accessing RESOURCE from the HOST of the ROLE member using the K2HR3 REST API.

Details

When performing access control, it is necessary to check the access authority for the access target.   Generally, TOKEN, IP address, cookie, etc. are used for confirmation of authority.   On the K2HR3 system, use the IP address(and Auxiliary Information(AUX)) to confirm the access authority, and authenticate and authorize it.  

The flow of this processing is shown below.  

  1. HOST attempts to access RESOURCE using the REST API
  2. K2HR3 system confirms ROLE of HOST
  3. Check the authority of access to RESOURCE of ROLE
  4. HOST is granted access to RESOURCE and gets contents

As mentioned above, in the case of ROLE member HOST which is permitted access to RESOURCE, HOST can access RESOURCE without specifying TOKEN.

K2HR3 Usage RBAC - No Token Access

Examples

As shown below, HOST of ROLE member can get RESOURCE using RESOURCE API.

GET http://<K2HR3 API server host[:port]/v1/resource/<RESOURCE YRN PATH>?role=<ROLE YRN PATH>&type=<TYPE>

The above URL arguments and others are explained below.

In this way, you can use RESOURCE API request without TOKEN and get RESOURCE.

Access RESOURCE with TOKEN

USER can also access by giving TOKEN to RESOURCE.
This method is almost the same as accessing RESOURCE without TOKEN, but judge the access source(ROLE) by TOKEN, not authentication/authorization by IP address.

The access method using TOKEN is equivalent to the general usage method of other RBAC systems.

For details on the REST API, please see RESOURCE API. _ This section only describes features of the K2HR3 system. _

K2HR3 Usage RBAC - Role Token Access

+SERVICE cooperation Usage(RESOURCE delivery)

This introduce one way to provide functions and information of OWNER using +SERVICE feature. In this method, MEMBER gets RESOURCE defined as SERVICE from the K2HR3 system before accessing OWNER’s system(which provides functions and information) and passes that RESOURCE data to the OWNER system.

The schematic flow of this method is shown in the following figure.

K2HR3 Usage RBAC - Two step SERVICE Access

Flow

The flow of the above figure is as follows.

OWNER side

OWNER provides functions or information of its own system.
In order to access this function or information, dedicated authentication/authorization(which is different from the authentication/authorization of RBAC provided by K2HR3 system) of OWNER’s system is required.

MEMBER side

MEMBER accesses OWNER’s system and uses functions or information.
In order to use this function or information, MEMBER needs dedicated authentication/authorization provided by OWNER as mentioned above.

Sequence

The flow until MEMBER can use OWNER’s functions or information is explained below.

Registering SERVICE

Each of OWNER and MEMBER sets up to use SERVICE.

OWNER sets the data of dedicated authentication/authorization of OWNER’s system to RESOURCE of SERVICE.
This RESOURCE can be either static or dynamic.
If dedicated authentication/authorization is a dedicated token(which is created/used by OWNER system), OWNER registers the VERIFY URL to RESOURCE as dynamic RESOURCE.
VERIFY URL(which is REST API provided by OWNER) creates a dedicated token corresponding to MEMBER to be output as RESOURCE.

MEMBER cooperates with SERVICE and registers HOST as an access source as a ROLE member cooperated with it.

(1) MEMBER gets RESOURCE from K2HR3 system

MEMBER gets the RESOURCE of SERVICE by accessing K2HR3 system(REST API can be used without TOKEN).
The RESOURCE that MEMBER gets is dedicated authentication/authorization set by OWNER.

(2) MEMBER accesses OWNER system

MEMBER accesses OWNER’s system with data of dedicated authentication/authorization that MEMBER got as RESOURCE.

What system can cooperate with this usage

In this way, the OWNER system using the +SERVICE feature and using dedicated authentication/authorization was able to cooperate with.
And MEMBER can access OWNER system without knowing contents of dedicated authentication/authorization data.

In other words, this method has the following advantages.

This usage of +SERVICE can loosely couple the side that provides the system to be shared with the side that uses it.
And both sides can manage management for coordinating the system to the K2HR3 system and can manage them independently.

+SERVICE cooperation Usage(Delegation of authentication)

This section explains another way of using +SERVICE feature.

MEMBER accesses the OWNER system to use the functions and information of the OWNER system.
At this time, MEMBER accesses only the OWNER system.
In the above-mentioned usage, MEMBER required SERVICE’s RESOURCE data beforehand.
However, the method described here does not require RESOURCE data.
MEMBER hands over its own ROLE name etc. to OWNER and the OWNER system acquires the RESOURCE data in SERVICE from the K2HR3 system on behalf of MEMBER and uses it.

K2HR3 Usage RBAC - One step SERVICE Access

Flow

The flow of the above figure is as follows.

OWNER side

OWNER provides functions or information of its own system.

MEMBER accesses the OWNER system without the necessary data to authorize MEMBER. MEMBER will pass only the name of ROLE of MEMBER etc. When OWNER system is accessed, OWNER needs to check whether MEMBER is TENANT permitted to SERVICE. In order to confirm this, OWNER sends MEMBER information(ROLE, Peer IP address etc) to the K2HR3 system and OWNER gets RESOURCE data of SERVICE set for MEMBER.

The RESOURCE data for this MEMBER is the data registered by OWNER itself, and OWNER can confirm the identity of MEMBER by checking this data.

In this way, as OWNER delegates authorization of MEMBER to the K2HR3 system, and MEMBER will only access the OWNER system.

MEMBER side

MEMBER only passes the ROLE name as URL arguments and accesses the OWNER system.

Sequence

The flow until MEMBER can use OWNER’s functions or information is explained below.

Registering SERVICE

Each of OWNER and MEMBER sets up to use SERVICE.

OWNER sets RESOURCE capable of identifying MEMBER to SERVICE.
This resource can be either static or dynamic.
Also, if you only want to indicate whether access is permitted to the OWNER system, you only need to set common data for all MEMBERs.
For example, you can just register “true”.
Whether access is authorized is the same as meaning whether it is HOST of MEMBER cooperated with SERVICE or not and this can be determined by whether OWNER can get RESOURCE of SERVICE from K2HR3 system on behalf of MEMBER .

MEMBER cooperates with SERVICE and registers HOST as an access source as a ROLE member working with SERVICE.

(1) MEMBER access OWNER system

MEMBER accesses OWNER’s system.
At this time, MEMBER passes together the information(ROLE etc) for confirming HOST as a parameter.
This information(ROLE etc) to pass is the same information as when accessing without the TOKEN to the REST API of the K2HR3 system.
It is also possible to pass ROLE TOKEN if the system of OWNER can be trusted.

(2) OWNER delegates authentication

The OWNER system delegates the passed information(ROLE etc) and HOST information(Peer IP address) to the K2HR3 REST API and checks whether HOST belongs to TENANT of MEMBER cooperated with SERVICE.
OWNER can receive RESOURCE set by OWNER from the K2HR3 REST API, if HOST belongs to TENANT of MEMBER with SERVICE cooperation.
If HOST is not authorized, OWNER will receive an error from the K2HR3 REST API.

After confirming the acquired RESOURCE(if necessary), the OWNER system performs its own processing and returns the result to HOST.

What system can cooperate with this usage

Using the +SERVICE feature, OWNER does not require dedicated authentication and authorization, and MEMBER can access only the OWNER system directly.
This method is that the OWNER system delegates MEMBER’s authentication to the K2HR3 system.
Both OWNER and MEMBER can cooperate with RESOURCE(OWNER system functions or information) without establishing a unique authentication and authorization system.

For details, this method has the following advantages.

And the biggest advantage is that OWNER does not need to disclose the MEMBER specific RESOURCE used internally to MEMBER.
By doing this, OWNER can arbitrarily change system logic and RESOURCE freely, keeping security high.

Both OWNER and MEMBER can simplify API processing, and can completely delegate authentication and authorization to the K2HR3 system. And USER only sets the authority which is unified in the K2HR3 system.

REST API Usage Usage Other