特許 7468284 情報処理装置、配信制御プログラム、及び、情報処理システム

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

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

(11)【特許番号】

(24)【登録日】2024-04-08

(45)【発行日】2024-04-16

(54)【発明の名称】情報処理装置、配信制御プログラム、及び、情報処理システム

(51)【国際特許分類】

   G06F 21/33 20130101AFI20240409BHJP

   G06F 21/62 20130101ALI20240409BHJP

【ＦＩ】

G06F21/33 350

G06F21/62

【請求項の数】 8

(21)【出願番号】P 2020168260

(22)【出願日】2020-10-05

(65)【公開番号】P2022060666

(43)【公開日】2022-04-15

【審査請求日】2023-07-07

(73)【特許権者】

【識別番号】000005223

【氏名又は名称】富士通株式会社

(74)【代理人】

【識別番号】100092978

【弁理士】

【氏名又は名称】真田 有

(74)【代理人】

【識別番号】100189201

【弁理士】

【氏名又は名称】横田 功

(72)【発明者】

【氏名】大石 亮介

(72)【発明者】

【氏名】金丸 将平

【審査官】小林 秀和

(56)【参考文献】

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

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

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

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

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

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

Ｇ０６Ｆ ２１／３３

Ｇ０６Ｆ ２１／６２

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

【請求項1】

ユーザの認証を行なう認証システムによる認証結果に基づき前記ユーザに発行されたアクセストークンを含むデータ取得要求の受信に応じて、前記アクセストークンに対応付けられた１以上の契約情報であって契約の有効期限及び契約の対象部門の情報を含む前記１以上の契約情報と、前記データ取得要求の対象となるデータとに基づき、前記ユーザの所属確認を行なうか否かを判定し、
前記ユーザの所属確認を行なうと判定した場合、前記１以上の契約情報に対応付けられた１以上の認証システムのそれぞれに前記ユーザの所属確認を要求して得られた所属情報に基づき、前記データ取得要求の対象となる前記データを前記ユーザに配信する、制御部を備える
情報処理装置。

【請求項2】

前記制御部は、前記判定する処理において、前記１以上の契約情報について、前記有効期限が到来しておらず、且つ、前記対象部門が限定されている場合、前記ユーザの所属確認を行なうと判定する、
請求項１に記載の情報処理装置。

【請求項3】

前記制御部は、
前記判定する処理において、前記１以上の契約情報について、前記有効期限が到来しておらず、且つ、前記対象部門が限定されていない場合、前記ユーザの所属確認を行なわないと判定し、
前記配信する処理において、前記１以上の認証システムへの前記所属確認の要求を抑止して前記データを前記ユーザに配信する、
請求項２に記載の情報処理装置。

【請求項4】

前記制御部は、前記配信する処理において、前記所属情報と、少なくとも１つの前記契約情報に含まれる前記対象部門とが一致する場合、前記データを前記ユーザに配信する、
請求項１～請求項３のいずれか１項に記載の情報処理装置。

【請求項5】

前記制御部は、前記判定する処理において、前記アクセストークンに対応付けられた前記契約情報に含まれる前記有効期限が到来している場合、又は、前記アクセストークンに対応付けられた契約情報が存在しない場合、前記データの配信を抑制する、
請求項１～請求項４のいずれか１項に記載の情報処理装置。

【請求項6】

前記契約情報は、アクセスが許可される記憶領域に関する情報を含み、
前記制御部は、前記判定する処理において、前記１以上の契約情報について、前記記憶領域が前記データの格納先と一致しない場合、前記ユーザの所属確認を行なわないと判定し、前記データの配信を抑制する、
請求項１～請求項５のいずれか１項に記載の情報処理装置。

【請求項7】

ユーザの認証を行なう認証システムによる認証結果に基づき前記ユーザに発行されたアクセストークンを含むデータ取得要求の受信に応じて、前記アクセストークンに対応付けられた１以上の契約情報であって契約の有効期限及び契約の対象部門の情報を含む前記１以上の契約情報と、前記データ取得要求の対象となるデータとに基づき、前記ユーザの所属確認を行なうか否かを判定し、
前記ユーザの所属確認を行なうと判定した場合、前記１以上の契約情報に対応付けられた１以上の認証システムのそれぞれに前記ユーザの所属確認を要求して得られた所属情報に基づき、前記データ取得要求の対象となる前記データを前記ユーザに配信する、処理をコンピュータに実行させる、配信制御プログラム。

【請求項8】

複数の認証システムと、情報処理装置と、を備え、
前記情報処理装置は、
ユーザの認証を行なう認証システムによる認証結果に基づき前記ユーザに発行されたアクセストークンを含むデータ取得要求の受信に応じて、前記アクセストークンに対応付けられた１以上の契約情報であって契約の有効期限及び契約の対象部門の情報を含む前記１以上の契約情報と、前記データ取得要求の対象となるデータとに基づき、前記ユーザの所属確認を行なうか否かを判定し、
前記ユーザの所属確認を行なうと判定した場合、前記１以上の契約情報に対応付けられた１以上の認証システムのそれぞれに前記ユーザの所属確認を要求して得られた所属情報に基づき、前記データ取得要求の対象となる前記データを前記ユーザに配信する、制御部を備える
情報処理システム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、情報処理装置、配信制御プログラム、及び、情報処理システムに関する。

【背景技術】

【0002】

仮想化技術を利用したサービスとして、コンテナ配信サービスが知られている。コンテナは、仮想的なＯＳ空間を提供する技術である。コンテナ配信サービスのサービス提供者は、契約者ごとにコンテナを取得（例えばダウンロード）するための環境を提供する。

【0003】

ユーザによるコンテナの取得及び取得したコンテナの実行は、ＣＵＩ（Character User Interface）で実行されることがある。例えば、ＣＩ（Continuous Integration）／ＣＤ（Continuous Delivery）及びバッチ処理等では、当該取得及び実行が人手を介さずに自動で繰り返し実施される場合がある。

【0004】

繰り返しの実施が継続される繰り返し期間は、数日程度の場合もあるが、１年間等の長期間に亘る場合もある。当該繰り返し期間にコンテナがバージョンアップされた場合、サービス提供者は、最新版のコンテナを配信し、ユーザは、ＣＩ／ＣＤ及びバッチ処理等により、配信された最新版のコンテナを自動で取得及び実行する。

【0005】

コンテナ配信サービスでは、アクセス制御を行なうサーバは、ユーザがサービスにログインする際に、ユーザ及び契約者の属性の情報に基づきユーザのアクセス権限を確認（認証）する。契約者は、ユーザが所属する会社、部署等であってよい。ユーザがアクセス権限を有している場合、サーバは、ユーザの認証に成功したことを証明する証明情報、例えばトークンをユーザに配布する。ユーザは、配布されたトークンを利用することで、認証をスキップして、コンテナ配信サービスへのアクセス、例えばコンテナの取得を行なうことができる。

【先行技術文献】

【特許文献】

【0006】

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

【発明の概要】

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

【0007】

繰り返し期間にコンテナがバージョンアップされた場合、ユーザは、トークンを利用して、配信される最新版のコンテナを取得し、取得したコンテナを実行する。このとき、ユーザが最後にログインをしてから（認証を行なってから）、最新版のコンテナを取得するまでの間に、ユーザ及び契約者の一方又は双方に関する属性に変更が生じる場合がある。繰り返し期間が１年間等の長期間に亘る場合、属性に変更が生じる可能性が高くなる。

【0008】

例えば、属性の変更により、最新版のコンテナを取得する際のユーザは、認証が行なわれたとすれば認証失敗となる、換言すればコンテナの配信対象外となる場合がある。しかし、トークンによりユーザの認証が省略されるため、属性の変更により配信対象外となるユーザであっても、コンテナを取得できてしまう場合がある。

【0009】

上述した不都合は、サービスの利用者の属性に基づく制約に応じて利用者にデータを配信する種々のシステムであって、利用者の認証とデータの配信とが互いに異なるタイミングとなる種々のシステムにおいても同様に生じ得る。

