特許 7271147 サービス認可処理装置、システム、方法及びプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2023-04-28

(45)【発行日】2023-05-11

(54)【発明の名称】サービス認可処理装置、システム、方法及びプログラム

(51)【国際特許分類】

   G06F 21/44 20130101AFI20230501BHJP

【ＦＩ】

G06F21/44

【請求項の数】 7

(21)【出願番号】P 2018224487

(22)【出願日】2018-11-30

(65)【公開番号】P2020087235

(43)【公開日】2020-06-04

【審査請求日】2021-10-28

【前置審査】

(73)【特許権者】

【識別番号】000003078

【氏名又は名称】株式会社東芝

(73)【特許権者】

【識別番号】301063496

【氏名又は名称】東芝デジタルソリューションズ株式会社

(74)【代理人】

【識別番号】110003708

【氏名又は名称】弁理士法人鈴榮特許綜合事務所

(72)【発明者】

【氏名】保坂 真由美

(72)【発明者】

【氏名】江崎 裕一郎

(72)【発明者】

【氏名】斉藤 稔

【審査官】局 成矢

(56)【参考文献】

【文献】特開２０１３－１０５４４２（ＪＰ，Ａ）

【文献】特開２０１７－２０４０７３（ＪＰ，Ａ）

【文献】特開２０１７－０５９２１９（ＪＰ，Ａ）

【文献】米国特許出願公開第２０１７／００８３６９７（ＵＳ，Ａ１）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ ２１／４４

(57)【特許請求の範囲】

【請求項1】

複数のサービスを連携して、所定の機能を実現するシステムに適用するサービス認可処理装置であって、
連携する各サービスを実行する際に、認可が必要であるか否かを判定する認可判定手段と、
認可が必要であるサービスに対して認可に利用する認可情報を提供するために、前記認可情報を取得して管理する認可情報管理手段と、
前記連携する各サービスの起動時に、前記システムに含まれるサーバから取得する情報に基づいて、前記連携する各サービス毎に、呼び出し関係を示す第１の情報と、認可の必要性が有るか又は無いかを特定する第２の情報とを含む認可処理情報を作成する認可処理情報作成手段と、
前記認可処理情報作成手段によって作成された前記認可処理情報を格納する第２の記憶装置とを具備し、
前記認可判定手段は、前記認可処理情報において、前記第２の情報に、許可の必要性が無いと特定されているサービスが認可を必要としないと判定する、
サービス認可処理装置。

【請求項2】

前記認可情報管理手段は、
前記システムに含まれるサーバから、前記認可判定手段により認可が必要であると判定されるサービスに対応する認可情報を取得し、
前記認可情報を第１の記憶装置に格納し、
前記認可情報を利用するサービスからの要求に基づいて、前記第１の記憶装置から前記認可情報を取り出して前記サービスに提供する、請求項１に記載のサービス認可処理装置。

【請求項3】

請求項１又は２に記載のサービス認可処理装置と、
前記サービス認可処理装置と通信して、複数のサービスを連携して実行する第１のサーバと、
前記サービス認可処理装置と通信して、前記認可情報を生成して前記サービス認可処理装置に提供する第２のサーバと
を具備する、システム。

【請求項4】

前記サービス認可処理装置は、
前記第１のサーバ及び前記第２のサーバと通信し、各種の情報を交換する中継手段を含む、請求項３に記載のシステム。

【請求項5】

複数のサービスを連携して、所定の機能を実現するシステムに適用するサービス認可処理の方法であって、
連携する各サービスを実行する際に、認可が必要であるか否かを判定する処理と、
認可が必要であるサービスに対して認可に利用する認可情報を提供するために、前記認可情報を取得して管理する処理と、
前記連携する各サービスの起動時に、前記システムに含まれるサーバから取得する情報に基づいて、前記連携する各サービス毎に、呼び出し関係を示す第１の情報と、認可の必要性が有るか又は無いかを特定する第２の情報とを含む認可処理情報を作成して、第２の記憶装置に格納する処理と、
前記認可処理情報において、前記第２の情報に、許可の必要性が無いと特定されているサービスが認可を必要としないと判定する処理とを実行する、方法。

