REST API Usage Usage Other

RBACRole Based Access Control)の使い方

K2HR3システムを使うことで、リソース(RESOURCE)へのロール(ROLE)ベースのアクセス制御 RBACRole Based Access Control)ができます。

K2HR3システムを使う前に、ロール(ROLE)、ポリシー/ルール(POLICY)、リソース(RESOURCE)、サービス(SERVICE)を設定している必要があります。
これらの設定方法については、K2HR3システムの使い方を参照してください。

概要

K2HR3システムは、リソース(RESOURCE)に対するアクセスをRBACRole Based Access Control)として提供します。
RBACとしてのアクセス元は、ロール(ROLE)で管理され、個々のアクセスはロール(ROLE)に登録されているメンバーであるホスト(HOST)です。
RBACとしての制御は、ポリシー/ルール(POLICY)で管理し、実行されます。

RBACとして動作するためのこれらの設定をリソース(RESOURCE)の提供側と利用側で簡単な管理ができるようにするための機能が、+サービス(+SERVICE)機能です。
サービス(SERVICE)は、+サービス(+SERVICE)機能を利用するために設定するデータです。

このRBACの使い方では、K2HR3システムのRBAC機能を使うための方法を説明します。

リソース(RESOURCE)アクセス

K2HR3システムのリソース(RESOURCE)へのアクセス方法は、トークン(TOKEN)無し/トークン(TOKEN)有りの方法があります。
またトークン(TOKEN)は、ユーザ(USER)単位とロール(ROLE)単位で発行されたトークン(TOKEN)があります。
トークン(TOKEN)によるK2HR3システムへのアクセス方法の詳細については、K2HR3 REST APIも参照してください。

トークン(TOKEN)無しでリソース(RESOURCE)へアクセス

トークン(TOKEN)無しで、リソース(RESOURCE)のデータを取得することができます。
トークン(TOKEN)については、K2HR3 REST APIを参照してください。

ロール(ROLE)に登録されているホスト(HOST)からK2HR3のREST APIを利用して、リソース(RESOURCE)を取得する場合、トークン(TOKEN)無しでリソース(RESOURCE)を取得することができます。

詳細

通常、アクセス制御を行う場合、トークン(TOKEN)やIPアドレス、Cookieなどを使い、アクセス権限があるか確認します。
K2HR3システムでは、IPアドレスと付加情報により、アクセス権限の確認と認証・認可ができます。

この処理の流れを以下に示します。

  1. ホスト(HOST)がREST APIを使いリソース(RESOURCE)をリクエスト
  2. K2HR3システムがホスト(HOST)のロール(ROLE)を確認
  3. ロール(ROLE)のリソース(RESOURCE)アクセスの権限を確認
  4. ホスト(HOST)にリソース(RESOURCE)を返信

上記のように、予め設定されているロール(ROLE)のメンバーであるホスト(HOST)であれば、トークン(TOKEN)なしでリソース(RESOURCE)へのアクセスが可能です。

K2HR3 Usage RBAC - No Token Access

以下のようにRESOURCE APIを使い、予めロール(ROLE)に登録されているホスト(HOST)からリソース(RESOURCE)を取得します。

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

上記のパラメータ他を説明します。

このように、REST APIのリクエストにはトークン(TOKEN)を指定せず、リソース(RESOURCE)を取得することができます。

トークン(TOKEN)有りでリソース(RESOURCE)へアクセス

トークン(TOKEN)有りで、リソース(RESOURCE)のデータを取得もできます。
トークン(TOKEN)無しでリソース(RESOURCE)にアクセスする場合とほぼ同じですが、トークン(TOKEN)を指定し、IPアドレスによる認証・認可ではなく、トークン(TOKEN)によるロール(ROLE)の判定を行う違いがあります。
このアクセス方法は、一般的なRBACシステムと同等です。

詳しくは、RESOURCE APIなどの説明を参照してください。
ここではK2HR3システムの特徴としての説明に限定します。

K2HR3 Usage RBAC - Role Token Access

+サービス(+SERVICE)機能による連携(1)

K2HR3システムの+サービス(+SERVICE)機能を利用したサービス(SERVICE)の提供方法の1つを説明します。
これは、以下の図のようなサービス(SERVICE)の所有側(OWNER)のシステムが専用の認証・認可(K2HR3のRBACとは別)を持つケースです。

K2HR3 Usage RBAC - Two step SERVICE Access

フロー

上図のフローは以下のようになっています。

サービス(SERVICE)の所有側(OWNER)

サービス(SERVICE)の所有側(OWNER)が機能・情報を提供しています。
この機能・情報にアクセスするには、所有側(OWNER)のシステムの専用の認証・認可(K2HR3のRBACとは別)が必要です。

サービス(SERVICE)の利用側(MEMBER)

サービス(SERVICE)の利用側(MEMBER)は、所有側(OWNER)のシステムにアクセスし、機能・情報を利用します。
この機能・情報を利用するには、上述の専用の認証・認可が必要です。

シーケンス

サービス(SERVICE)の利用側(MEMBER)が、所有側(OWNER)の機能・情報を利用できるまでの流れを示します。

K2HR3システムへの設定

所有側(OWNER)と利用側(MEMBER)は、それぞれでサービス(SERVICE)の利用のための設定をします。