【0010】

１つの側面では、本発明は、適切な利用者にデータを配信することを目的の１つとする。

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

【0011】

１つの側面では、情報処理装置は、制御部を備えてよい。前記制御部は、ユーザの認証を行なう認証システムによる認証結果に基づき前記ユーザに発行されたアクセストークンを含むデータ取得要求の受信に応じて、前記アクセストークンに対応付けられた１以上の契約情報であって契約の有効期限及び契約の対象部門の情報を含む前記１以上の契約情報と、前記データ取得要求の対象となるデータとに基づき、前記ユーザの所属確認を行なうか否かを判定してよい。また、前記制御部は、前記ユーザの所属確認を行なうと判定した場合、前記１以上の契約情報に対応付けられた１以上の認証システムのそれぞれに前記ユーザの所属確認を要求して得られた所属情報に基づき、前記データ取得要求の対象となる前記データを前記ユーザに配信してよい。

【発明の効果】

【0012】

１つの側面では、本発明は、適切な利用者にデータを配信できる。

【図面の簡単な説明】

【0013】

【図1】一実施形態に係るシステムの構成例を示すブロック図である。

【図2】権限管理サーバによるログイン処理の動作例を説明するためのフローチャートである。

【図3】権限管理サーバによるログイン処理の動作例を説明するためのシーケンス図である。

【図4】契約データデータベース（ＤＢ）の一例を示す図である。

【図5】アクセス制御ＤＢの一例を示す図である。

【図6】権限管理サーバによるダウンロード（ＤＬ）処理の動作例を説明するためのフローチャートである。

【図7】権限管理サーバによるＤＬ処理の動作例を説明するためのシーケンス図である。

【図8】コンテナ配信システムの機能を実現するコンピュータのハードウェア（ＨＷ）構成例を示すブロック図である。

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

【0014】

以下、図面を参照して本発明の実施の形態を説明する。ただし、以下に説明する実施形態は、あくまでも例示であり、以下に明示しない種々の変形又は技術の適用を排除する意図はない。例えば、本実施形態を、その趣旨を逸脱しない範囲で種々変形して実施することができる。なお、以下の説明で用いる図面において、同一符号を付した部分は、特に断らない限り、同一若しくは同様の部分を表す。

【0015】

〔１〕一実施形態
〔１－１〕一実施形態に係るシステムの説明
図１は、一実施形態に係るシステム１の構成例を示すブロック図である。図１に示すように、システム１は、情報処理システムの一例であり、例示的に、コンテナ配信システム２、複数（図１の例では３つ）のユーザ端末５ａ～５ｃ、並びに、複数（図１の例では３つ）の認証システム６ａ～６ｃを備えてよい。

【0016】

コンテナ配信システム２は、コンテナをユーザ（利用者）に配信する情報処理装置の一例である。

【0017】

図１に示すように、コンテナ配信システム２は、例示的に、権限管理サーバ３、契約データＤＢ（Database）３４、アクセス制御ＤＢ３５、並びに、複数（図１の例では３つ）のリポジトリ４ａ～４ｃを備えてよい。

【0018】

以下、リポジトリ４ａ～４ｃ、ユーザ端末５ａ～５ｃ及び認証システム６ａ～６ｃのそれぞれについて、互いに区別しない場合には、単にリポジトリ４、ユーザ端末５及び認証システム６と表記する。

【0019】

リポジトリ４は、データを格納する記憶領域であり、例えばＤＢ等であってよい。例えば、リポジトリ４ａ～４ｃ（リポジトリＸ、Ｙ、Ｚと表記）は、それぞれ、１以上のコンテナイメージ４０ａ～４０ｃ（コンテナイメージＸ１…、Ｙ１…、Ｚ１…と表記）を格納してよい。コンテナ配信システム２は、リポジトリ４に格納されたコンテナイメージ４０をユーザに配信してよい。ユーザによるコンテナ配信サービスへのアクセスは、例えば、契約者ごとに設定されたリポジトリ４単位のアクセス制限に応じて制御されてよい。

【0020】

ユーザ端末５は、ユーザが利用するＰＣ（Personal Computer）等のコンピュータであってよい。ユーザ端末５は、図示しないネットワークを介してコンテナ配信システム２とアクセス可能に接続されてよく、例えば、コンテナ配信システム２へのログイン、コンテナ配信システム２からのコンテナイメージ４０のダウンロード、コンテナイメージ４０の実行等の処理を行なってよい。

【0021】

認証システム６は、ユーザの認証を行なうシステムであり、例えば、Ａ社、Ｂ社、Ｃ社等の契約者ごとに存在してよい。図１の例では、Ａ社認証システム６ａがＡ社に所属するユーザの認証を行ない、Ｂ社認証システム６ｂがＢ社に所属するユーザの認証を行ない、Ｃ社認証システム６ｃがＣ社に所属するユーザの認証を行なう。各認証システム６は、契約者が有するシステムであってもよい。認証システム６は、図示しないネットワークを介してコンテナ配信システム２とアクセス可能に接続されてよい。

【0022】

コンテナ配信システム２とユーザ端末５との間、及び、コンテナ配信システム２と認証システム６との間を接続するネットワークは、それぞれ、種々のネットワークであってよい。当該ネットワークは、例えば、インターネット、及び、セルラ網等のモバイルネットワークの一方又は双方であってもよい。また、当該ネットワークは、ＬＡＮ（Local Area Network）等のイントラネットを含んでもよい。

【0023】

権限管理サーバ３は、制御部の一例であり、ユーザ及び契約者の属性の情報に応じて、コンテナ配信サービスから各ユーザにデータを配信するための管理及び制御を行なう。例えば、権限管理サーバ３は、ユーザ端末５を介したユーザによるコンテナ配信サービスへのログインの際に、ユーザ及び契約者の属性の情報に基づき、認証システム６を利用してユーザのアクセス権限を確認（認証）する。ユーザがアクセス権限を有している場合、サーバは、ユーザの認証に成功したことを証明する証明情報、例えばトークンをユーザに配布する。

【0024】

例えば、権限管理サーバ３は、各ドメインと契約者の契約とを対応付けて管理する契約データＤＢ３４、及び、ユーザのアクセス制御に利用されるアクセス制御ＤＢ３５に従い、アクセス制御を行なってよい。これにより、コンテナ配信システム２の管理者（コンテナの配布者）によるユーザ個別の設定作業を不要とすることができ、ユーザの変更に柔軟に対応することができる。ユーザは、配布されたトークンを利用することで、認証をスキップして、コンテナ配信サービスへのアクセスを要求する。権限管理サーバ３は、トークンに基づく認証処理後、ユーザにアクセスを許可する。

【0025】

ところで、セキュリティ上の観点から、ユーザによるコンテナ配信サービスへのログインは、ＣＩ／ＣＤ又はバッチ処理の繰り返し実行の前に手動で行なわれ、自動実行スクリプトにはログインに用いられるパスワードが設定されないことがある。例えば、ユーザがログインに成功し、コンテナのダウンロード用のトークンを付与された場合、自動実行スクリプトは、スクリプト実行時にトークンを参照することで、ユーザによる再ログイン作業、スクリプトへのパスワードの付与を省略できる。従って、ユーザは、長期間に亘って、最新のコンテナを安全に繰り返し取得することができる。

【0026】

しかし、上述したように、繰り返し期間が長期間になると、ログインのタイミングとダウンロードのタイミングとの間に時間差（例えば数日～１年等）が生じる場合がある。このような時間差の期間にユーザの他部署への異動、組織改変等が発生し、ユーザの所属会社、所属部署等の属性が変更されることがある。このような場合、例えば、契約において、コンテナの配布が特定の部署のユーザに限定されていると、ユーザがデータの配布対象外になることがある。

【0027】

そこで、一実施形態に係るコンテナ配信システム２は、ユーザのログインの際に、ユーザの所属会社の認証システム６へのアクセス情報をユーザと対応付けて管理する。そして、コンテナ配信システム２は、ユーザからコンテナのダウンロード要求を受信すると、アクセス情報に基づき認証システム６にアクセスし、認証システム６からユーザの所属部署等の属性に関する情報を取得し、データの配信の可否を判断する。