【請求項6】

前記システムに含まれるサーバから、認可が必要であると判定されるサービスに対応する前記認可情報を取得する処理と、
前記認可情報を第１の記憶装置に格納する処理と、
前記認可情報を利用するサービスからの要求に基づいて、前記第１の記憶装置から前記認可情報を取り出して前記サービスに提供する処理と
を実行する、請求項５に記載の方法。

【請求項7】

請求項５又は６に記載の方法による各処理を、コンピュータに実行させるプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明の実施形態は、サービス認可処理装置、システム、方法及びプログラムに関する。

【背景技術】

【0002】

近年、例えばWebサービスを提供するためのシステムやソフトウェアの開発において、サービスの全機能を、いわゆるモノリス（monolith）構成ではなく、マイクロサービスを利用して構成する方式が注目されている。マイクロサービスアーキテクチャは、複数のサービスを組み合わせて連携させることにより、所定の全機能を実現する仕組みである。マイクロサービスを利用する方式であれば、外部のサービスを利用できるために、開発コストの削減を実現できる。また、組み合わせる各サービスは独立性があるため、サービス（機能）ごとの変更や追加が容易となる。

【0003】

ところで、マイクロサービスを利用して、連携元のサービスが連携先のサービスを呼び出して利用する場合に、例えばOAuth2というプロトコルを利用した認可が必要となることがある。この場合、例えばアクセストークン（access token）のような、認可に必要な認可情報を取得するための認可処理が必要となる。

【先行技術文献】

【特許文献】

【0004】

【文献】特開２０１５－２２８０６７号公報

【文献】ＷＯ２０１３１４５５１７号公報

【文献】特開２００９－９９１３１号公報

【文献】特開２０１３－１４５５０６号公報

【発明の概要】

【発明が解決しようとする課題】

【0005】

マイクロサービスを利用する方式では、認可を必要としない連携元のサービスが、認可が必要である連携先のサービスを呼び出して利用する場合、当該連携元サービスは認可処理を実行する機能を実装することが要求されることになる。このため、マイクロサービスの利点に含まれる各サービスの独立性を確保できなくなる。

【0006】

そこで、目的は、認可を必要とするサービスを含む複数のサービスを連携して、所定の機能を実現する方式に適用できると共に、各サービスの独立性を確保できるサービス認可処理装置を提供することにある。

【課題を解決するための手段】

【0007】

本実施形態のサービス認可処理装置は、複数のサービスを連携して、所定の機能を実現するシステムに適用するサービス認可処理装置であって、認可判定手段と、認可情報管理手段と、認可処理情報作成手段と、第２の記憶装置とを有する。前記認可判定手段は、連携する各サービスを実行する際に、認可が必要であるか否かを判定する。前記認可情報管理手段は、認可が必要であるサービスに対して認可に利用する認可情報を提供するために、前記認可情報を取得して管理する。認可処理情報作成手段は、前記連携する各サービスの起動時に、前記システムに含まれるサーバから取得する情報に基づいて、前記連携する各サービス毎に、呼び出し関係を示す第１の情報と、認可の必要性が有るか又は無いかを特定する第２の情報とを含む認可処理情報を作成する。前記第２の記憶装置は、前記認可処理情報作成手段によって作成された前記認可処理情報を格納する。前記認可判定手段はさらに、前記認可処理情報において、前記第２の情報に、許可の必要性が無いと特定されているサービスが認可を必要としないと判定する。

【図面の簡単な説明】

【0008】

【図1】実施形態に関するシステムの構成を説明するためのブロック図。

【図2】実施形態に関するサービス関連テーブルの一例を示す図。

【図3】実施形態に関する認可情報テーブルの一例を示す図。

【図4】実施形態に関するユーザ情報テーブルの一例を示す図。