所有側(OWNER)の設定では、リソース(RESOURCE)に所有側(OWNER)のシステムの専用の認証・認可の情報を設定します。
リソース(RESOURCE)は静的・動的のいずれでも可能です。
専用の認証・認可が専用のトークンなどである場合は、動的なリソース(RESOURCE)を選択し、VERIFY URLにより利用側(MEMBER)に応じたトークンをリソース(RESOURCE)に設定できるようにするとよいでしょう。

利用側(MEMBER)は、サービス(SERVICE)の連携を行い、アクセス元となるホスト(HOST)を連携させたロール(ROLE)に登録しておきます。

アクセス(1)

利用側(MEMBER)は、K2HR3システムにアクセスし(トークン(TOKEN)無しでREST APIを利用する)、サービス(SERVICE)連携したリソース(RESOURCE)を取得します。
ここで取得できるリソース(RESOURCE)は、専用の認証・認可のための情報そのものです。

アクセス(2)

利用側(MEMBER)は、アクセス(1)で取得した専用の認証・認可のための情報を使って、所有側(OWNER)のシステムにアクセスできます。

何が可能となったのか

サービス(SERVICE)を利用して、専用の認証・認可を持つ所有側(OWNER)のシステムに対して、利用側(MEMBER)は、専用の認証・認可の情報の中身を知らないままアクセスが可能となりました。
つまり、以下のメリットがあります。

システムを提供する側、利用する側ともに疎結合できており、その結合方法を知る必要がありません。
連携させるための管理は、K2HR3システム上で双方が分離して設定・管理することができます。

+サービス(+SERVICE)機能による連携(2)

K2HR3システムの+サービス(+SERVICE)機能を利用したサービス(SERVICE)のもう一つの提供方法を説明します。
これは、以下の図のようなサービス(SERVICE)の所有側(OWNER)のシステムが認証・認可をK2HR3システムに委譲するケースです。

K2HR3 Usage RBAC - One step SERVICE Access

構成

上図の構成は以下のようになっています。

サービス(SERVICE)の所有側(OWNER)

サービス(SERVICE)の所有側(OWNER)が機能・情報を提供しています。
この機能・情報にアクセスする際、専用の認証・認可は不要であり、その代わりK2HR3システムに利用側(MEMBER)のロール(ROLE)を確認するための情報を受け取ります。

サービス(SERVICE)の利用側(MEMBER)

サービス(SERVICE)の利用側(MEMBER)は、所有側(OWNER)のシステムにアクセスし、機能・情報を利用します。

シーケンス

サービス(SERVICE)の利用側(MEMBER)が、所有側(OWNER)の機能・情報を利用できるまでの流れを示します。

K2HR3システムへの設定

所有側(OWNER)と利用側(MEMBER)は、それぞれでサービス(SERVICE)の利用のための設定をします。

所有側(OWNER)の設定では、リソース(RESOURCE)に所有側(OWNER)のシステムで確認できる情報(フラグでも可)を設定しておきます。
リソース(RESOURCE)は静的で可能です。
この確認できる情報は、サービス(SERVICE)連携の許可がなされているときに取り出せる値というだけです。
この値が取り出せる意味は、アクセスが認可されたということになります。

利用側(MEMBER)は、サービス(SERVICE)の連携を行い、アクセス元となるホスト(HOST)を連携させたロール(ROLE)に登録しておきます。

アクセス(1)

利用側(MEMBER)は、直接所有側(OWNER)のシステムにアクセスします。
このとき、利用側(MEMBER)のホスト(HOST)情報を一緒にパラメータとして渡します。
この渡す情報は、REST APIにトークン(TOKEN)なしでアクセスする情報と同じです。
所有側(OWNER)のシステムが信頼できるならトークン(TOKEN)を渡すことも可能ではあります。

アクセス(2)

所有側(OWNER)は、アクセス(1)で受け取った利用側(MEMBER)のホスト(HOST)情報とそのIPアドレスなどをK2HR3 REST APIに渡し、利用側(MEMBER)が連携したリソース(RESOURCE)を取得します。
リソース(RESOURCE)は、所有側(OWNER)が設定した値そのものです。
利用側(MEMBER)のホスト(HOST)が正しいロール(ROLE)メンバーであれば、リソース(RESOURCE)の取得が成功します。

リソース(RESOURCE)取得の成功を確認後、所有側(OWNER)のシステムは、自身の処理を行い機能・情報を利用側(MEMBER)に返します。

何が可能となったのか

サービス(SERVICE)を利用して、所有側(OWNER)は専用の認証・認可を必要とせず、利用側(MEMBER)はK2HR3システムの必要とするホスト(HOST)情報を渡し、1度だけのアクセスで、所有側(OWNER)システムが利用可能となりました。

つまり、以下のメリットがあります。

そして、最大のメリットは 所有側(OWNER)が内部で使う利用側(MEMBER)固有のリソース(RESOURCE)を、利用側(MEMBER)に見せる必要がない ことです。
これにより、所有側(OWNER)は任意のタイミングで自由にロジック・リソース(RESOURCE)の変更が可能であり、セキュリティ面でも優位とできます。
リソース(RESOURCE)は利用側(MEMBER)固有でなくても同じです。

システムを提供する側と利用する側のAPIを簡素にすることができ、独自の認証・認可も不要となります。
連携させるための管理は、K2HR3システム上で双方が分離して設定・管理することができます。

REST API Usage Usage Other