【0028】

これにより、コンテナ配信システム２は、例えば、所属会社、所属部署等の属性が変更され配布対象外となったユーザへのコンテナ配信サービスへのログイン及びコンテナのダウンロードを不許可とすることが可能となる。

【0029】

〔１－２〕コンテナ配信システムの機能構成例
次に、図１を参照して、一実施形態に係るコンテナ配信システム２の機能構成例を説明する。コンテナ配信システム２の権限管理サーバ３は、契約データＤＢ３４及びアクセス制御ＤＢ３５に基づき、ユーザによるコンテナ配信システム２へのアクセスの制御を行なう。当該制御には、例えば、ユーザからのログイン要求の受信に応じたログイン処理、及び、コンテナのダウンロード要求に応じたダウンロード（ＤＬ；Download）処理が含まれてよい。ログイン処理及びＤＬ処理の詳細は後述する。

【0030】

図１に例示するように、アクセス制御部３１、契約情報照会部３２及び契約管理部３３を備えてよい。

【0031】

アクセス制御部３１は、ユーザ端末５からのログイン要求及びＤＬ要求の受信、契約データＤＢ３４の取得要求、アクセス制御ＤＢ３５の作成及び更新、並びに、ログイン及びＤＬに関するアクセスの制御等の種々の制御を行なう。

【0032】

契約情報照会部３２は、アクセス制御部３１からの要求に応じて、契約管理部３３に対して、契約データＤＢ３４の照会を依頼する。

【0033】

契約管理部３３は、契約データＤＢ３４の管理を行なう。例えば、契約管理部３３は、契約情報照会部３２からの依頼に応じて、特定のユーザ又は契約者に対応する契約情報を契約データＤＢ３４から取得し、契約情報照会部３２に応答してよい。契約管理部３３は、例えば、アクセス制御部３１及び契約情報照会部３２とは異なるアプリケーションプログラム又はモジュールとして実装されるシステム（契約管理システム）であってもよい。

【0034】

契約データＤＢ３４及びアクセス制御ＤＢ３５は、それぞれＤＢであってよく、例えば、それぞれＤＢサーバとして実装されてもよい。契約データＤＢ３４及びアクセス制御ＤＢ３５の一方又は双方は、権限管理サーバ３に含まれてもよい。契約データＤＢ３４及びアクセス制御ＤＢ３５の詳細は後述する。

【0035】

〔１－３〕コンテナ配信システムの動作例
以下、コンテナ配信システム２、例えば権限管理サーバ３における、ログイン処理及びコンテナのＤＬ処理のそれぞれの動作例を、フローチャート及びシーケンス図を参照しながら説明する。

【0036】

（ログイン処理）
図２は、権限管理サーバ３によるログイン処理の動作例を説明するためのフローチャートであり、図３は、権限管理サーバ３によるログイン処理の動作例を説明するためのシーケンス図である。

【0037】

図２に例示するように、権限管理サーバ３のアクセス制御部３１は、ユーザ端末５からコンテナ配信システム２へのログイン要求を受信する（ステップＳ１；図３の処理Ｐ１）。ここで、ログイン要求には、ユーザのメールアドレス及びパスワードが含まれてよい。メールアドレス及びパスワードは、例えば、ユーザに対応する認証システム６、又は、コンテナ配信サービスのユーザアカウント情報であってもよい。以下の説明では、メールアドレスが“[e-mail]”であり、パスワードが“p3rcli29_4”であるものとする。

【0038】

アクセス制御部３１は、ログイン要求に基づき、ユーザの所属（例えば会社、組織、部署等の契約者）を特定し、契約情報照会部３２を介して契約管理部３３に、特定した所属の情報を含む契約情報照会要求を送信する（ステップＳ２）。契約情報の照会は、例えば、ユーザの所属ごとに行なわれてもよいし、当該ユーザ（所属）にアクセスが許可されるリポジトリ４又はコンテナイメージ４０ごとに行なわれてもよい。

【0039】

例えば、アクセス制御部３１は、ログイン要求に含まれるユーザのメールアドレスのドメインである“bar.jp”をユーザの所属として特定し、照会要求に含めてよい（図３の処理Ｐ２）。

【0040】

契約情報照会部３２は、アクセス制御部３１から受信した照会要求を契約管理部３３に送信（転送）する（図３の処理Ｐ３）。

【0041】

契約管理部３３は、受信した照会要求と契約データＤＢ３４とに基づき、契約データＤＢ３４の照会結果を契約情報照会部３２に応答する（図３の処理Ｐ４）。

【0042】

図４は、契約データＤＢ３４の一例を示す図である。図４に示すように、契約データＤＢ３４は、例示的に、「契約ＩＤ（Identifier）」、「ドメイン」、「認証システムのＵＲＩ（Uniform Resource Indicator）」、「契約部門」、「契約期間」、及び、「リポジトリ」の項目を含んでよい。

【0043】

「契約ＩＤ」は、コンテナ配信サービスの契約を識別するための識別情報である。１つの契約者に対して、複数の契約が存在してもよい。

【0044】

「ドメイン」は、契約に対応付けて設定されるドメインである。契約に基づきコンテナ配信サービスを利用するユーザは、当該契約に対応するドメインを含むメールアドレスを利用するものとする。

【0045】

「認証システムのＵＲＩ」は、契約に対応付けて設定される認証システム６のＵＲＩである。契約者は、１以上の認証システム６を有してよく、当該契約者の契約ごとに、利用する認証システム６のＵＲＩが異なってもよい。

【0046】

「契約部門」は、契約の対象部門の一例であり、契約においてコンテナ配信サービスの利用が許可される所属範囲を示す。例えば、図４において、契約ＩＤ“001”の契約では、Ａ社の第一開発部にコンテナ配信サービスの利用が許可されている。また、契約ＩＤ“002”の契約では、部署の指定がなく、Ｂ社の全ての部署（すなわち全社）にコンテナ配信サービスの利用が許可されている。

【0047】

ここで、図４の契約ＩＤ“001”及び“004”のエントリに示すように、複数の契約において、同一のドメイン“a.jp”が設定されてもよく、この場合において、認証システム６のＵＲＩ及び契約部門（会社）のそれぞれは、互いに異なってもよい。また、図４の契約ＩＤ“003”及び“004”のエントリに示すように、複数の契約において、同一の認証システム６のＵＲＩ“ldap://ldap.c.jp:389/”及び同一の契約部門“Ｃ社）業務本部”が設定されてもよく、この場合において、ドメインは互いに異なってもよい。

【0048】

「契約期間」は、契約が有効である期間であり、契約の有効期限の一例である。「契約期間」は、契約の始期及び終期の一方又は双方を含んでよい。

【0049】

「リポジトリ」は、アクセスが許可される記憶領域に関する情報の一例であり、契約においてコンテナ配信サービスで利用が許可されるリポジトリ４を示す。例えば、「リポジトリ」には、コンテナ配信システム２が備えるリポジトリ４（リポジトリＸ、Ｙ、Ｚ）ごとに、各契約においてアクセス可能か否かが設定されてよい。図４の例では、アクセスが許可されるリポジトリ４には“True”（例えば“１”）が設定され、アクセスが拒否されるリポジトリ４には“False”（例えば“０”）が設定されてよい。

【0050】

図２の説明に戻り、契約管理部３３は、契約情報照会部３２から受信した照会要求に含まれるユーザの所属ドメインに対応する契約、例えば所属ドメインと一致する「ドメイン」を含む契約のエントリの情報を契約データＤＢ３４から所得してよい。そして、契約管理部３３は、例えば、契約の有無と、契約がある場合にはユーザの所属ドメインと対応付けられた１以上の契約情報の一覧とを含む照会結果を契約情報照会部３２に送信してよい。契約情報には、エントリの情報、一例として、以下のような契約ＩＤ、ドメイン、認証システム６のＵＲＩ、契約部門、及び、契約期間が含まれてよい。
・契約ＩＤ：契約00x
・ドメイン：bar.jp, foo.jp,…
・認証システム６のＵＲＩ：ldap://ldap.bar.jp:389
・契約部門：第一業務本部）第二開発部
・契約期間：2019/4/1-2021/3/31