【図5】実施形態に関する各サービスの呼び出し関係の一例を示す図。

【図6】実施形態に関する認可処理の概要を説明するための図。

【図7】実施形態に関する認可処理を説明するためのフローチャート。

【図8】実施形態に関する認可判定部の処理を説明するためのフローチャート。

【図9】実施形態に関するアクセストークン管理部の処理を説明するためのフローチャート。

【図10】実施形態に関するサービス関連作成部の処理を説明するためのフローチャート。

【発明を実施するための形態】

【0009】

以下図面を参照して、実施形態を説明する。
［システムの構成］
図１は、本実施形態に関するシステム１の構成を示す図である。図１に示すように、本実施形態のシステム１は、認可処理装置１０、認可サーバ１３、リソースサーバ１４、及び各種のサービス（機能）Ａ～Ｅを実現するサービス提供サーバ１５を有する。サービス提供サーバ１５は、各サービスＡ～Ｅをそれぞれ独立して実現する複数のサーバ群であり、後述するように、各サービスＡ～Ｅを連携させるマイクロサービスを実現する。マイクロサービスは、複数のサービスを連携して所定のサービス（機能）を実現する方式である。

【0010】

認可処理装置１０は、主としてコンピュータ及び記憶装置により実現する、ＡＰＩゲートウエイ（Application Programming Interface Gateway）１１及びサービスレジストリ１２を含む。本実施形態のＡＰＩゲートウエイ１１は、クライアント２とサービス（Ａ～Ｅ）との間で各種の情報を交換する中継機能を実現すると共に、後述する認可判定機能を有する。ＡＰＩゲートウエイ１１は、通信の制御を実行する通信部１０１及び認可判定部１０２を含む。認可判定部１０２は、後述する認可情報取得部１０３により取得されたデータに基づいて、サービスを利用する上での認可が必要であるか否かを判定する認可判定処理を実行する。

【0011】

サービスレジストリ１２は情報管理用のサーバに相当し、認可情報取得部１０３、アクセストークン（Access Token）管理部１０４、認可情報記憶部１０５、及びサービス関連作成部１０６を含む。認可情報取得部１０３は、認可情報記憶部１０５から、後述するサービス関連テーブル２０、認可情報テーブル２１、及びユーザ情報テーブル２２を取得する。これらの各テーブル２０、２１、２２は、認可処理装置１０において使用される認可処理情報である。

【0012】

アクセストークン管理部１０４は、認可サーバ１３により発行されるアクセストークンを認可情報記憶部１０５に登録する処理や、認可情報記憶部１０５からアクセストークンを取得する処理を実行する。認可情報記憶部１０５は、サービス関連テーブル２０、認可情報テーブル２１、及びユーザ情報テーブル２２を格納すると共に、登録対象のアクセストークンを格納する。サービス関連作成部１０６は、後述するように、サービス関連テーブル２０及び認可情報テーブル２１を作成して、認可情報記憶部１０５に格納する。

【0013】

認可サーバ１３は、ＡＰＩゲートウエイ１１の通信部１０１と接続し、ユーザが操作するクライアント２からのリクエストに基づいて、リソースサーバ１４にアクセスするか否かの判定処理や、アクセストークンを発行する処理を実行する。本実施形態では、リソースサーバ１４は、例えばサービスＥと連携する外部のサービス（Ｆ）を提供する。ここで、サービスＥが当該サービス（Ｆ）にアクセスするためには、例えばOAuth2のプロトコルを利用した認可が必要であるとする。なお、本実施形態では、当該OAuth2のプロトコルを利用した認可を、単に認可と表記する。

【0014】

図２は、サービス関連テーブル２０の一例を示す図である。サービス関連テーブル２０は、マイクロサービスを実現するために、連携する各サービスの呼び出し関係を表す情報である。図５は、当該各サービスの呼び出し関係の一例を示す図である。図５に示すように、クライアント２からのリクエストにより、サービスＡ（パス：/service a-1）が呼び出されると、サービスＡはサービスＢ（パス：/service b-1）とサービスＤ（パス：/service ｄ-1）を呼び出す。さらに、サービスＢは、サービスＣ（パス：/service c-1）とサービスＥ（パス：/service e-1）を呼び出す関係になっている。

【0015】

図２に示すように、サービス関連テーブル２０は、図５で示すような各サービスの呼び出し関係を、サービス名とパスにより一意に特定できる情報である。即ち、サービス関連テーブル２０は、行単位のデータにより、どのサービスがどのサービスを呼び出しているかを定義している。例えば、１行目のデータは、サービスＡ（パス：/service a-1）が、サービスＢ（パス：/service b-1）を呼び出すことを定義している。ここで、パスとは、サービス名のサービスにアクセスするためのルートを示し、例えばＵＲＬ（Uniform Resource Locator）のパス名に相当する情報である。

【0016】

図３は、認可情報テーブル２１の一例を示す図である。図３に示すように、認可情報テーブル２１は、各サービスＡ～Ｅにアクセスする（呼び出す）ために、認可を必要とするか否かを示す情報である。認可情報テーブル２１は、例えば、サービスＡからサービスＤについては認可を必要とせず、サービスＥについては認可を必要とすることを示している。

【0017】

図４は、ユーザ情報テーブル２２の一例を示す図である。図４に示すように、ユーザ情報テーブル２２は、ユーザ毎に、サービスにアクセスする際の認可に必要なアクセストークン（Access Token）を設定している情報である。即ち、アクセストークンは、認可に使用する認可情報である。ユーザ情報テーブル２２は、例えば、ユーザＩＤとして「User C」が設定されたユーザが、クライアント２からサービスＥにアクセスするためのアクセストークン「accVkjcJyb4BWCx」、及び、その有効期限が「2020/11/30 00:00:00」であることを示している。
［システムの動作］
図６は、本実施形態の認可処理装置１０及び認可サーバ１３による認可処理の概要を説明するための図である。ここでは、ユーザＩＤとして「User A」が設定されたユーザがクライアント２から、サービスＡ（パス：/service a-1）にアクセスする例として説明する。

【0018】

ＡＰＩゲートウエイ１１は、クライアント２からサービスＡに対してアクセスがあると（６０）、認可判定部１０２がアクセス先のサービスが認可を必要とするか否かを判定する。認可判定部１０２は、サービスレジストリ１２にアクセスし（６１）、認可情報記憶部１０５に格納されたサービス関連テーブル２０及び認可情報テーブル２１を参照して、認可の有無を判定する。なお、クライアント２は、例えば、パーソナルコンピュータのディスプレイ２００及びＰＣ本体２０１からなる。

【0019】

ここで、ＡＰＩゲートウエイ１１は、例えばサービスＡと連携してアクセス先となるサービス（Ｅ）が認可を必要とする場合には、クライアント２のＰＣ本体２０１に対して認可を行うためにリダイレクトする（６２）。クライアント２は、認可サーバ１３にリダイレクトすることで（６３）、認可サーバ１３からログイン画面情報を受信する（６４）。クライアント２は、ディスプレイ２００上の表示されたログイン画面上にユーザＩＤやパスワードを入力して、認可サーバ１３に送信する（６５）。認可サーバ１３は、ユーザＩＤやパスワードが正しい場合には、認可コードをクライアント２及びＡＰＩゲートウエイ１１に返信する（６６）。

【0020】

ＡＰＩゲートウエイ１１は、認可サーバ１３から取得する認可コードを利用して、認可サーバ１３により発行される認可情報であるアクセストークンを取得する（６７）。本実施形態では、ＡＰＩゲートウエイ１１は、認可サーバ１３から取得したアクセストークンを、サービスレジストリ１２の認可情報記憶部１０５に格納する（６１）。

【0021】