【0051】

なお、照会結果には、複数の契約情報が含まれる場合がある。また、ユーザが複数の所属を有するケースにおいて、有効な契約の一覧中に２つ以上の認証システム６のＵＲＩが含まれ、且つ、これら全ての認証システム６に対応するドメイン（例えばメールアドレス）が同じである場合、契約管理部３３は、当該２つ以上の認証システム６のＵＲＩを含む契約情報を照会結果に含めてよい。

【0052】

契約情報照会部３２は、照会結果に基づき、認証システム６への問い合わせ要否を判定する（図３の処理Ｐ５）。

【0053】

例えば、契約情報照会部３２は、照会結果に基づき、ユーザに対して１つ以上有効な契約があるか否かを判定する（ステップＳ３）。

【0054】

有効な契約が１つも存在しない場合（ステップＳ３でＮＯ）、契約情報照会部３２は、アクセス制御部３１に契約がない旨を応答する。アクセス制御部３１は、ユーザ端末５にログイン拒否を応答し（ステップＳ４）、ログイン処理が終了する。有効な契約が１つも存在しない場合としては、例えば、照会結果において契約がないことが示されている場合、契約が１つ以上あるがこれら全ての契約の契約期間が満了している（現在日時が契約期間内にない）場合、等が挙げられる。

【0055】

一方、ユーザに対して１つ以上有効な契約がある場合（ステップＳ３でＹＥＳ）、契約情報照会部３２は、有効な契約に係る認証システム６のＵＲＩの情報、例えば“ldap://ldap.bar.jp:389”をアクセス制御部３１に送信する（図３の処理Ｐ６）。また、契約情報照会部３２は、有効な契約に係る契約部門の情報をアクセス制御部３１に送信してよい。

【0056】

アクセス制御部３１は、未認証の（未だ認証システム６の認証が行なわれていない）有効な契約情報があるか否かを判定する（ステップＳ５）。

【0057】

未認証の有効な契約情報がある場合（ステップＳ５でＹＥＳ）、アクセス制御部３１は、１つの有効な契約に対応する認証システム６のＵＲＩに対して、ユーザの認証要求を送信する（ステップＳ６；図３の処理Ｐ７）。認証要求には、例えば、ユーザのメールアドレス“[e-mail]”及びパスワード“p3rcli29_4”が含まれてよい。

【0058】

このように、権限管理サーバ３は、契約データＤＢ３４及びアクセス制御ＤＢ３５に基づき、契約情報の有効性（有効期限等）を判定することで、認証システム６への不要な認証要求を抑制できる。これにより、認証システム６への認証要求の頻度を低下させることができ、権限管理サーバ３及び認証システム６の処理負荷、並びに、権限管理サーバ３と認証システム６との間のネットワークの通信負荷等を低減させることができる。

【0059】

認証システム６は、受信した認証要求に基づきユーザの認証処理を行ない、認証結果を含む応答をアクセス制御部３１に送信する（図３の処理Ｐ８）。認証結果には、例えば、認証の可否、及び、現在認証システム６に登録されているユーザの所属“第一業務本部）第二開発部”が含まれてよい。

【0060】

アクセス制御部３１は、応答が認証可（ＯＫ）を示すか否かを判定する（ステップＳ７）。認証不可（ＮＧ）を示す場合（ステップＳ７でＮＯ）、処理がステップＳ５に移行し、アクセス制御部３１は、他の未認証の有効な契約情報があるか否かを判定する。

【0061】

このように、アクセス制御部３１は、ユーザに対して複数の有効な契約が存在し、複数の認証システム６のＵＲＩを取得した場合（契約ごとにＵＲＩが異なる場合）、取得した認証システム６のＵＲＩのそれぞれに対してユーザの認証要求を送信してよい。認証システム６のＵＲＩは、ユーザごと又は所属ごとに異なる可能性があるため、認証システム６ごとに認証要求を送信することで、複数の認証システム６に対応でき、ユーザの複数の所属に対応可能となる。

【0062】

応答が認証可（ＯＫ）を示す場合（ステップＳ７でＹＥＳ）、アクセス制御部３１は、後述するように、認証可の契約情報及び認証情報（ユーザ情報）をアクセス制御ＤＢ３５に記録し（ステップＳ８；図３の処理Ｐ９）、処理がステップＳ５に移行する。

【0063】

ステップＳ５において、未認証の有効な契約情報がない（例えば全ての契約情報について認証要求を送信した）場合（ステップＳ５でＮＯ）、アクセス制御部３１は、認証システム６から認証可の応答があるか否かを判定する（ステップＳ９；図３の処理Ｐ１０）。

【0064】

認証可の応答がない場合（ステップＳ９でＮＯ）、処理がステップＳ４に移行する。一方、認証可の応答がある場合（ステップＳ９でＹＥＳ）、アクセス制御部３１は、ユーザのログインを許可するか否かを判定する（ステップＳ１０）。

【0065】

例えば、アクセス制御部３１は、１つ以上の認証システム６から認証可の応答があった場合でも、応答に含まれる所属の情報と、契約情報照会部３２から取得した照会結果に含まれる１つ以上の契約部門とが一致しない場合、ログインを拒否すると判定してよい。ログインを拒否する場合（ステップＳ１０でＮＯ）、処理がステップＳ４に移行する。

【0066】

応答に含まれる所属の情報と、契約情報照会部３２から取得した照会結果に含まれる契約部門のうちの少なくとも１つとが一致し、アクセス制御部３１がログインを許可すると判定した場合（ステップＳ１０でＹＥＳ）、処理がステップＳ１１に移行する。

【0067】

ステップＳ１１では、アクセス制御部３１は、ユーザに対してトークン（例えば“8932eb6a8c9b001e5d”）を発行し（図３の処理Ｐ１１）、トークンをアクセス制御ＤＢ３５に格納して、ログイン処理が終了する。

【0068】

図５は、アクセス制御ＤＢ３５の一例を示す図である。図５に示すように、アクセス制御ＤＢ３５は、例示的に、「Ｎｏ．」、「メールアドレス」、「トークン」、「契約ＩＤ」、「ログイン認証」及び「認証システムが応答したユーザの所属」の項目を含んでよい。

【0069】

「Ｎｏ．」は、「メールアドレス」に応じたエントリを識別するための識別情報である。「メールアドレス」は、ログイン要求に含まれるメールアドレスであり、一実施形態では、ユーザを識別するための識別情報の一例である。

【0070】

「トークン」は、ステップＳ１１で発行されるトークンであり、証明情報の一例である。また、例えば、「トークン」は、認証システム６による認証結果に基づきユーザに発行されたアクセストークンの一例である。

【0071】

「契約ＩＤ」は、ステップＳ１０でログインが許可された契約を識別するための識別情報であり、契約データＤＢ３４のエントリに対応してよい。

【0072】

「ログイン認証」は、ユーザのログインの際のログイン認証において、ユーザが認証されたか否か、換言すれば、ユーザがアクセス権限を有しているか否かを示す情報である。例えば、「ログイン認証」には、ステップＳ１０において、ログインが許可された場合、「ＯＫ」（例えば“１”）が設定され、拒否された場合、「ＮＧ」（例えば“０”）が設定されてよい。

【0073】

「認証システムが応答したユーザの所属」は、後述するＤＬ処理において、アクセス制御部３１が認証システム６に問い合わせた結果に含まれる、ユーザの所属に関する情報である。なお、アクセス制御ＤＢ３５には、当該項目に加えて、ログイン処理のステップＳ６で認証システム６から取得した認証結果に含まれるユーザの所属が記録されてもよい。

【0074】

（ＤＬ処理）
図６は、権限管理サーバ３によるＤＬ処理の動作例を説明するためのフローチャートであり、図７は、権限管理サーバ３によるＤＬ処理の動作例を説明するためのシーケンス図である。

【0075】

図６に例示するように、権限管理サーバ３のアクセス制御部３１は、ユーザ端末５からコンテナ、例えばコンテナイメージ４０のＤＬ要求を受信する（ステップＳ２１；図７の処理Ｐ２１）。ＤＬ要求は、認証システム６による認証結果に基づきユーザに発行されたトークンを含むデータ取得要求の一例である。ＤＬ要求には、アクセス制御部３１から発行されたトークン、ＤＬ対象であるコンテナのＵＲＩ、及び、ＤＬ対象であるコンテナのタグが含まれてよい。なお、コンテナのタグは、コンテナのＵＲＩの一部として記述されてもよい（コンテナのＵＲＩに含まれてもよい）。以下の説明では、トークンが“8932eb6a8c9b001e5d”であり、コンテナのＵＲＩが、コンテナのタグ“20200401R01”を含む“https://re.gi.st/ry/container:20200401R01”であるものとする。

【0076】

アクセス制御部３１は、アクセス制御ＤＢ３５等からトークンに対応する契約情報を取得する（ステップＳ２２）。トークンに対応する契約情報が複数存在する場合、アクセス制御部３１は、トークンに対応する全ての契約情報を取得してよい。

【0077】

例えば、アクセス制御部３１は、アクセス制御ＤＢ３５から、トークン“8932eb6a8c9b001e5d”に対応するメールアドレス“[e-mail]”及び契約ＩＤ“契約00x”を取得してよい（図７の処理Ｐ２２）。

【0078】

また、アクセス制御部３１は、契約情報照会部３２に対して、契約情報の照会要求を送信する（図７の処理Ｐ２３）。当該照会要求には、メールアドレス“[e-mail]”から取得したユーザの所属ドメイン“bar.jp”、ＤＬ対象であるコンテナのＵＲＩ（及びタグ）“https://re.gi.st/ry/container:20200401R01”が含まれてよい。

【0079】

契約情報照会部３２は、アクセス制御部３１から受信した照会要求を契約管理部３３に送信（転送）する（図７の処理Ｐ２４）。

【0080】

契約管理部３３は、受信した照会要求と契約データＤＢ３４とに基づき、契約データＤＢ３４の照会結果を契約情報照会部３２に応答する（図７の処理Ｐ２５）。

【0081】

例えば、契約管理部３３は、契約情報照会部３２から受信した照会要求に含まれるユーザの所属ドメイン“bar.jp”に対応する契約、例えば所属ドメインと一致する「ドメイン」を含む契約のエントリの情報を契約データＤＢ３４から所得してよい。

【0082】

このとき、契約管理部３３は、契約データＤＢ３４から情報を取得するエントリを、受信した照会要求に含まれるコンテナのＵＲＩに対応するリポジトリ４が“True”に設定されたエントリに制限してよい。例えば、権限管理サーバ３は、１以上の契約情報について、アクセスが許可されるリポジトリ４がＤＬ対象のコンテナの格納先と一致しない場合、後述のように、ユーザの所属確認を行なわないと判定し、コンテナの配信を抑制してよい。

【0083】

そして、契約管理部３３は、例えば、ユーザの所属ドメイン“bar.jp”と対応付けられ、ＤＬ対象のコンテナへのアクセスが可能である１以上の契約情報の一覧を含む照会結果を契約情報照会部３２に送信してよい。契約情報には、エントリの情報、一例として、以下のような契約ＩＤ、認証システム６のＵＲＩ、契約部門、及び、契約期間が含まれてよい。
・契約ＩＤ：契約00x
・認証システム６のＵＲＩ：ldap://ldap.bar.jp:389
・契約部門：第一業務本部）第二開発部
・契約期間：2019/4/1-2021/3/31

【0084】

なお、契約データＤＢ３４から複数の契約情報が取得された場合、契約管理部３３は、当該複数の契約情報を照会結果に含めて、契約情報照会部３２に送信してよい。

【0085】

契約情報照会部３２は、照会結果に基づき、トークン及びＤＬ対象のコンテナの組に対して１つ以上有効な契約があるか否かを判定する（ステップＳ２３；図７の処理Ｐ２６）。

【0086】

有効な契約が１つも存在しない場合（ステップＳ２３でＮＯ）、契約情報照会部３２は、アクセス制御部３１に契約がない旨を応答する。アクセス制御部３１は、ユーザ端末５に対して、ログイン許可を取り消す旨を応答し、ログイン許可を取り消して（ステップＳ２４）、ＤＬ処理が終了する。ステップＳ２４では、アクセス制御部３１は、例えば、トークンの無効化を行なってよい。トークンの無効化の手法としては、例えば、ＤＬ要求内のメールアドレスに対応するアクセス制御ＤＢ３５のエントリに対する、トークンの削除、及び、ログイン認証へのＮＧの設定、の一方又は双方が含まれてもよい。

【0087】

なお、有効な契約が１つも存在しない場合としては、例えば、照会結果に契約情報が含まれない場合等が挙げられる。

【0088】

一方、ユーザに対して１つ以上有効な契約がある場合（ステップＳ２３でＹＥＳ）、契約情報照会部３２は、有効な契約に係る契約情報、例えば、認証システム６のＵＲＩ、及び、契約部門の情報をアクセス制御部３１に送信する（図７の処理Ｐ２７）。なお、契約部門の情報は、部門（部署）がない、換言すれば、全社が対象である場合がある。

【0089】

アクセス制御部３１は、契約情報照会部３２から受信した契約情報に基づき、ユーザの所属未確認、且つ、有効期限内である契約情報があるか否か、換言すれば、コンテナをＤＬ可能な契約情報があるか否かを判定する（ステップＳ２５；図７の処理Ｐ２８）。

【0090】

例えば、アクセス制御部３１は、ユーザの所属が未確認である（未だ認証システム６に所属を問い合わせていない）契約情報であって、契約期間が満了していない（現在日時が契約期間内にある）契約情報を特定してよい。

【0091】

一例として、アクセス制御部３１は、契約情報照会部３２から取得した契約情報を展開したメモリ上で、各契約情報のエントリにユーザの所属を確認済みであるか否かの情報、例えばフラグを付加することで、ユーザの所属が未確認か否かを判定してよい。

【0092】

なお、契約情報照会部３２から取得した契約情報について、契約期間が満了していない契約情報の特定は、ステップＳ２３において契約情報照会部３２により実行されてもよい。例えば、契約情報照会部３２は、ステップＳ２３において、図２のステップＳ３と同様に、契約が１つ以上あるがこれら全ての契約の契約期間が満了している（現在日時が契約期間内にない）場合は、有効な契約がないと判定してよい。

【0093】

ステップＳ２５において、ユーザの所属未確認、且つ、有効期限内である契約情報がない場合（ステップＳ２５でＮＯ）、処理がステップＳ２４に移行する。

【0094】

このように、権限管理サーバ３は、トークンに対応付けられた契約情報に含まれる有効期限が到来している場合、又は、トークンに対応付けられた契約情報が存在しない場合、ステップＳ２４に示すように、データの配信を抑制してよい。

【0095】

一方、ステップＳ２５において、ユーザの所属未確認、且つ、有効期限内である契約情報がある場合（ステップＳ２５でＹＥＳ）、アクセス制御部３１は、当該契約情報が全社契約の契約情報であるか否かを判定する（ステップＳ２６）。

【0096】

全社契約の契約情報ではない場合（ステップＳ２６でＮＯ）、アクセス制御部３１は、当該契約情報に対応する認証システム６のＵＲＩの各々に対して、ユーザの所属の問い合わせを送信する（ステップＳ２７；図７の処理Ｐ２９）。当該問い合わせには、例えば、アクセス制御ＤＢ３５から取得したユーザのメールアドレス、並びに、ユーザの所属を参照するための参照用のＩＤ（例えば“ref_admin”）及びパスワード（例えば“snt3x'49X0”）が含まれてよい。参照用のＩＤ及びパスワードは、例えば、認証システム６へのユーザの所属の問い合わせに利用可能な参照用アカウントであってよい。