このような認可処理の実行後に、ＡＰＩゲートウエイ１１は、サービスＡに対してアクセスする（６８）。図５に示すような呼び出し関係により、各サービスＡからＥは連携して、所定のサービスの全機能を実現する。即ち、サービスＡは、連携先であるサービスＢ及びサービスＤを呼び出す。さらに、サービスＢは、連携先であるサービスＣ及びサービスＥを呼び出す。

【0022】

ここで、サービスＥは、リソースサーバ１４にアクセスするために、サービスレジストリ１２の認可情報記憶部１０５に格納されたアクセストークンを取得する（６９）。サービスＥは、リソースサーバ１４に当該アクセストークンを送信する（７０）。即ち、サービスＥは、アクセストークンを使用してサービスＦを呼び出し、必要なリソースを取得できる（７１）。

【0023】

図７から図１０は、本実施形態の認可処理装置１０及び認可サーバ１３による認可処理を、さらに詳細に説明するためのフローチャートである。

【0024】

図７に示すように、ＡＰＩゲートウエイ１１は、通信部１０１がクライアント２から、サービスＡに対してアクセスするためのリクエストを受け付けると（Ｓ１）、認可判定部１０２により認可が必要であるか否かを判定する（Ｓ２）。

【0025】

図８は、認可判定部１０２の判定処理を説明するためのフローチャートである。認可判定部１０２は、サービスレジストリ１２の認可情報取得部１０３にアクセスする。図８に示すように、認可情報取得部１０３は、認可情報記憶部１０５からサービス関連テーブル２０及び認可情報テーブル２１を取得する（Ｓ２０）。認可判定部１０２は、サービス関連テーブル２０を参照して、パスとサービス名が一致する項目のデータを取得する（Ｓ２１）。ここでは、サービスＡ（パス：/service a-1）にアクセスしているので、サービス関連テーブル２０の１行目と２行目の各データを取得する。

【0026】

次に、認可判定部１０２は、認可情報テーブル２１を参照して、パスとサービス名が一致する項目のデータを取得する（Ｓ２２）。認可判定部１０２は、認可情報テーブル２１のデータから、認可の有無を判定する（Ｓ２３）。具体的には、認可情報テーブル２１の１行目のデータは、認可の値が無しなっているため、認可判定部１０２は、サービスＡが認可を行わない（認可を必要としない）と判定する。

【0027】

次に、認可判定部１０２は、サービス関連テーブル２０を参照して、パスを含むサービス名（Ａ）に対応する、利用サービスパスを含む利用サービス名（Ｂ，Ｄ）を取得する（Ｓ２４）。利用サービスパスと利用サービス名が無しの場合は、対応するサービスから呼び出されるサービスが無いことを示す。

【0028】

具体的には、サービス関連テーブル２０の１行目のデータから、サービスＡがする利用サービスが利用サービス名Ｂ（利用サービスパス：/service b-1）であるため、認可判定部１０２は、サービス関連テーブル２０の３及び４行目のデータ（いずれもサービス名Ｂ）を取得する。同様に、サービス関連テーブル２０の２行目のデータ（利用サービス名Ｄ）から、サービス関連テーブル２０の６行目のデータ（サービス名Ｄ）を取得する。

【0029】

認可判定部１０２は、サービス関連テーブル２０からデータを取得できなくなるまで、Ｓ２１からの処理を繰り返す（Ｓ２５のＹＥＳ）。認可判定部１０２は、データを取得できなかった場合に処理を終了する（Ｓ２５のＮＯ）。このような認可判定部１０２の処理により、サービスＡ（パス：/service a-1）にアクセスするためには、提携先のサービスＥ（パス：/service e-1）において認可が必要であることが判定できる。

【0030】

図７に戻って、ＡＰＩゲートウエイ１１は、サービスＡにアクセスするために、認可判定部１０２により認可が必要でないと判定された場合（Ｓ３のＮＯ）、通信部１０１を経由してサービスＡを実行して処理を終了する（Ｓ１７）。即ち、クライアント２は、ＡＰＩゲートウエイ１１を介して、サービスＡからＥが連携して実現される、所定のサービスの全機能が提供される。