【0097】

このように、権限管理サーバ３は、ＤＬ要求の受信に応じて、ステップＳ２３及びＳ２５において、アクセス制御部３１及び契約情報照会部３２により、以下の情報に基づきユーザの所属確認を行なうか否かを判定する。例えば、権限管理サーバ３は、トークンに対応付けられた１以上の契約情報であって契約期間及び契約部門を含む１以上の契約情報と、ＤＬ要求の対象となるデータとに基づき、所属確認を行なうか否かを判定する。一例として、ステップＳ２５でＹＥＳの場合、権限管理サーバ３は、１以上の契約情報について、有効期限が到来しておらず、且つ、対象部門が限定されている場合、ユーザの所属確認を行なうと判定してよい。

【0098】

以上のように、権限管理サーバ３は、契約データＤＢ３４及びアクセス制御ＤＢ３５に基づき、契約情報の有効性（有効期限等）を判定することで、認証システム６への不要な問い合わせを抑制できる。これにより、認証システム６への問い合わせ頻度を低下させることができ、権限管理サーバ３及び認証システム６の処理負荷、並びに、権限管理サーバ３と認証システム６との間のネットワークの通信負荷等を低減させることができる。

【0099】

認証システム６は、受信した問い合わせに基づき、ユーザの所属に関する所属情報を含む応答をアクセス制御部３１に送信する（図７の処理Ｐ３０）。例えば、認証システム６は、受信した問い合わせに含まれる参照用アカウントが有効である場合に、問い合わせに含まれるメールアドレスに対応する所属情報、例えば“第一業務本部)第二開発部”を取得し、当該所属情報を応答に含めてよい。

【0100】

アクセス制御部３１は、応答内のユーザの所属が契約情報内のユーザの所属（契約部門）と一致するか否かを判定する（ステップＳ２８）。一致しない場合（ステップＳ２８でＮＯ）、処理がステップＳ２５に移行する。

【0101】

応答内のユーザの所属が契約情報内のユーザの所属（契約部門）と一致する場合（ステップＳ２８でＹＥＳ）、アクセス制御部３１は、ユーザによるＤＬを許可する（ステップＳ２９）、換言すればデータをユーザに配信し、ＤＬ処理が終了する。例えば、ステップＳ２９において、アクセス制御部３１は、ＤＬ対象のコンテナが属するリポジトリ４に対する、ユーザ端末５によるコンテナのＤＬを許可してよい。

【0102】

このように、権限管理サーバ３は、ステップＳ２３及びＳ２５においてユーザの所属確認を行なうと判定した場合、１以上の契約情報に対応付けられた１以上の認証システム６のそれぞれにユーザの所属確認を要求して得られた所属情報に基づき、ＤＬ要求の対象となるデータをユーザに配信する。例えば、権限管理サーバ３は、所属情報と、少なくとも１つの契約情報に含まれる契約部門とが一致する場合、データをユーザに配信してよい。

【0103】

また、ステップＳ２６において、契約情報が全社契約の契約情報である場合（ステップＳ２６でＹＥＳ）、アクセス制御部３１は、認証システム６への問い合わせをスキップしてよい。この場合、処理がステップＳ２９に移行する。

【0104】

このように、アクセス制御部３１は、ユーザがＤＬを要求したコンテナ（配布データ）の配布対象が全社である場合、ユーザの所属情報の取得を不要と判断し、認証システム６へのアクセスを省略して、コンテナの配布を許可してよい。換言すれば、権限管理サーバ３は、１以上の契約情報について、有効期限が到来しておらず、且つ、対象部門が限定されていない場合、ユーザの所属確認を行なわないと判定し、１以上の認証システム６への所属確認の要求を抑止してデータをユーザに配信する。これにより、ＤＬ処理において認証システム６への問い合わせを行なう一実施形態における、認証システム６へのアクセス数の増加を抑制することができる。

【0105】

〔１－４〕ＤＬ処理における処理例
次に、ＤＬ処理における、ユーザの所属の変化に応じた権限管理サーバ３による処理例を説明する。

【0106】

（第１のパターン）
メールアドレス“[e-mail]”のユーザがＤＬ要求を行なった場合（図５のＮｏ．“１”参照）、契約ＩＤ“契約001”が有効である。契約ＩＤ“契約001”は、図４に示すように、全社契約ではないため、権限管理サーバ３は、当該契約ＩＤに対応する“ldap://ldap.a.jp:389”の認証システム６に所属確認を行なう。

【0107】

権限管理サーバ３は、所属確認により認証システム６から取得した所属情報と契約データＤＢ３４から取得した契約部門とがいずれも“Ａ社）第一開発部”（図４及び図５参照）であり両者が一致するため、ＤＬ要求を許可する。

【0108】

（第２のパターン）
メールアドレス“[e-mail]”のユーザがＤＬ要求を行なった場合（図５のＮｏ．“２”参照）、契約ＩＤ“契約002”が有効である。契約ＩＤ“契約002”は、図４に示すように、全社契約であるため、権限管理サーバ３は、認証システム６への所属確認を省略し、ＤＬ要求を許可する。

【0109】

（第３のパターン）
メールアドレス“[e-mail]”のユーザがＤＬ要求を行なった場合（図５のＮｏ．“３”参照）、契約ＩＤ“契約003”が有効である。契約ＩＤ“003”は、図４に示すように、全社契約ではないため、権限管理サーバ３は、“ldap://ldap.b.jp:389”の認証システム６に所属確認を行なう。

【0110】

権限管理サーバ３は、所属確認により認証システム６から取得した所属情報“Ｃ社）第二開発部”（図５参照）と契約データＤＢ３４から取得した契約部門“Ｃ社）業務本部”（図４参照）とが一致しないため、ＤＬ要求を拒否する。

【0111】

（第４のパターン）
メールアドレス“[e-mail]”のユーザがＤＬ要求を行なった場合（図５のＮｏ．“４”参照）、契約ＩＤ“契約001”及び“契約004”の２つの契約が有効であるため、権限管理サーバ３は、それぞれの契約について判定を行なう。

【0112】

例えば、契約ＩＤ“001”は、図４に示すように、全社契約ではないため、権限管理サーバ３は、“ldap://ldap.a.jp:389”の認証システム６に所属確認を行なう。この場合、権限管理サーバ３は、所属確認により認証システム６から取得した所属情報“Ａ社）第二開発部”（図５参照）と契約データＤＢ３４から取得した契約部門“Ａ社）第一開発部”（図４参照）とが一致しない。

【0113】

契約ＩＤ“004”は、図４に示すように、全社契約ではないため、権限管理サーバ３は、“ldap://ldap.c.jp:389”の認証システム６に所属確認を行なう。この場合、権限管理サーバ３は、所属確認により認証システム６から取得した所属情報と契約データＤＢ３４から取得した契約部門とがいずれも“Ｃ社）業務本部”（図４及び図５参照）であり両者が一致するため、ＤＬ要求を許可する。

【0114】

〔１－５〕ハードウェア構成例
上述したコンテナ配信システム２を実現する装置は、仮想サーバ（ＶＭ；Virtual Machine）であってもよいし、物理サーバであってもよい。また、コンテナ配信システム２の機能は、１台のコンピュータにより実現されてもよいし、２台以上のコンピュータにより実現されてもよい。さらに、コンテナ配信システム２の機能のうちの少なくとも一部は、クラウド環境により提供されるＨＷ（Hardware）リソース及びＮＷ（Network）リソースを用いて実現されてもよい。

【0115】

図８は、コンテナ配信システム２の機能を実現するコンピュータ１０のハードウェア（ＨＷ）構成例を示すブロック図である。コンテナ配信システム２の機能を実現するＨＷリソースとして、複数のコンピュータが用いられる場合は、各コンピュータが図８に例示するＨＷ構成を備えてよい。

【0116】

図８に示すように、コンピュータ１０は、ＨＷ構成として、例示的に、プロセッサ１０ａ、メモリ１０ｂ、記憶部１０ｃ、ＩＦ（Interface）部１０ｄ、Ｉ／Ｏ（Input / Output）部１０ｅ、及び読取部１０ｆを備えてよい。

【0117】

プロセッサ１０ａは、種々の制御や演算を行なう演算処理装置の一例である。プロセッサ１０ａは、コンピュータ１０内の各ブロックとバス１０ｉで相互に通信可能に接続されてよい。なお、プロセッサ１０ａは、複数のプロセッサを含むマルチプロセッサであってもよいし、複数のプロセッサコアを有するマルチコアプロセッサであってもよく、或いは、マルチコアプロセッサを複数有する構成であってもよい。

【0118】

プロセッサ１０ａとしては、例えば、ＣＰＵ、ＭＰＵ、ＧＰＵ、ＡＰＵ、ＤＳＰ、ＡＳＩＣ、ＦＰＧＡ等の集積回路（ＩＣ；Integrated Circuit）が挙げられる。なお、プロセッサ１０ａとして、これらの集積回路の２以上の組み合わせが用いられてもよい。ＣＰＵはCentral Processing Unitの略称であり、ＭＰＵはMicro Processing Unitの略称である。ＧＰＵはGraphics Processing Unitの略称であり、ＡＰＵはAccelerated Processing Unitの略称である。ＤＳＰはDigital Signal Processorの略称であり、ＡＳＩＣはApplication Specific ICの略称であり、ＦＰＧＡはField-Programmable Gate Arrayの略称である。

【0119】

メモリ１０ｂは、種々のデータやプログラム等の情報を格納するＨＷの一例である。メモリ１０ｂとしては、例えばＤＲＡＭ（Dynamic Random Access Memory）等の揮発性メモリ、及び、ＰＭ（Persistent Memory）等の不揮発性メモリ、の一方又は双方が挙げられる。

【0120】

記憶部１０ｃは、種々のデータやプログラム等の情報を格納するＨＷの一例である。記憶部１０ｃとしては、ＨＤＤ（Hard Disk Drive）等の磁気ディスク装置、ＳＳＤ（Solid State Drive）等の半導体ドライブ装置、不揮発性メモリ等の各種記憶装置が挙げられる。不揮発性メモリとしては、例えば、フラッシュメモリ、ＳＣＭ（Storage Class Memory）、ＲＯＭ（Read Only Memory）等が挙げられる。

【0121】

なお、図１に示す契約データＤＢ３４、アクセス制御ＤＢ３５、及び、リポジトリ４ａ～４ｃの情報は、メモリ１０ｂ及び記憶部１０ｃの一方又は双方が有する記憶領域に格納されてもよい。また、契約データＤＢ３４、アクセス制御ＤＢ３５、及び、リポジトリ４ａ～４ｃのそれぞれは、記憶部１０ｃとしての複数の記憶装置により実現されるディスクアレイ装置等のストレージ装置により実現されてもよい。

【0122】

また、記憶部１０ｃは、コンピュータ１０の各種機能の全部若しくは一部を実現するプログラム１０ｇ（配信制御プログラム）を格納してよい。例えば、コンテナ配信システム２（一例として権限管理サーバ３）のプロセッサ１０ａは、記憶部１０ｃに格納されたプログラム１０ｇをメモリ１０ｂに展開して実行することにより、図１に例示するアクセス制御部３１、契約情報照会部３２及び契約管理部３３としての機能を実現できる。

【0123】

ＩＦ部１０ｄは、コンテナ配信システム２と各ユーザ端末５との間のネットワーク、及び、コンテナ配信システム２と各認証システム６との間のネットワークの一方又は双方との間の接続及び通信の制御等を行なう通信ＩＦの一例である。例えば、ＩＦ部１０ｄは、イーサネット（登録商標）等のＬＡＮ、或いは、ＦＣ（Fibre Channel）等の光通信等に準拠したアダプタを含んでよい。当該アダプタは、無線及び有線の一方又は双方の通信方式に対応してよい。例えば、コンテナ配信システム２は、ＩＦ部１０ｄを介して、ユーザ端末５及び認証システム６の各々と相互に通信可能に接続されてよい。また、例えば、プログラム１０ｇは、当該通信ＩＦを介して、ネットワークからコンピュータ１０にダウンロードされ、記憶部１０ｃに格納されてもよい。

【0124】

Ｉ／Ｏ部１０ｅは、入力装置、及び、出力装置、の一方又は双方を含んでよい。入力装置としては、例えば、キーボード、マウス、タッチパネル等が挙げられる。出力装置としては、例えば、モニタ、プロジェクタ、プリンタ等が挙げられる。

【0125】

読取部１０ｆは、記録媒体１０ｈに記録されたデータやプログラムの情報を読み出すリーダの一例である。読取部１０ｆは、記録媒体１０ｈを接続可能又は挿入可能な接続端子又は装置を含んでよい。読取部１０ｆとしては、例えば、ＵＳＢ（Universal Serial Bus）等に準拠したアダプタ、記録ディスクへのアクセスを行なうドライブ装置、ＳＤカード等のフラッシュメモリへのアクセスを行なうカードリーダ等が挙げられる。なお、記録媒体１０ｈにはプログラム１０ｇが格納されてもよく、読取部１０ｆが記録媒体１０ｈからプログラム１０ｇを読み出して記憶部１０ｃに格納してもよい。

【0126】

記録媒体１０ｈとしては、例示的に、磁気／光ディスクやフラッシュメモリ等の非一時的なコンピュータ読取可能な記録媒体が挙げられる。磁気／光ディスクとしては、例示的に、フレキシブルディスク、ＣＤ（Compact Disc）、ＤＶＤ（Digital Versatile Disc）、ブルーレイディスク、ＨＶＤ（Holographic Versatile Disc）等が挙げられる。フラッシュメモリとしては、例示的に、ＵＳＢメモリやＳＤカード等の半導体メモリが挙げられる。

【0127】

上述したコンピュータ１０のＨＷ構成は例示である。従って、コンピュータ１０内でのＨＷの増減（例えば任意のブロックの追加や削除）、分割、任意の組み合わせでの統合、又は、バスの追加若しくは削除等は適宜行なわれてもよい。例えば、コンテナ配信システム２において、Ｉ／Ｏ部１０ｅ及び読取部１０ｆの少なくとも一方は、省略されてもよい。

【0128】

なお、ユーザ端末５、及び、認証システム６のそれぞれは、上述したコンピュータ１０と同様のＨＷ構成により実現されてもよい。

【0129】

〔２〕その他
上述した一実施形態に係る技術は、以下のように変形、変更して実施することができる。

【0130】

例えば、図１に示すシステム１において、リポジトリ４、ユーザ端末５及び認証システム６のそれぞれの数が３であるものとしたが、これに限定されるものではなく、それぞれ、２以下、又は、４以上であってもよい。

【0131】

また、図１に示す権限管理サーバ３が備えるアクセス制御部３１、契約情報照会部３２及び契約管理部３３は、任意の組み合わせで併合してもよく、それぞれ分割してもよい。さらに、図１に示すコンテナ配信システム２が記憶する契約データＤＢ３４及びアクセス制御ＤＢ３５は、併合してもよく、それぞれ分割してもよい。

【0132】

さらに、図１に示すコンテナ配信システム２は、複数の装置がネットワークを介して互いに連携することにより、各処理機能を実現する構成であってもよい。例えば、図１に示す複数の機能ブロックのそれぞれは、Ｗｅｂサーバ、アプリケーションサーバ、ＤＢサーバ等のサーバに分散して配置されてよい。この場合、Ｗｅｂサーバ、アプリケーションサーバ及びＤＢサーバが、ネットワークを介して互いに連携することにより、コンテナ配信システム２としての各処理機能を実現してもよい。

【0133】