【0031】

一方、認可判定部１０２は認可が必要と判定した場合、アクセストークン管理部１０４にアクセスする（Ｓ３のＹＥＳ）。アクセストークン管理部１０４は、認可情報記憶部１０５にアクセストークンが登録（格納）されている否かを確認する（Ｓ４）。

【0032】

図９は、アクセストークン管理部１０４の処理を説明するためのフローチャートである。図９に示すように、アクセストークン管理部１０４は、認可情報記憶部１０５からユーザ情報テーブルを取得する（Ｓ３０）。アクセストークン管理部１０４は、ユーザ情報テーブル（図４を参照）から、ユーザＩＤ、パス、サービス名（Ｅ）が一致するデータを取得する（Ｓ３１）。具体的には、ユーザ情報テーブル２２から、例えば、ユーザＩＤとして「User C」、パスが「/service e-1」、及びサービス名Ｅのデータを取得する。即ち、サービスＡ（パス：/service a-1）にアクセスするためには、提携先のサービスＥ（パス：/service e-1）において認可が必要であるという、認可判定部１０２の判定結果に基づいている。

【0033】

アクセストークン管理部１０４は、ユーザ情報テーブル２２から、アクセストークンが登録済みであるか否かを確認する（Ｓ３２）。ここで、アクセストークン管理部１０４は、ユーザ情報テーブル２２の１行目のデータにはアクセストークンの値がないため、この場合には、アクセストークンが登録済みでないと判定し（Ｓ３２のＮＯ）、その旨を認可判定部１０２に返信する（Ｓ３４）。

【0034】

アクセストークン管理部１０４は、ユーザ情報テーブル２２の３行目のデータにはアクセストークンの値があるため、アクセストークンが登録済みであると判定し（Ｓ３２のＹＥＳ）、その旨を認可判定部１０２に返信する（Ｓ３３）。但し、アクセストークン管理部１０４は、有効期限の値が現在より前であれば、アクセストークンが登録済みでないと判定し、有効期限の値が現在より後であれば、アクセストークンが登録済みであると判定する。

【0035】

図７に戻って、ＡＰＩゲートウエイ１１は、認可判定部１０２がアクセストークン管理部１０４からアクセストークンが登録済みであるとの返信を受けると（Ｓ５のＹＥＳ）、通信部１０１を経由してサービスＡを実行する（Ｓ１４）。即ち、図５に示すような呼び出し関係により、各サービスＡからＥは連携して、所定のサービスの全機能を実現する。

【0036】

この場合、サービスＥは、サービスＢからの呼び出しに応じて、アクセストークン管理部１０４から、認可情報記憶部１０５に登録（格納）されているアクセストークンを取得する（Ｓ１５）。サービスＥは、ＡＰＩゲートウエイ１１から送信される、ユーザ情報テーブル２２のユーザＩＤ、パス、サービス名を含む情報を利用して、アクセストークン管理部１０４から所定のアクセストークンを取得する。サービスＥは、当該アクセストークンを利用してリソースサーバ１４にアクセスし、サービスＦを呼び出して必要なリソースを取得する（Ｓ１６）。これにより、クライアント２は、ＡＰＩゲートウエイ１１を介して、サービスＡからＥが連携して実現される、所定のサービスの全機能が提供される。

【0037】

一方、ＡＰＩゲートウエイ１１は、認可判定部１０２がアクセストークン管理部１０４からアクセストークンが登録済みでないとの返信を受けると（Ｓ５のＮＯ）、通信部１０１を経由して認可サーバ１３にリダイレクトする（Ｓ６）。以下、図６を参照して前述したように、アクセストークン管理部１０４は、認可サーバ１３が発行するアクセストークンを、認可情報記憶部１０５に登録（格納）する処理を実行する。

【0038】