また、認証システム６は、コンテナ配信サービスの提供者により、会社、組織、部署等の契約者ごとに用意されるシステムであってもよい。

【0134】

〔３〕付記
以上の実施形態に関し、さらに以下の付記を開示する。

【0135】

（付記１）
ユーザの認証を行なう認証システムによる認証結果に基づき前記ユーザに発行されたアクセストークンを含むデータ取得要求の受信に応じて、前記アクセストークンに対応付けられた１以上の契約情報であって契約の有効期限及び契約の対象部門の情報を含む前記１以上の契約情報と、前記データ取得要求の対象となるデータとに基づき、前記ユーザの所属確認を行なうか否かを判定し、
前記ユーザの所属確認を行なうと判定した場合、前記１以上の契約情報に対応付けられた１以上の認証システムのそれぞれに前記ユーザの所属確認を要求して得られた所属情報に基づき、前記データ取得要求の対象となる前記データを前記ユーザに配信する、制御部を備える
情報処理装置。

【0136】

（付記２）
前記制御部は、前記判定する処理において、前記１以上の契約情報について、前記有効期限が到来しておらず、且つ、前記対象部門が限定されている場合、前記ユーザの所属確認を行なうと判定する、
付記１に記載の情報処理装置。

【0137】

（付記３）
前記制御部は、
前記判定する処理において、前記１以上の契約情報について、前記有効期限が到来しておらず、且つ、前記対象部門が限定されていない場合、前記ユーザの所属確認を行なわないと判定し、
前記配信する処理において、前記１以上の認証システムへの前記所属確認の要求を抑止して前記データを前記ユーザに配信する、
付記２に記載の情報処理装置。

【0138】

（付記４）
前記制御部は、前記配信する処理において、前記所属情報と、少なくとも１つの前記契約情報に含まれる前記対象部門とが一致する場合、前記データを前記ユーザに配信する、
付記１～付記３のいずれか１項に記載の情報処理装置。

【0139】

（付記５）
前記制御部は、前記判定する処理において、前記アクセストークンに対応付けられた前記契約情報に含まれる前記有効期限が到来している場合、又は、前記アクセストークンに対応付けられた契約情報が存在しない場合、前記データの配信を抑制する、
付記１～付記４のいずれか１項に記載の情報処理装置。

【0140】

（付記６）
前記契約情報は、アクセスが許可される記憶領域に関する情報を含み、
前記制御部は、前記判定する処理において、前記１以上の契約情報について、前記記憶領域が前記データの格納先と一致しない場合、前記ユーザの所属確認を行なわないと判定し、前記データの配信を抑制する、
付記１～付記５のいずれか１項に記載の情報処理装置。

【0141】

（付記７）
ユーザの認証を行なう認証システムによる認証結果に基づき前記ユーザに発行されたアクセストークンを含むデータ取得要求の受信に応じて、前記アクセストークンに対応付けられた１以上の契約情報であって契約の有効期限及び契約の対象部門の情報を含む前記１以上の契約情報と、前記データ取得要求の対象となるデータとに基づき、前記ユーザの所属確認を行なうか否かを判定し、
前記ユーザの所属確認を行なうと判定した場合、前記１以上の契約情報に対応付けられた１以上の認証システムのそれぞれに前記ユーザの所属確認を要求して得られた所属情報に基づき、前記データ取得要求の対象となる前記データを前記ユーザに配信する、処理をコンピュータに実行させる、配信制御プログラム。

【0142】

（付記８）
前記判定する処理は、前記１以上の契約情報について、前記有効期限が到来しておらず、且つ、前記対象部門が限定されている場合、前記ユーザの所属確認を行なうと判定する処理を含む、
付記７に記載の配信制御プログラム。

【0143】

（付記９）
前記判定する処理は、前記１以上の契約情報について、前記有効期限が到来しておらず、且つ、前記対象部門が限定されていない場合、前記ユーザの所属確認を行なわないと判定する処理を含み、
前記配信する処理は、前記１以上の認証システムへの前記所属確認の要求を抑止して前記データを前記ユーザに配信する処理を含む、
付記８に記載の配信制御プログラム。

【0144】

（付記１０）
前記配信する処理は、前記所属情報と、少なくとも１つの前記契約情報に含まれる前記対象部門とが一致する場合、前記データを前記ユーザに配信する処理を含む、
付記７～付記９のいずれか１項に記載の配信制御プログラム。

【0145】

（付記１１）
前記判定する処理は、前記アクセストークンに対応付けられた前記契約情報に含まれる前記有効期限が到来している場合、又は、前記アクセストークンに対応付けられた契約情報が存在しない場合、前記データの配信を抑制する処理を含む、
付記７～付記１０のいずれか１項に記載の配信制御プログラム。

【0146】

（付記１２）
前記契約情報は、アクセスが許可される記憶領域に関する情報を含み、
前記判定する処理は、前記１以上の契約情報について、前記記憶領域が前記データの格納先と一致しない場合、前記ユーザの所属確認を行なわないと判定し、前記データの配信を抑制する処理を含む、
付記７～付記１１のいずれか１項に記載の配信制御プログラム。

【0147】

（付記１３）
複数の認証システムと、情報処理装置と、を備え、
前記情報処理装置は、
ユーザの認証を行なう認証システムによる認証結果に基づき前記ユーザに発行されたアクセストークンを含むデータ取得要求の受信に応じて、前記アクセストークンに対応付けられた１以上の契約情報であって契約の有効期限及び契約の対象部門の情報を含む前記１以上の契約情報と、前記データ取得要求の対象となるデータとに基づき、前記ユーザの所属確認を行なうか否かを判定し、
前記ユーザの所属確認を行なうと判定した場合、前記１以上の契約情報に対応付けられた１以上の認証システムのそれぞれに前記ユーザの所属確認を要求して得られた所属情報に基づき、前記データ取得要求の対象となる前記データを前記ユーザに配信する、制御部を備える
情報処理システム。

【0148】

（付記１４）
前記制御部は、前記判定する処理において、前記１以上の契約情報について、前記有効期限が到来しておらず、且つ、前記対象部門が限定されている場合、前記ユーザの所属確認を行なうと判定する、
付記１３に記載の情報処理システム。

【0149】

（付記１５）
前記制御部は、
前記判定する処理において、前記１以上の契約情報について、前記有効期限が到来しておらず、且つ、前記対象部門が限定されていない場合、前記ユーザの所属確認を行なわないと判定し、
前記配信する処理において、前記１以上の認証システムへの前記所属確認の要求を抑止して前記データを前記ユーザに配信する、
付記１４に記載の情報処理システム。

【0150】

（付記１６）
前記制御部は、前記配信する処理において、前記所属情報と、少なくとも１つの前記契約情報に含まれる前記対象部門とが一致する場合、前記データを前記ユーザに配信する、
付記１３～付記１５のいずれか１項に記載の情報処理システム。

【0151】

（付記１７）
前記制御部は、前記判定する処理において、前記アクセストークンに対応付けられた前記契約情報に含まれる前記有効期限が到来している場合、又は、前記アクセストークンに対応付けられた契約情報が存在しない場合、前記データの配信を抑制する、
付記１３～付記１６のいずれか１項に記載の情報処理システム。

【0152】

（付記１８）
前記契約情報は、アクセスが許可される記憶領域に関する情報を含み、
前記制御部は、前記判定する処理において、前記１以上の契約情報について、前記記憶領域が前記データの格納先と一致しない場合、前記ユーザの所属確認を行なわないと判定し、前記データの配信を抑制する、
付記１３～付記１７のいずれか１項に記載の情報処理システム。

【符号の説明】

【0153】

１ システム
２ コンテナ配信システム
３ 権限管理サーバ
３１ アクセス制御部
３２ 契約情報照会部
３３ 契約管理部
３４ 契約データＤＢ
３５ アクセス制御ＤＢ
４、４ａ～４ｃ リポジトリ
４０、４０ａ～４０ｃ コンテナイメージ
５、５ａ～５ｃ ユーザ端末
６、６ａ～６ｃ 認証システム

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】