即ち、認可サーバ１３は、クライアント２にログイン画面を表示する（Ｓ７）。クライアント２は、ユーザがログイン画面に入力した、ユーザＩＤとパスワードを、認可サーバ１３に送信する（Ｓ８）。認可サーバ１３は、送信されたユーザＩＤとパスワードが正しくない場合には、クライアント２にログイン画面を再度表示する（Ｓ９のＮＯ）。

【0039】

一方、認可サーバ１３は、送信されたユーザＩＤとパスワードが正しい場合には（Ｓ９のＹＥＳ）、通信部１０１に認可コードを返信する（Ｓ１０）。ＡＰＩゲートウエイ１１は、通信部１０１を経由し、認可コードを利用して認可サーバ１３からアクセストークンを取得する（Ｓ１１）。通信部１０１は、取得したアクセストークンを、アクセストークン管理部１０４に渡す（Ｓ１２）。アクセストークン管理部１０４は、アクセストークンを認可情報記憶部１０５に登録する（Ｓ１３）。具体的には、アクセストークン管理部１０４は、認可情報記憶部１０５に格納されているユーザ情報テーブル２２に対して、ユーザＩＤ、パス、サービス名（Ｅ）、アクセストークン、アクセストークンの有効期限を登録する（図４を参照）。

【0040】

ここで、サービス関連作成部１０６は、ＡＰＩゲートウエイ１１からの通知に応じたサービス起動時に、サービス関連テーブル２０及び認可情報テーブル２１を作成して認可情報記憶部１０５に格納する。図１０は、サービス関連作成部１０６の処理を示すフローチャートである。

【0041】

図１０に示すように、サービス起動時に、サービス関連作成部１０６は、ＡＰＩゲートウエイ１１を経由して、サービス提供サーバ１５により呼び出される。サービス関連作成部１０６は、サービス提供サーバ１５からＡＰＩゲートウエイ１１を経由して提供される情報に基づいて、サービス関連テーブル２０を作成して認可情報記憶部１０５に格納（登録）する（Ｓ４０）。この場合、サービス関連作成部１０６は、サービスのソースコードや設定ファイルなどに基づいて各サービスの呼び出し関係を取得し、サービス関連テーブル２０を作成する。

【0042】

次に、サービス関連作成部１０６は、サービス提供サーバ１５からＡＰＩゲートウエイ１１を経由して提供される情報に基づいて、認可情報テーブル２１を作成して認可情報記憶部１０５に格納（登録）する（Ｓ４１）。この場合、サービス関連作成部１０６は、サービスのソースコードや設定ファイルなどに基づいて、該当するサービスが認可を必要とするか否かの情報を取得し、認可情報テーブル２１を作成する。

【0043】

以上のように本実施形態によれば、クライアントからのリクエストに応じて、複数のサービスが連携して所定のサービスの全機能を実現する、マイクロサービスを提供することが可能となる。このようなマイクロサービスにおける各サービスの呼び出し関係において、呼び出し先のサービスで認可が必要となる場合に、当該サービスが認可に必要なアクセストークンを利用することができる。これにより、連携する複数のサービスの中で、認可を必要としない呼び出し元のサービスは、呼び出し先の認可に必要な認可処理機能の実装が不要となる。従って、各サービスが連携してマイクロサービスを実現する場合に、各サービスの独立性を確保することができる。

【0044】

なお、本実施形態では、OAuth2というプロトコルを利用する認可について説明したが、これに限ることなく、別の方式による認可にも適用できる。また、本実施形態の各サービスの呼び出し関係は一例であり、別の呼び出し関係にも適用できる。

【0045】

本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

【符号の説明】

【0046】

１…システム、２…クライアント、１０…認可処理装置、１１…ＡＰＩゲートウエイ、
１２…サービスレジストリ、１３…認可サーバ、１４…リソースサーバ、
１５…サービス提供サーバ、１０１…通信部、１０２…認可判定部、
１０３…認可情報取得部、１０４…アクセストークン管理部、
１０５…認可情報記憶部、１０６…サービス関連作成部。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】