(57)【要約】【課題】  複数のサービスを連携させて付加価値を創造するために、ＯＡｕｔｈと呼ばれる標準プロトコルがある。ＯＡｕｔｈによれば、アプリケーションはユーザーの明示的な認可を得ることでリソースにアクセスできるようになる。また近年、一人で複数の端末を所有するケースが増えている。ここで従来の方法では、ユーザーが所有する端末ごとに個別に認可操作を行う必要が発生し、利便性が低下するという問題があった。【解決手段】  テナントに紐付く端末にて少なくとも一度でも認可操作が行われたという事実を担保にそのテナントに所属するユーザーの認可操作を省略する。【選択図】  図９
2016085641.tif 000002
【特許請求の範囲】
【請求項１】
端末と、ネットワークを介してサービスを提供するサーバーと、前記サービスを利用するクライアントとを含む権限移譲システムであって、
前記端末にて表示される認証画面を介してユーザーから入力された認証情報を基に、前記ユーザーが正規のユーザーであるか否かを判断する認証手段と、
前記認証手段により正規のユーザーであると判断された前記ユーザーが前記端末にて表示される認可画面を介し、前記サービスにおける前記ユーザーの権限を前記端末に備えられた前記クライアントへ移譲することを許可する認可操作を行った場合、前記ユーザーの権限が前記クライアントへ移譲されたことを示す認可情報を発行する発行手段と、
前記クライアントが前記サービスの利用を要求する際に送信する前記認可情報を基に、前記クライアントが前記ユーザーの権限で前記サービスを利用することを認可する認可手段と、
前記認証手段により正規なユーザーであると判断された前記ユーザーが所属するテナントに対し、前記テナントに所属する他のユーザーが前記端末に備えられた前記クライアントを用いて前記サービスを利用する際、前記認可操作を行わずとも前記クライアントに対応する認可情報が発行されるように設定するか否かを前記ユーザーに確認する確認手段と、を有し、
前記認可手段は、前記テナントに所属する他のユーザーが前記端末に備えられた前記クライアントを用いて前記サービスを利用する際、前記認可操作を行わずとも前記認可情報が発行されるよう前記ユーザーが前記テナントに対し設定を行ったことに応じて、他のユーザーが前記端末に備えられた前記クライアントを用いて前記サービスを利用する際に前記認可操作を行うことなく前記サービスを利用することを認可することを特徴とする権限移譲システム。
【請求項２】
前記認可手段は、前記テナントに所属する他のユーザーが前記端末に備えられた前記クライアントを用いて前記サービスを利用する際、前記認可操作を行わずとも前記認可情報が発行されるよう前記ユーザーが前記テナントに対し設定を行っており、かつ前記他のユーザーが前記端末とは別の端末に備えられたクライアントを用いて前記サービスを利用する際、前記認可操作を行うことで前記別の端末に備えられたクライアントに対応する認可情報が前記発行手段により既に発行されていることに応じて、他のユーザーが前記端末を利用し前記サービスを利用する際に前記認可操作を行うことなく前記サービスを利用することを認可することを特徴とする請求項１に記載の権限移譲システム。
【請求項３】
前記ユーザーが利用する端末の種別が、共有設定が設定された共有設定端末であるか否かを判断する判断手段を有し、
前記確認手段は、前記判断手段により前記端末が共有設定端末であると判断された場合は、前記認証手段により正規なユーザーであると判断された前記ユーザーが所属するテナントに対し、前記テナントに所属する他のユーザーが前記端末に備えられた前記クライアントを用いて前記サービスを利用する際に前記認可操作を行わずとも前記クライアントに対応する認可情報が発行されるように設定するか否かを前記ユーザーに確認することを特徴とする請求項１または２に記載の権限移譲システム。
【請求項４】
前記確認手段は、前記端末が共有設定端末ではないと判断された場合は、前記認証手段により正規なユーザーであると判断された前記ユーザーに対し、前記別の端末に備えられたクライアントを用いて前記サービスを利用する際に前記認可操作を行わずとも前記クライアントに対応する前記認可情報が発行されるように設定するか否かを前記ユーザーに確認することを特徴とする請求項３に記載の権限移譲システム。
【請求項５】
前記確認手段により前記テナントに所属する他のユーザーが前記認可操作を行わずとも前記認可情報が発行されるよう前記テナントに対し設定が行われたことが確認されたことに応じて、前記端末に備えられた前記クライアントを識別するクライアント識別子と、前記前記認証手段により正規なユーザーであると判断された前記ユーザーの識別子を基に特定した前記テナントの識別子とを関連づけて管理する管理手段を有し、
前記認可手段は、前記他のユーザーから入力された認証情報を基に前記他のユーザーの識別子を特定し、特定された他のユーザーの識別子に紐付く前記テナントの識別子に対して前記他のユーザーが利用する前記端末の識別子が紐付いていることに応じ、前記他のユーザーが前記端末を利用し前記サービスを利用する際に前記認可操作を行うことなく前記サービスを利用することを認可することを特徴とする請求項１乃至４の何れか１項に記載の権限移譲システム。
【請求項６】
端末と、ネットワークを介してサービスを提供するサーバーと、前記サービスを利用するクライアントとを含む権限移譲システムにて実行される方法であって、
前記端末にて表示される認証画面を介してユーザーから入力された認証情報を基に、前記ユーザーが正規のユーザーであるか否かを判断する認証ステップと、
前記認証ステップにおいて正規のユーザーであると判断された前記ユーザーが前記端末にて表示される認可画面を介し、前記サービスにおける前記ユーザーの権限を前記端末に備えられた前記クライアントへ移譲することを許可する認可操作を行った場合、前記ユーザーの権限が前記クライアントへ移譲されたことを示す認可情報を発行する発行ステップと、
前記クライアントが前記サービスの利用を要求する際に送信する前記認可情報を基に、前記クライアントが前記ユーザーの権限で前記サービスを利用することを認可する認可ステップと、
前記認証ステップにおいて正規なユーザーであると判断された前記ユーザーが所属するテナントに対し、前記テナントに所属する他のユーザーが前記端末に備えられた前記クライアントを用いて前記サービスを利用する際、前記認可操作を行わずとも前記クライアントに対応する認可情報が発行されるように設定するか否かを前記ユーザーに確認する確認ステップと、を含み、
前記認可ステップにおいては、前記テナントに所属する他のユーザーが前記端末に備えられた前記クライアントを用いて前記サービスを利用する際、前記認可操作を行わずとも前記認可情報が発行されるよう前記ユーザーが前記テナントに対し設定を行ったことに応じて、他のユーザーが前記端末に備えられた前記クライアントを用いて前記サービスを利用する際に前記認可操作を行うことなく前記サービスを利用することを認可することを特徴とする方法。
【請求項７】
前記認可ステップにおいては、前記テナントに所属する他のユーザーが前記端末に備えられた前記クライアントを用いて前記サービスを利用する際、前記認可操作を行わずとも前記認可情報が発行されるよう前記ユーザーが前記テナントに対し設定を行っており、かつ前記他のユーザーが前記端末とは別の端末に備えられたクライアントを用いて前記サービスを利用する際、前記認可操作を行うことで前記別の端末に備えられたクライアントに対応する認可情報が前記発行ステップにおいて既に発行されていることに応じて、他のユーザーが前記端末を利用し前記サービスを利用する際に前記認可操作を行うことなく前記サービスを利用することを認可することを特徴とする請求項６に記載の方法。
【請求項８】
前記ユーザーが利用する端末の種別が、共有設定が設定された共有設定端末であるか否かを判断する判断ステップを含み、
前記確認ステップにおいては、前記判断ステップにおいて前記端末が共有設定端末であると判断された場合は、前記認証ステップにおいて正規なユーザーであると判断された前記ユーザーが所属するテナントに対し、前記テナントに所属する他のユーザーが前記端末に備えられた前記クライアントを用いて前記サービスを利用する際に前記認可操作を行わずとも前記クライアントに対応する認可情報が発行されるように設定するか否かを前記ユーザーに確認することを特徴とする請求項６または７に記載の方法。
【請求項９】
前記確認ステップにおいては、前記端末が共有設定端末ではないと判断された場合は、前記認証ステップにおいて正規なユーザーであると判断された前記ユーザーに対し、前記別の端末に備えられたクライアントを用いて前記サービスを利用する際に前記認可操作を行わずとも前記クライアントに対応する前記認可情報が発行されるように設定するか否かを前記ユーザーに確認することを特徴とする請求項８に記載の方法。
【請求項１０】
前記確認ステップにおいて前記テナントに所属する他のユーザーが前記認可操作を行わずとも前記認可情報が発行されるよう前記テナントに対し設定が行われたことが確認されたことに応じて、前記端末に備えられた前記クライアントを識別するクライアント識別子と、前記前記認証手段により正規なユーザーであると判断された前記ユーザーの識別子を基に特定した前記テナントの識別子とを関連づけて管理する管理ステップを含み、
前記認可ステップにおいては、前記他のユーザーから入力された認証情報を基に前記他のユーザーの識別子を特定し、特定された他のユーザーの識別子に紐付く前記テナントの識別子に対して前記他のユーザーが利用する前記端末の識別子が紐付いていることに応じ、前記他のユーザーが前記端末を利用し前記サービスを利用する際に前記認可操作を行うことなく前記サービスを利用することを認可することを特徴とする請求項６乃至９の何れか１項に記載の方法。
【請求項１１】
端末と、ネットワークを介してサービスを提供するサーバーと、前記サービスを利用するクライアントとを含む権限移譲システムにて実行されるプログラムであって、
前記端末にて表示される認証画面を介してユーザーから入力された認証情報を基に、前記ユーザーが正規のユーザーであるか否かを判断する認証ステップと、
前記認証ステップにおいて正規のユーザーであると判断された前記ユーザーが前記端末にて表示される認可画面を介し、前記サービスにおける前記ユーザーの権限を前記端末に備えられた前記クライアントへ移譲することを許可する認可操作を行った場合、前記ユーザーの権限が前記クライアントへ移譲されたことを示す認可情報を発行する発行ステップと、
前記クライアントが前記サービスの利用を要求する際に送信する前記認可情報を基に、前記クライアントが前記ユーザーの権限で前記サービスを利用することを認可する認可ステップと、
前記認証ステップにおいて正規なユーザーであると判断された前記ユーザーが所属するテナントに対し、前記テナントに所属する他のユーザーが前記端末に備えられた前記クライアントを用いて前記サービスを利用する際、前記認可操作を行わずとも前記クライアントに対応する認可情報が発行されるように設定するか否かを前記ユーザーに確認する確認ステップと、を含み、
前記認可ステップにおいては、前記テナントに所属する他のユーザーが前記端末に備えられた前記クライアントを用いて前記サービスを利用する際、前記認可操作を行わずとも前記認可情報が発行されるよう前記ユーザーが前記テナントに対し設定を行ったことに応じて、他のユーザーが前記端末に備えられた前記クライアントを用いて前記サービスを利用する際に前記認可操作を行うことなく前記サービスを利用することを認可することを特徴とするプログラム。
【請求項１２】
前記認可ステップにおいては、前記テナントに所属する他のユーザーが前記端末に備えられた前記クライアントを用いて前記サービスを利用する際、前記認可操作を行わずとも前記認可情報が発行されるよう前記ユーザーが前記テナントに対し設定を行っており、かつ前記他のユーザーが前記端末とは別の端末に備えられたクライアントを用いて前記サービスを利用する際、前記認可操作を行うことで前記別の端末に備えられたクライアントに対応する認可情報が前記発行ステップにおいて既に発行されていることに応じて、他のユーザーが前記端末を利用し前記サービスを利用する際に前記認可操作を行うことなく前記サービスを利用することを認可することを特徴とする請求項１１に記載のプログラム。
【請求項１３】
前記ユーザーが利用する端末の種別が、共有設定が設定された共有設定端末であるか否かを判断する判断ステップを含み、
前記確認ステップにおいては、前記判断ステップにおいて前記端末が共有設定端末であると判断された場合は、前記認証ステップにおいて正規なユーザーであると判断された前記ユーザーが所属するテナントに対し、前記テナントに所属する他のユーザーが前記端末に備えられた前記クライアントを用いて前記サービスを利用する際に前記認可操作を行わずとも前記クライアントに対応する認可情報が発行されるように設定するか否かを前記ユーザーに確認することを特徴とする請求項１１または１２に記載のプログラム。
【請求項１４】
前記確認ステップにおいては、前記端末が共有設定端末ではないと判断された場合は、前記認証ステップにおいて正規なユーザーであると判断された前記ユーザーに対し、前記別の端末に備えられたクライアントを用いて前記サービスを利用する際に前記認可操作を行わずとも前記クライアントに対応する前記認可情報が発行されるように設定するか否かを前記ユーザーに確認することを特徴とする請求項１３に記載のプログラム。
【請求項１５】
前記確認ステップにおいて前記テナントに所属する他のユーザーが前記認可操作を行わずとも前記認可情報が発行されるよう前記テナントに対し設定が行われたことが確認されたことに応じて、前記端末に備えられた前記クライアントを識別するクライアント識別子と、前記前記認証手段により正規なユーザーであると判断された前記ユーザーの識別子を基に特定した前記テナントの識別子とを関連づけて管理する管理ステップを含み、
前記認可ステップにおいては、前記他のユーザーから入力された認証情報を基に前記他のユーザーの識別子を特定し、特定された他のユーザーの識別子に紐付く前記テナントの識別子に対して前記他のユーザーが利用する前記端末の識別子が紐付いていることに応じ、前記他のユーザーが前記端末を利用し前記サービスを利用する際に前記認可操作を行うことなく前記サービスを利用することを認可することを特徴とする請求項１１乃至１４の何れか１項に記載のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
サービスにおけるユーザーの権限をクライアントへ移譲する認可処理に関する権限移譲システム、権限移譲システムにて実行される方法、およびそのプログラム。
【背景技術】
【０００２】
クラウドが一般化するに伴い複数のサービスを連携させる機会はますます増加している。サービスとは、インターネット等のネットワークを介して接続されたサーバーが提供する機能、換言すれば、ウェブアプリケーションのことを指す。サービスが連携することで通常提供されるサービスに付加価値を加えた新たなサービスをユーザーに提供することができる。
【０００３】
しかし、サービスが連携することによって課題が生まれる。それは、ユーザーが望んだ以上の情報が複数のサービス間で送受信される虞があり、ユーザーデータや個人情報に関する機密情報の流出が発生するという課題である。また、様々なサービス間でサービス連携が実現される可能性があるが、ユーザーが認識したサービス以外がユーザーデータや個人情報を操作できてはいけない。しかし、上述した付加価値の提供の観点から見るとサービス連携の仕組みは必要であり、サービス提供者としてはその仕組みが容易に実装できる方が好ましい。
【０００４】
このような状況において、ＯＡｕｔｈと呼ばれる認可の連携を実現させるための標準プロトコルが策定されている。ＯＡｕｔｈによれば、例えば、ある端末内のアプリケーションからクラウドサービスが管理するデータにアクセスする場合、アプリケーションはユーザーの明示的な認可を得ることで認証処理を省略してアクセスすることが可能になる。
【０００５】
ユーザーが認可すると、アプリケーションへユーザーの権限が移譲され、アプリケーションはサービスへのアクセスが認められる。そのアクセスが認められたことを証明する認可情報（以下、アクセストークン）をアプリケーションは受け取り、以降のアクセスはユーザーの認証操作を必要とせずに、そのアクセストークンを用いてサービスとの通信を実現する。以下では、アクセストークンの発行のため、あるサービスにおけるユーザーの権限を第三者に移譲することを認可するためにユーザーが行う操作を認可操作と称する。特許文献１においては、既にＯＡｕｔｈを利用したアクセストークンの発行制御に関する技術が開示されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２０１３−１４５５０５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
近年、スマートフォンの普及により、一人で複数の端末を所有するケースが増えている。そのため、ユーザーが所有する複数の端末の内、どの端末を使っているかを意識せずにシームレスに使いたいという要望が発生する可能性がある。
【０００８】
例えば、複数の端末の夫々に対し、クラウドサービスが管理するデータにアクセスするアプリケーションがインストールされていたとする。アプリケーションがデータにアクセスするためにはアクセストークンが必要であり、またユーザーの認可操作が必要となる。従来の方法では、ユーザーが所有する端末ごとに個別に認可操作を行う必要が発生する。これは、どの端末では認可操作が済んでいて、どの端末では認可操作が済んでいないかをユーザーが意識することになりシームレスとは言えない。
【０００９】
この課題を解決する本願発明の１つの目的は、テナントに紐付く端末にて少なくとも一度でも認可操作が行われたという事実を担保にそのテナントに所属するユーザーの認可操作を省略することで上述した課題を解決する点にある。
【課題を解決するための手段】
【００１０】
本発明の一実施形に係る権限移譲システムは、端末と、ネットワークを介してサービスを提供するサーバーと、前記サービスを利用するクライアントとを含む権限移譲システムであって、前記端末にて表示される認証画面を介してユーザーから入力された認証情報を基に、前記ユーザーが正規のユーザーであるか否かを判断する認証手段と、前記認証手段により正規のユーザーであると判断された前記ユーザーが前記端末にて表示される認可画面を介し、前記サービスにおける前記ユーザーの権限を前記端末に備えられた前記クライアントへ移譲することを許可する認可操作を行った場合、前記ユーザーの権限が前記クライアントへ移譲されたことを示す認可情報を発行する発行手段と、前記クライアントが前記サービスの利用を要求する際に送信する前記認可情報を基に、前記クライアントが前記ユーザーの権限で前記サービスを利用することを認可する認可手段と、前記認証手段により正規なユーザーであると判断された前記ユーザーが所属するテナントに対し、前記テナントに所属する他のユーザーが前記端末に備えられた前記クライアントを用いて前記サービスを利用する際、前記認可操作を行わずとも前記クライアントに対応する認可情報が発行されるように設定するか否かを前記ユーザーに確認する確認手段と、を有し、前記認可手段は、前記テナントに所属する他のユーザーが前記端末に備えられた前記クライアントを用いて前記サービスを利用する際、前記認可操作を行わずとも前記認可情報が発行されるよう前記ユーザーが前記テナントに対し設定を行ったことに応じて、他のユーザーが前記端末に備えられた前記クライアントを用いて前記サービスを利用する際に前記認可操作を行うことなく前記サービスを利用することを認可することを特徴とする。
【発明の効果】
【００１１】
テナントに紐付く端末にて少なくとも一度でも認可操作が行われたという事実を担保にそのテナントに所属するユーザーの認可操作を省略することが可能になる。
【図面の簡単な説明】
【００１２】
【図１】本実施の第１の形態に係るネットワーク構成を示す図である。
【図２】本実施の第１の形態に係るサーバーコンピューターの構成図である。
【図３】本実施の第１の形態に係るモジュール構成図である。
【図４】本実施の第１の形態に係るクライアント識別子発行のフローである。
【図５】本実施の第１の形態に係るリソースに対するアクセスフローのフローである。
【図６】本実施の第１の形態に係る認可操作要否の判断フローである。
【図７】本実施の第１の形態に係るクライアント識別子紐付け確認のフローである。
【図８】本実施の第１の形態に係る画面の表示例である。
【図９】本実施の第１の形態に係るユーザー操作の模式図である。
【図１０】本実施の第２の形態に係るモジュール構成図である。
【図１１】本実施の第２の形態に係る認可操作要否の判断フローである。
【図１２】本実施の第２の形態に係る紐付け確認の要否設定のフローである。
【図１３】本実施の第２の形態に係る画面の表示例である。
【図１４】本実施の第３の形態に係るモジュール構成図である。
【図１５】本実施の第３の形態に係るクライアント種別の初期登録フローである。
【図１６】本実施の第３の形態に係るクライアント種別の変更フローである。
【図１７】本実施の第３の形態に係る画面の表示例である。
【発明を実施するための形態】
【００１３】
［実施例１］
以下、本発明を実施するための形態について図面を用いて説明する。本実施の形態に係る権限移譲システムは、図１に示すような構成のネットワーク上に実現される。
【００１４】
１００は、Ｗｉｄｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ（ＷＡＮ１００）であり、本発明ではＷｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂ（ＷＷＷ）システムが構築されている。１０１は各構成要素を接続するＬｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ（ＬＡＮ１０１）である。１０２はユーザー端末が接続するネットワークである。ネットワーク１０２はＬＡＮでもよい。またユーザー端末がモバイル端末であれば、ネットワーク１０２はワイヤレスネットワークでもよい。
【００１５】
１５１はユーザーの認証、およびアクセストークンの発行を行う認証・認可サーバー、１５２はサービスを提供するリソースサーバーである。また１５３はデータベースサーバーである。また１９１、１９２および１９３はユーザーが操作するユーザー端末である。例えば、クラウドサービスが管理するデータにアクセスするためのアクセストークンを用いるユーザー端末のアプリケーションは、ユーザーに許可された権限の範囲でリソースサーバーのデータにアクセスできるようになる。アクセストークンは認可情報の一形態であり、英数字の羅列により表現される。
【００１６】
認証・認可サーバー１５１、リソースサーバー１５２、データベースサーバー１５３はそれぞれＷＡＮネットワーク１００およびＬＡＮ１０１を介して接続されている。また同様にユーザー端末１９１、１９２および１９３はＷＡＮネットワーク１００およびネットワーク１０２を介して接続されている。なお認証・認可サーバー１５１、リソースサーバー１５２、データベースサーバー１５３はそれぞれ個別のＬＡＮ上に構成されていてもよいし同一のＬＡＮ上に構成されていてもよい。また同一のＰＣまたはサーバーコンピューター上に構成されていてもよい。またユーザー端末１９１、１９２および１９３の代わりに不図示のＰＣがＬＡＮ１０１を介してＷＡＮ１００に接続されていてもよく、あるいは不図示の印刷装置やモバイル端末であってもよい。
【００１７】
図２は本実施の形態に係る、認証・認可サーバー１５１のサーバーコンピューターの構成を示す図である。またリソースサーバー１５２、データベースサーバー１５３のサーバーコンピューターの構成やユーザー端末１９１、１９２および１９３の構成も同様である。尚、図２に示されるハードウェアブロック図は一般的な情報処理装置のハードウェアブロック図に相当するものとし、本実施形態のサーバーコンピューターおよびユーザー端末には一般的な情報処理装置のハードウェア構成を適用できる。
【００１８】
図２において、ＣＰＵ２０１は、ＲＯＭ２０３のプログラム用ＲＯＭに記憶された、或いはハードディスク２１１からＲＡＭ２０２にロードされたＯＳやアプリケーション等のプログラムを実行する。ここでＯＳとはコンピュータ上で稼動するオペレーティングシステムの略語であり、以下オペレーティングシステムのことをＯＳと呼ぶ。後述する各フローチャートの処理はこのプログラムの実行により実現できる。ＲＡＭ２０２は、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。キーボードコントローラ（ＫＢＣ）２０５は、キーボード（ＫＢ）２０９や不図示のポインティングデバイスからのキー入力を制御する。ＣＲＴコントローラ（ＣＲＴＣ）２０６は、ＣＲＴディスプレイ２１０の表示を制御する。ディスクコントローラ（ＤＫＣ）２０７は各種データを記憶する外部メモリ２１１はハードディスクやフラッシュディスク等におけるデータアクセスを制御する。ＮＣ２１２はネットワークに接続されて、ネットワークに接続された他の機器との通信制御処理を実行する。
【００１９】
尚、後述の全ての説明においては、特に断りのない限り実行のハード上の主体はＣＰＵ２０１であり、ソフトウェア上の主体はハードディスク（ＨＤ）２１１にインストールされたアプリケーションプログラムである。
【００２０】
図３は本実施の形態に係る、認証・認可サーバー１５１およびユーザー端末１９１のモジュール構成を示す図である。図３（Ａ）は認証・認可サーバー１５１、図３（Ｂ）はユーザー端末１９１のモジュール構成をそれぞれ示す。認証・認可サーバー１５１はクライアント識別子管理モジュール３０１、認証モジュール３０２、クライアント識別子紐付け管理モジュール３０３、認可モジュール３０４を持つ。さらに認証・認可サーバー１５１は認可操作要否判断モジュール３０５を持つ。またユーザー端末１９１はクライアントモジュール３５１、クライアント紐付け要求モジュール３５２を持つ。なおユーザー端末１９２、１９３はユーザー端末１９１同様に、図３（Ｂ）の構成を取るものとする。
【００２１】
図４（Ａ）は本実施の形態に係る、ユーザー端末１９１におけるクライアント識別子発行要求フローである。本フローはユーザーがクライアントモジュール３５１を起動することで開始される。
【００２２】
ステップＳ４０１でクライアントモジュール３５１は、ユーザーの起動指示を受けて起動する。ステップＳ４０２でクライアントモジュール３５１は、認証・認可サーバー１５１にクライアント識別子発行を依頼する。ここでクライアント識別子発行の依頼には、事前にクライアントモジュール３５１に割り当てられたクライアント証明書が必要となる。ステップＳ４０３でクライアントモジュール３５１は、認証・認可サーバー１５１に発行されたクライアント識別子を受信し、フローを終了する。
【００２３】
図４（Ｂ）は本実施の形態に係る、認証・認可サーバー１５１におけるクライアント識別子発行フローである。本フローはクライアントモジュール３５１からのクライアント識別子発行依頼を受信することで開始される。ステップＳ４１１でクライアント識別子管理モジュール３０１は、クライアントモジュール３５１からのクライアント識別子発行依頼を受信する。ステップＳ４１２でクライアント識別子管理モジュール３０１は、受信したクライアント識別子発行依頼に含まれるクライアント証明書を取り出す。
【００２４】
ステップＳ４１３でクライアント識別子管理モジュール３０１は、ステップＳ４１２で取り出したクライアント証明書が妥当な証明書か判断する。ここでクライアント証明書が妥当と判断された場合はステップＳ４１４に遷移する。またクライアント証明書が妥当でないと判断された場合はステップＳ４５０に遷移する。
【００２５】
ステップＳ４１４でクライアント識別子管理モジュール３０１は、クライアントモジュール３５１からのクライアント識別子発行依頼に対し、クライアント識別子を発行する。なおここで発行されたクライアント識別子はクライアント識別子管理モジュール３０１が記憶する。表１はクライアント識別子テーブルであり、クライアント識別子管理モジュール３０１が記憶している発行済みクライアント識別子の様子を示す。ここではユーザー端末１９１のクライアントモジュール３５１に対しクライアント識別子ＡｐｐＡｍ００１が、ユーザー端末１９２のクライアントモジュール３５１に対しクライアント識別子ＡｐｐＡｍ００２が、それぞれ発行されているとする。またユーザー端末１９３のクライアントモジュール３５１に対しクライアント識別子ＡｐｐＡｍ００３が発行されているとする。夫々の端末におけるクライアントモジュール３５１に対して、それぞれ異なるクライアント識別子が発行される。
【００２６】
【表１】
2016085641.tif 000003
【００２７】
ステップＳ４１５でクライアント識別子管理モジュール３０１は、ステップＳ４１４で発行したクライアント識別子をクライアントモジュール３５１に返し、フローを終了する。ステップＳ４５０でクライアント識別子管理モジュール３０１は、クライアント識別子を発行できない旨をクライアントモジュール３５１に返し、フローを終了する。
【００２８】
図５（Ａ）は本実施の形態に係る、ユーザー端末１９１における、リソースサーバー１５２のリソースに対するアクセスフローである。本フローはクライアントモジュール３５１がユーザーから、リソースサーバー１５２のリソースに対するアクセス指示を受信することで開始される。ステップＳ１００１でクライアントモジュール３５１は、ユーザーからリソースサーバー１５２のリソースに対するアクセス指示を受け付ける。ステップＳ１００２でクライアントモジュール３５１は、リソースサーバーへのアクセスに必要なアクセストークンを保持しているか判断する。ここでアクセストークンを保持していると判断された場合はステップＳ１００５に遷移する。またアクセストークンを保持していないと判断された場合はステップＳ１００３に遷移する。
【００２９】
ステップＳ１００３でクライアントモジュール３５１は、認証・認可サーバー１５１に対し、アクセストークンを要求する。ここでアクセストークンの要求は、ユーザー端末を操作するユーザーの情報およびステップＳ４０３で受信したクライアント識別子を含む。ステップＳ１００４でクライアントモジュール３５１は、ステップＳ１００３の応答としてアクセストークンが発行されたか判断する。ここでアクセストークンが発行されたと判断された場合はステップＳ１００５に遷移する。またアクセストークンが発行されなかったと判断された場合はステップＳ１０５０に遷移する。
【００３０】
ステップＳ１００５でクライアントモジュール３５１は、ステップＳ１００３の応答として得られたアクセストークンを保持するとともに、そのアクセストークンをリソースサーバー１５２へ送信することでリソースにアクセスを行い、フローを終了する。ステップＳ１０５０でクライアントモジュール３５１は、アクセストークンが得られなかったためリソースサーバー１５２にアクセスできない旨をユーザーに通知し、フローを終了する。
【００３１】
図５（Ｂ）は本実施の形態に係る、認証・認可サーバー１５１における、アクセストークンの発行フローである。本フローは認証・認可サーバー１５１の認可モジュール３０４がクライアントモジュール３５１から、アクセストークンの要求を受信することで開始される。ステップＳ１１０１で認可モジュール３０４は、クライアントモジュール３５１からアクセストークンの要求を受け付ける。ここで受け付けたアクセストークンの要求は、ユーザーの情報およびクライアント識別子を含む。
【００３２】
ステップＳ１１０２で認可モジュール３０４は、クライアントモジュール３５１を操作しているユーザーがログイン済みか判断する。ここでユーザーがログイン済みと判断された場合はステップＳ１１０４に遷移する。またログイン済みでないと判断された場合はステップＳ１１０３に遷移する。ステップＳ１１０３で認証モジュール３０２は、クライアントモジュール３５１に指示し、図８（Ａ）に示されるようなログイン画面１４０１を表示させることでユーザーにログインを促す。ユーザーは認証情報を認証画面であるログイン画面１４０１を介して入力し、認証モジュール３０２は入力された認証情報を基にユーザーが正規のユーザーであるか否かを判断する。
【００３３】
ステップＳ１１０４で認可操作要否判断モジュール３０５は、ステップＳ１１０１で受け付けたアクセストークンの要求に対し、ユーザーによる認可操作が必要か判断する。ステップＳ１１０５で認可操作要否判断モジュール３０５は、ステップＳ１１０４の判断の結果に従い、後続の処理を決定する。ステップＳ１１０４で認可操作が必要と判断された場合はステップＳ１１１０に遷移する。またステップＳ１１０４で認可操作が不要と判断された場合はステップＳ１１０６に遷移する。
【００３４】
ステップＳ１１０６で認可モジュール３０４は、アクセストークンを発行し、ステップＳ１１０１で受け付けたアクセストークンの要求に含まれるクライアント識別子とユーザー情報に紐付けて記憶する。また発行したアクセストークンをクライアントモジュール３５１に返し、フローを終了する。ステップＳ１１１０で認可モジュール３０４は、クライアントモジュール３５１に指示し、図８（Ｃ）に示すような認可確認画面１４０３を表示させ、ユーザーの確認を求める。
【００３５】
ステップＳ１１１１で認可モジュール３０４は、ステップＳ１１１０に対応してユーザーの認可を得られたか判断する。ここで認可を得られたと判断された場合はステップＳ１１０６に遷移する。また認可を得られなかったと判断された場合はステップＳ１１５０に遷移する。ユーザーが認可を行うために図８（Ｃ）にて許可を選択するための操作を認可操作と称し、ユーザーにより認可操作が行われたことでアクセストークンの発行が行われる。なお、図８（Ｃ）におけるユーザーの権限とは、ユーザーに紐付くデータへのアクセス権限となる。実際は、権限には他の権限も存在し、ＡＰＩ（ａｐｐｌｉｃａｔｉｏｎ  ｐｒｏｇｒａｍ  ｉｎｔｅｒｆａｃｅ）の使用権限もその内の１つである。ステップＳ１１５０で認可モジュール３０４は、アクセストークンを発行できない旨をクライアントモジュール３５１に通知し、フローを終了する。
【００３６】
図６は本実施の形態に係る、認証・認可サーバー１５１における認可操作要否の判断フローである。なおこのフローは図５（Ｂ）のステップＳ１１０４の詳細フローである。ステップＳ１２０１で認可操作要否判断モジュール３０５は、ステップＳ１１０１で受け付けたアクセストークンの要求に含まれるユーザーの認証情報を用いて、ユーザーが所属するテナントを取得する。テナントを取得するには、表２に示すようなユーザー管理テーブルを参照する必要がある。なお、本実施例では認証情報とユーザーを識別するためのユーザー識別子は同一である形態を説明するが、別であっても良い。ここで例えばユーザーがＵｓｅｒ  Ｘであればユーザー識別子はＵｓｅｒ  Ｘであり、そのユーザー識別子に関連付くテナント識別子はＴｅｎａｎｔ  Ｔと判断される。結果、ユーザーの所属テナントはＴｅｎａｎｔ  Ｔと特定される。
【００３７】
【表２】
2016085641.tif 000004
【００３８】
ステップＳ１２０２で認可操作要否判断モジュール３０５は、ステップＳ１２０１で取得したテナントに紐付けられたクライアント識別子の一覧を取得する。クライアント識別子を取得するには、表３に示されるような、クライアント識別子紐付けテーブルを参照する。ここで、例えばテナントがＴｅｎａｎｔ  Ｔであれば、紐付けられたクライアント識別子はＡｐｐＡｍ００１とＡｐｐＡｍ００２であると判断される。
【００３９】
【表３】
2016085641.tif 000005
【００４０】
ステップＳ１２０３で認可操作要否判断モジュール３０５は、ステップＳ１１０１で受け付けたアクセストークンの要求に含まれるクライアント識別子を取得する。ステップＳ１２０４で認可操作要否判断モジュール３０５は、ステップＳ１２０３で取得したクライアント識別子が、ステップＳ１２０２で取得したクライアント識別子の一覧に含まれるか判断する。ここでクライアント識別子が一覧に含まれている場合は、クライアントがテナントに紐付け済みとして、ステップＳ１２０５に遷移する。また一覧に含まれていない場合は、クライアント識別子がテナントに紐付けられていないとしてステップＳ１２１０に遷移する。
【００４１】
ステップＳ１２０５で認可操作要否判断モジュール３０５は、ステップＳ１２０２で取得したクライアント識別子の一覧のいずれかに対し、ユーザーのアクセストークンが発行済みか判断する。アクセストークンが発行済みであればステップＳ１２０６に遷移する。また発行済みでなければステップＳ１２１０に遷移する。ここでは表４に示されるようなアクセストークンテーブルを参照し、一覧に含まれるクライアント識別子に対するユーザーのトークンが存在しているかを確認する。例えばユーザーがＵｓｅｒ  Ｘで、クライアント識別子の一覧にはＡｐｐＡｍ００１とＡｐｐＡｍ００２が含まれるとする。このとき表４から、ＡｐｐＡｍ００１に対してＵｓｅｒ  Ｘのアクセストークンが存在していると判断される。なお、ステップＳ１２０５を行わず、端末に備えられたクライアントがテナントに紐付いていることを確認したことに応じて認可操作を省略してよいと判断する形態であっても良い。
【００４２】
【表４】
2016085641.tif 000006
【００４３】
ステップＳ１２０６で認可操作要否判断モジュール３０５は、認可操作を省略してアクセストークンを発行してよいと判断し、フローを終了する。なおここでの判断の結果は、図５（Ｂ）のステップＳ１１０５で使用される。なお、ここで言う認可操作の省略方法には幾つか種類がある。例えば、図８（ｃ）に示す画面を表示させない方法が考えられ、この場合ユーザーは認可操作を意識して行うことなく処理が進む。ステップＳ１２１０で認可操作要否判断モジュール３０５は、アクセストークンの発行のためには認可操作を省略できないと判断し、フローを終了する。なおここでの判断の結果は、図５（Ｂ）のステップＳ１１０５で使用される。
【００４４】
図７（Ａ）は本実施の形態に係る、認証・認可サーバー１５１における、クライアント識別子紐付け要否判断のフローである。本フローは認証・認可サーバー１５１が、クライアントモジュール３５１からユーザー情報を含むアクセスを受信することで開始される。例えば、図５（Ｂ）のステップＳ１１０３におけるユーザーログイン後に本フローを実行してもよい。
【００４５】
ステップＳ７０１でクライアント識別子紐付け管理モジュール３０３は、クライアントモジュール３５１からのアクセスを受け付ける。ここで受け付けたアクセスには、ユーザーの情報およびクライアント識別子を含む。ステップＳ７０２でクライアント識別子紐付け管理モジュール３０３は、ステップＳ７０１で受け付けたアクセスに含まれるユーザーの情報およびクライアント識別子から、クライアント識別子が、ユーザーが所属するテナントに紐付け済みかを判断する。ここで紐付け済みと判断された場合は、クライアントに対し、テナントとクライアント識別子の紐付けの確認を行わずにフローを終了する。また紐付け済みでないと判断された場合はステップＳ７０３に遷移する。ここでユーザーが所属するテナントは表２のユーザー管理テーブルから、クライアントが紐付けられたテナントは表３のクライアント識別子紐付けテーブルから、それぞれ判断する。
【００４６】
ステップＳ７０３でクライアント識別子紐付け管理モジュール３０３は、ステップＳ７０１で受け付けたアクセスに含まれるユーザーが、クライアント識別子をテナントに紐付ける権限を持つか判断する。ここでは、ユーザーがテナントの管理者である場合に、クライアント識別子を紐付ける権限を持つこととする。またこの判断には、表２のユーザー管理テーブルを用いて、ユーザーの権限を判断することとする。ユーザーがテナントにクライアント識別子を紐付ける権限を持つと判断された場合はステップＳ７０４に遷移する。また権限がないと判断された場合は、クライアントに対し、テナントとクライアント識別子の紐付けの確認を行わずにフローを終了する。
【００４７】
ステップＳ７０４でクライアント識別子紐付け管理モジュール３０３は、クライアントモジュール３５１に対してクライアント識別子紐付け確認を要求し、クライアント側で図８（Ｂ）に示すようなクライアント紐付け確認画面１４０２を表示するよう促す。またクライアント識別子紐付け確認の要求が完了するとフローを終了する。
【００４８】
図７（Ｂ）は本実施の形態に係る、ユーザー端末１９１における、クライアント識別子紐付け確認のフローである。このフローは、図７（Ａ）のステップＳ７０４のクライアント識別子紐付け確認の要求を、ユーザー端末１９１が認証・認可サーバー１５１から受け付けることで開始される。ステップＳ８０１でクライアント紐付け要求モジュール３５２は、認証・認可サーバー１５１からの要求に従い、図８（Ｂ）に示すようなクライアント紐付け確認画面１４０２を表示する。また画面を表示することで、ユーザーが所属するテナントに、クライアント識別子を紐付けるか、ユーザーに確認を行う。
【００４９】
ステップＳ８０２でクライアント紐付け要求モジュール３５２は、ステップＳ８０１の確認に対応して、ユーザーにクライアント識別子の紐付けをする指示があったかを判断する。ここで指示があったと判断された場合はステップＳ８０３に遷移する。また指示がなかったと判断された場合はクライアント識別子の紐付け要求を行わずにフローを終了する。ステップＳ８０３でクライアント紐付け要求モジュール３５２は、認証・認可サーバー１５１にクライアント識別子紐付け要求を行う。ここでクライアント識別子紐付け要求は、ユーザー端末を操作するユーザーが所属するテナントおよびステップＳ４０３で受信したクライアント識別子を含む。クライアント識別子紐付け要求が完了するとフローを終了する。
【００５０】
図７（Ｃ）は本実施の形態に係る、認証・認可サーバー１５１における、クライアント識別子の紐付けフローである。本フローは認証・認可サーバー１５１がユーザー端末１９１からクライアント識別子紐付け要求を受信したことで開始される。ステップＳ９０１でクライアント識別子紐付け管理モジュール３０３は、クライアント紐付け要求モジュール３５２からクライアント識別子紐付け要求を受け付ける。ここで受け付けたクライアント識別子紐付け要求は、ユーザーの情報およびクライアント識別子を含む。
【００５１】
ステップＳ９０２でクライアント識別子紐付け管理モジュール３０３は、ステップＳ９０１で受け付けた要求に含まれるクライアント識別子を、クライアントからの要求に従ってクライアント識別子紐付けテーブルに記憶する。例えばクライアントから、ユーザーが所属するテナントを指定された場合は、クライアント識別子を、指定されたテナントと紐付けて記憶する。紐付けの記憶が完了するとフローを終了する。
【００５２】
図８は本実施の形態に係る、画面の表示例である。図８（Ａ）はユーザーがログインするときに操作するログイン画面１４０１の例である。また図８（Ｂ）はユーザーがクライアントモジュールを、ユーザーが所属するテナントに紐付ける際の確認を行うクライアント紐付け確認画面１４０２の例である。また図８（Ｃ）はユーザーがクライアントモジュールを認可しアクセストークンの発行を許可する認可確認画面１４０３の例であり、認可画面とも称する。
【００５３】
図９は本実施の形態に係る、クライアント識別子の紐付けおよび認可操作を模式的に表した図である。図９（Ａ）は、テナントの管理者であるＡｄｍｉｎｉｓｔｒａｔｏｒ  Ｙが、ユーザー端末１９１および１９２を、テナント管理者が所属するＴｅｎａｎｔ  Ｔに対して紐付けを行っている様子を示す。
【００５４】
図９（Ｂ）はテナントの管理者であるＡｄｍｉｎｉｓｔｒａｔｏｒ  Ｙが、リソースサーバー１５２の機能を利用するために、認証・認可サーバー１５１にてアクセストークンを発行するための認可操作を行っている様子を示す。ここでＡｄｍｉｎｉｓｔｒａｔｏｒ  Ｙは、ユーザー端末１９１に対してアクセストークンを発行するためには認可操作が必要（図中の、Ａｄｍｉｎｉｓｔｒａｔｏｒ  Ｙからユーザー端末１９１に向かう実線）である。しかしユーザー端末１９１で認可操作を行いアクセストークンを発行することで、ユーザー端末１９２でアクセストークンを発行する際には認可操作は省略可能（図中の、Ａｄｍｉｎｉｓｔｒａｔｏｒ  Ｙからユーザー端末１９２に向かう点線）である。これは図９（Ａ）の操作で、ユーザー端末１９１および１９２が、ともにＴｅｎａｎｔ  Ｔに紐付いていて、かつ、Ａｄｍｉｎｉｓｔｒａｔｏｒ  Ｙがユーザー端末１９１でアクセストークンを発行した実績があるためである。このようにＡｄｍｉｎｉｓｔｒａｔｏｒ  Ｙは、２台目の端末で認可操作を省略することができ、利便性が向上する。
【００５５】
図９（Ｃ）はテナントの一般ユーザーであるＵｓｅｒ  Ｘが、リソースサーバー１５２の機能を利用するために、認証・認可サーバー１５１にてアクセストークンを発行するための認可操作を行っている様子を示す。ここでＵｓｅｒ  Ｘは、ユーザー端末１９１に対してアクセストークンを発行するためには認可操作が必要（図中の、Ｕｓｅｒ  Ｘからユーザー端末１９１に向かう実線）である。しかしユーザー端末１９１で認可操作を行いアクセストークンを発行することで、ユーザー端末１９２でアクセストークンを発行する際には認可操作は省略可能（図中の、Ｕｓｅｒ  Ｘからユーザー端末１９２に向かう点線）である。これは図９（Ａ）のＡｄｍｉｎｉｓｔｒａｔｏｒ  Ｙの操作で、ユーザー端末１９１および１９２が、ともにＴｅｎａｎｔ  Ｔに紐付いていて、かつ、Ｕｓｅｒ  Ｘがユーザー端末１９１でアクセストークンを発行した実績があるためである。このようにＵｓｅｒ  Ｘは、テナントにクライアント識別子を紐付ける操作を行うことなく、２台目の端末で認可操作を省略することができ、Ａｄｍｉｎｉｓｔｒａｔｏｒ  Ｙと比較して更に利便性が向上する。
【００５６】
本実施の形態によれば、ユーザーが所属するテナントに紐付けられたクライアント識別子のいずれかでアクセストークンを発行しているかが確認される。そしてそれらの内でアクセストークンを発行していないクライアント識別子に対しても、認可確認を省略してアクセストークンを発行できる。さらに、テナントの管理者が事前にクライアント識別子を自身が所属するテナントに紐付けておくことで、管理者以外の他のユーザーはクライアント識別子をテナントに紐付ける操作をする必要が無くなる。さらに、ユーザーは事前に紐付けが済んだ端末では認可操作を省略でき利便性が向上する。
【００５７】
［実施例２］
次に、本発明を実施するための第２の形態について図面を用いて説明する。なお第１の実施の形態と共通の部分については説明を省略し、以下では差異部分について説明する。第１の実施の形態においてはクライアント識別子をテナントに紐付けたが、第２の実施の形態においては、ユーザーに紐付けるクライアント識別子も扱う方式について説明する。クライアント識別子をテナントとユーザーのどちらに紐付けるかはクライアント種別で判断するものとするが、ここでは各クライアント識別子のクライアント種別は事前になんらかの手段で決定されているものとする。
【００５８】
クライアント種別が個別設定端末となっている端末は、クライアントがユーザーに紐付けられる端末であり、後述する通り、個別設定端末間で認可操作を省略できるものとする。またクライアント種別が共有設定端末となっている端末は、クライアントがテナントに紐付けられる端末であり、後述する通り、共有設定端末間で認可操作を省略できるものとする。更に共有設定端末は、個別設定端末で認可済みの場合も認可操作を省略できるものとする。認可操作の省略可否の判断フローは図１１で後述する。
【００５９】
図１０は本実施の第２の形態に係る、認証・認可サーバー１５１およびユーザー端末１９１のモジュール構成を示す図である。図１０（Ａ）は認証・認可サーバー１５１、図１０（Ｂ）はユーザー端末１９１のモジュール構成をそれぞれ示す。認証・認可サーバー１５１はクライアント識別子管理モジュール３０１、認証モジュール３０２、認可モジュール３０４を持つ。さらに認証・認可サーバー１５１は第２の認可操作要否判断モジュール３０６および第２のクライアント識別子紐付け管理モジュール３０７を持つ。またユーザー端末１９１はクライアントモジュール３５１、クライアント紐付け要求モジュール３５２、第２のクライアント紐付け要求モジュール３５３を持つ。なおユーザー端末１９２、１９３はユーザー端末１９１同様に、図１０（Ｂ）の構成を取るものとする。また本実施の形態において、ユーザー端末１９１、１９２は共有設定端末であり、ユーザー端末１９３は個別設定端末であるとしている。
【００６０】
本実施の第２の形態において、クライアント識別子発行要求フローは図４（Ａ）と、クライアント識別子発行フローは図４（Ｂ）と、それぞれ同様のフローを取れるものとする。また本実施の第２の形態において、ユーザー端末からリソースへのアクセスフローは図５（Ａ）と、アクセストークンの発行フローは図５（Ｂ）と、それぞれ同様のフローを取れるものとする。
【００６１】
図１１は本実施の第２の形態における、認証・認可サーバー１５１における、認可操作要否の判断フローである。なおこのフローは図５（Ｂ）のステップＳ１１０４の詳細フローである。ステップＳ２００１で第２の認可操作要否判断モジュール３０６は、ステップＳ１１０１で受け付けたアクセストークンの要求に含まれるユーザーの情報を用いて、ユーザーが所属するテナントを取得する。テナントを取得するには、表２に示すようなユーザー管理テーブルを参照する。ここで例えばユーザーがＵｓｅｒ  Ｘであれば、所属テナントはＴｅｎａｎｔ  Ｔと判断される。
【００６２】
ステップＳ２００２で第２の認可操作要否判断モジュール３０６は、ステップＳ２００１で取得したテナントに紐付けられたクライアント識別子の一覧を取得する。クライアント識別子を取得するには、表３に示されるような、クライアント識別子紐付けテーブルを参照する。ここで例えばテナントがＴｅｎａｎｔ  Ｔであれば、紐付けられたクライアント識別子はＡｐｐＡｍ００１とＡｐｐＡｍ００２であると判断される。
【００６３】
ステップＳ２００３で第２の認可操作要否判断モジュール３０６は、ステップＳ１１０１で受け付けたアクセストークンの要求に含まれるユーザーの情報を用いて、ユーザーに紐付けられたクライアント識別子の一覧を取得する。クライアント識別子を取得するには、表５に示されるような、第２のクライアント識別子紐付けテーブルを参照する。ここで例えばユーザーがＵｓｅｒ  Ｘであれば、紐付けられたクライアント識別子はＡｐｐＡｍ００３であると判断される。
【００６４】
【表５】
2016085641.tif 000007
【００６５】
ステップＳ２００４で第２の認可操作要否判断モジュール３０６は、ステップＳ１１０１で受け付けたアクセストークンの要求に含まれるクライアント識別子を用いて、クライアント識別子に割り当てられたクライアント種別を取得する。クライアント種別を取得するには、表６に示されるような、第２のクライアント識別子テーブルを参照する。なお表６では共有設定端末のクライアント種別をｔｅｎａｎｔと、個別設定端末のクライアント種別をｕｓｅｒと、それぞれ表現している。
【００６６】
【表６】
2016085641.tif 000008
【００６７】
ここで例えばＡｐｐＡｍ００１およびＡｐｐＡｍ００２のクライアント種別は共有設定端末であり、ＡｐｐＡｍ００３のクライアント種別は個別設定端末である。ステップＳ２００５で第２の認可操作要否判断モジュール３０６は、ステップＳ２００４で取得したクライアント種別が個別設定端末だったか共有設定端末だったか判断する。個別設定端末と判断された場合はステップＳ２０１０に、共有設定端末と判断された場合はステップＳ２０２０に、それぞれ遷移する。
【００６８】
ステップＳ２０１０で第２の認可操作要否判断モジュール３０６は、ステップＳ１１０１で受け付けたアクセストークンの要求に含まれるクライアント識別子が、ステップＳ２００３で取得したクライアント識別子一覧に含まれるか判断する。ここでクライアント識別子が一覧に含まれていた場合、アクセストークンの要求を行ったクライアント識別子がユーザーに紐付いていると判断し、ステップＳ２０１１に遷移する。またここでクライアント識別子が一覧に含まれていない場合、アクセストークンの要求を行ったクライアント識別子がユーザーに紐付いていないと判断し、ステップＳ２０５０に遷移する。
【００６９】
ステップＳ２０１１で第２の認可操作要否判断モジュール３０６は、ステップＳ２００３で取得したクライアント識別子一覧に含まれるクライアント識別子のいずれかに対して、ユーザーのアクセストークンが発行済みか判断する。アクセストークンが発行済みであればステップＳ２０３０に遷移する。また発行済みでなければステップＳ２０５０に遷移する。ここでは表４に示されるようなアクセストークンテーブルを参照し、一覧に含まれるクライアント識別子に対するユーザーのトークンが存在しているかを確認する。たとえばユーザーがＵｓｅｒ  Ｘで、クライアント識別子の一覧にはＡｐｐＡｍ００３が含まれるとする。このとき表４から、Ｕｓｅｒ  Ｘのアクセストークンが存在していないと判断される。
【００７０】
ステップＳ２０２０で第２の認可操作要否判断モジュール３０６は、ステップＳ１１０１で受け付けたアクセストークンの要求に含まれるクライアント識別子が、ステップＳ２００２で取得したクライアント識別子一覧に含まれるか判断する。ここでクライアント識別子が一覧に含まれていた場合、アクセストークンの要求を行ったクライアント識別子がユーザーの所属するテナントに紐付いていると判断し、ステップＳ２０２１に遷移する。クライアント識別子が一覧に含まれていない場合、アクセストークンの要求を行ったクライアント識別子がユーザーの所属するテナントに紐付いていないと判断し、ステップＳ２０６０に遷移する。
【００７１】
ステップＳ２０２１で第２の認可操作要否判断モジュール３０６は、ステップＳ２００２で取得したクライアント識別子一覧に含まれるクライアント識別子のいずれかに対して、ユーザーのアクセストークンが発行済みか判断する。アクセストークンが発行済みであればステップＳ２０３０に遷移する。また発行済みでなければステップＳ２０１１に遷移することで、ユーザーに紐付けられたクライアント識別子に対するアクセストークンの発行を確認する。ここでは表４に示されるようなアクセストークンテーブルを参照し、一覧に含まれるクライアント識別子に対するユーザーのトークンが存在しているかを確認する。たとえばユーザーがＵｓｅｒ  Ｘで、クライアント識別子の一覧にはＡｐｐＡｍ００１およびＡｐｐＡｍ００２が含まれるとする。このとき表４から、ＡｐｐＡｍ００１に対してＵｓｅｒ  Ｘのアクセストークンが存在していると判断される。
【００７２】
ステップＳ２０３０で第２の認可操作要否判断モジュール３０６は、認可操作を省略してアクセストークンを発行してよいと判断し、フローを終了する。なおここでの判断の結果は、図５（Ｂ）のステップＳ１１０５で使用される。ステップＳ２０５０で第２の認可操作要否判断モジュール３０６は、アクセストークンの発行のためには認可操作を省略できないと判断し、フローを終了する。なおここでの判断の結果は、図５（Ｂ）のステップＳ１１０５で使用される。ステップＳ２０６０で第２の認可操作要否判断モジュール３０６は、アクセストークンの発行のためには認可操作を省略できないと判断し、フローを終了する。なおここでの判断の結果は、図５（Ｂ）のステップＳ１１０５で使用される。
【００７３】
図１２（Ａ）は本実施の第２の形態に係る、認証・認可サーバー１５１における、クライアント識別子紐付け要否判断のフローである。本フローは認証・認可サーバー１５１が、クライアントモジュール３５１からユーザー情報を含むアクセスを受信することで開始される。たとえば、図５（Ｂ）のステップＳ１１０３におけるユーザーログイン後に本フローを実行してもよい。
【００７４】
ステップＳ２１０１で第２のクライアント識別子紐付け管理モジュール３０７は、クライアントモジュール３５１からのアクセスを受け付ける。ここで受け付けたアクセスには、ユーザーの情報およびクライアント識別子を含む。ステップＳ２１０２で第２のクライアント識別子紐付け管理モジュール３０７は、ステップＳ２１０１で受け付けたアクセスに含まれるクライアント識別子のクライアント種別が、共有設定端末であるか判断する。共有設定端末であると判断されればステップＳ２０１３に遷移する。また共有設定端末でないと判断された場合はステップＳ２１１１に遷移する。なおここでクライアント種別は表６に示されるような第２のクライアント識別子テーブルを参照する。
【００７５】
ステップＳ２１０３で第２のクライアント識別子紐付け管理モジュール３０７は、ステップＳ２１０１で受け付けたアクセスに含まれるユーザーの情報およびクライアント識別子から、クライアント識別子が、ユーザーが所属するテナントに紐付け済みかを判断する。ここで紐付け済みと判断された場合は、クライアントに対し、テナントとクライアント識別子の紐付けの確認を行わずにフローを終了する。また紐付け済みでないと判断された場合はステップＳ２１０４に遷移する。ここでユーザーが所属するテナントは表２のユーザー管理テーブルから、クライアントが紐付けられたテナントは表３のクライアント識別子紐付けテーブルから、それぞれ判断する。
【００７６】
ステップＳ２１０４で第２のクライアント識別子紐付け管理モジュール３０７は、ステップＳ２１０１で受け付けたアクセスに含まれるユーザーが、クライアント識別子をテナントに紐付ける権限を持つか判断する。ここでは、ユーザーがテナントの管理者である場合に、クライアント識別子を紐付ける権限を持つこととする。またこの判断には、表２のユーザー管理テーブルを用いて、ユーザーの権限を判断することとする。ユーザーがテナントにクライアント識別子を紐付ける権限を持つと判断された場合はステップＳ２１０５に遷移する。また権限がないと判断された場合は、クライアントに対し、テナントとクライアント識別子の紐付けの確認を行わずにフローを終了する。ステップＳ２１０５で第２のクライアント識別子紐付け管理モジュール３０７は、クライアントモジュール３５１に対してテナントとクライアント識別子を紐付ける、クライアント識別子紐付け確認を要求する。またクライアント識別子紐付け確認の要求が完了するとフローを終了する。
【００７７】
ステップＳ２１１１で第２のクライアント識別子紐付け管理モジュール３０７は、ステップＳ２１０１で受け付けたアクセスに含まれるユーザーの情報およびクライアント識別子から、クライアント識別子がユーザーに紐付け済みかを判断する。ここで紐付け済みと判断された場合は、クライアントに対し、ユーザーとクライアント識別子の紐付けの確認を行わずにフローを終了する。また紐付け済みでないと判断された場合はステップＳ２１１２に遷移する。ここでクライアントが紐付けられたユーザーは表５のクライアント識別子紐付けテーブルから判断する。ステップＳ２１１２で第２のクライアント識別子紐付け管理モジュール３０７は、クライアントモジュール３５１に対してユーザーとクライアント識別子を紐付ける、クライアント識別子紐付け確認を要求する。またクライアント識別子紐付け確認の要求が完了するとフローを終了する。
【００７８】
図１２（Ｂ）は本実施の第２の形態に係る、ユーザー端末１９１における、クライアント識別子紐付け確認のフローである。このフローは、図１２（Ａ）のステップＳ２１１２のユーザーに対するクライアント識別子紐付け確認の要求を、ユーザー端末１９１が認証・認可サーバー１５１から受け付けることで開始される。なおユーザー端末１９１が認証・認可サーバー１５１から受け付けた要求が、図１２（Ａ）のステップＳ２１０５に示されるような、テナントに対するクライアント識別子紐付け確認の要求であった場合は、図７（Ｂ）に示されるフローを実施する。
【００７９】
ステップＳ２２０１で第２のクライアント紐付け要求モジュール３５３は、認証・認可サーバー１５１からの要求に従い、図１３に示すような第２のクライアント紐付け確認画面２５０１を表示する。また画面を表示することで、クライアント識別子をユーザー自身に紐付けるか、ユーザーに確認を行う。
【００８０】
ステップＳ２２０２で第２のクライアント紐付け要求モジュール３５３は、ステップＳ２２０１の確認に対応して、ユーザーにクライアント識別子の紐付けをする指示があったかを判断する。ここで指示があったと判断された場合はステップＳ２２０３に遷移する。また指示がなかったと判断された場合はクライアント識別子の紐付け要求を行わずにフローを終了する。ステップＳ２２０３で第２のクライアント紐付け要求モジュール３５３は、認証・認可サーバー１５１にクライアント識別子紐付け要求を行う。ここでクライアント識別子紐付け要求は、ユーザー端末を操作するユーザーが所属するテナントおよびステップＳ４０３で受信したクライアント識別子を含む。クライアント識別子紐付け要求が完了するとフローを終了する。
【００８１】
図１２（Ｃ）は本実施の第２の形態に係る、認証・認可サーバー１５１における、クライアント識別子の紐付けフローである。本フローは認証・認可サーバー１５１がユーザー端末１９１からクライアント識別子紐付け要求を受信したことで開始される。ステップＳ２３０１で第２のクライアント識別子紐付け管理モジュール３０７は、クライアント紐付け要求モジュール３５２もしくは第２のクライアント紐付け要求モジュール３５３からクライアント識別子紐付け要求を受け付ける。ここで受け付けたクライアント識別子紐付け要求は、ユーザーの情報およびクライアント識別子を含む。ステップＳ２３０２で第２のクライアント識別子紐付け管理モジュール３０７は、ステップＳ２３０１で受け付けた要求に含まれるクライアント識別子を、クライアントからの要求に従ってクライアント識別子紐付けテーブルに記憶する。例えば、クライアントからユーザーとの紐付けを指定された場合は、クライアント識別子を、指定されたユーザーと紐付けて記憶する。紐付けの記憶が完了するとフローを終了する。図１３は本実施の第２の形態に係る、ユーザーがクライアントモジュールを、ユーザーが所属するテナントに紐付ける際の確認を行うクライアント紐付け確認画面２５０１の例である。
【００８２】
本実施の第２の形態において、ステップＳ２０２１では、ユーザーが所属するテナントに紐付けられた共有設定端末のいずれかに対してアクセストークンが発行済みか判断している。ここで共有設定端末のいずれに対してもアクセストークンが発行されていない場合は、ユーザーが共有設定端末で認可操作を行っていないことになるが、ステップＳ２０６０に遷移させて認可操作を省略できないと決定してはいない。代わりに、ステップＳ２０１１に遷移させることで、ユーザーに紐付けられたクライアント識別子に対するアクセストークンの発行を確認している。一方で、ステップＳ２０１１でアクセストークンが発行済みであると判断できなかった場合は、ユーザーが所属するテナントに紐付けられたクライアント識別子に対するアクセストークンの発行を確認することなく、認可操作を省略できないと決定している。これは個別設定端末と共有設定端末の利用の仕方を意識して処理を分けている。
【００８３】
個別設定端末はユーザー自身に紐付く端末であることから、ユーザーの個人的なデータも保存されていると言える。一方で共有設定端末はテナントに紐付く端末であることから、端末内には主に共有データが保存されていると言える。そのためユーザーの視点に立つと、個別設定端末に対する認可の可否の判断を、よりセキュアに行う必要がある。そのため個別設定端末で認可操作を省略するか判断する際は、個別設定端末の一覧に含まれるクライアント識別子のみでアクセストークンが発行済みであるかを確認する。
【００８４】
一方で、共有設定端末で認可操作を省略するか判断する際は、共有設定端末の一覧に含まれるクライアント識別子でアクセストークンが発行済みでない場合に、個別設定端末の一覧でもアクセストークンが発行済みであるかを確認する。これは、共有設定端末よりセキュアに運用される個別設定端末で認可操作が行われているのであれば、相対的に低いセキュリティレベルである共有設定端末で認可操作を省略してよいと判断するためである。
【００８５】
上述の処理は、図１１のステップＳ２０１１およびステップＳ２０２１の条件分岐に表れている。本実施の第２の形態によれば、クライアント種別を考慮して認可操作の省略可否を判断することで、個別設定端末利用時のセキュリティを確保すると共に、共有設定端末利用時の利便性を向上させることができる。
【００８６】
［実施例３］
次に、本発明を実施するための第３の形態について図面を用いて説明する。なお第１の実施の形態もしくは第２の実施の形態と共通の部分については説明を省略し、以下では差異部分について説明する。
【００８７】
第３の実施の形態においては、クライアント種別の登録および変更について説明する。図１４は本実施の第３の形態に係る、認証・認可サーバー１５１のモジュール構成を示す図である。認証・認可サーバー１５１はクライアント識別子管理モジュール３０１、認証モジュール３０２、認可モジュール３０４を持つ。さらに認証・認可サーバー１５１は第２の認可操作要否判断モジュール３０６および第２のクライアント識別子紐付け管理モジュール３０７を持つ。また認証・認可サーバー１５１は、クライアント種別登録モジュール３１０およびクライアント種別変更モジュール３１１を持つ。
【００８８】
図１５は本実施の第３の形態に係る、クライアント種別の初期値登録フローである。本フローは、図４（Ｂ）のクライアント識別子発行フローに続けて実施されてもよく、またそれ以降のタイミングで実施されてもよい。ステップＳ３００１でクライアント種別登録モジュール３１０は、クライアント識別子に割り当てるクライアント種別の初期値を決定するために、クライアントの証明書を取得する。これはステップＳ４１２で参照した証明書と同じものである。ステップＳ３００２でクライアント種別登録モジュール３１０は、表７に示されるようなデフォルトクライアントテーブルを参照し、証明書に紐付けられたデフォルトクライアント種別を取得する。
【００８９】
【表７】
2016085641.tif 000009
【００９０】
ここで例えば、ステップＳ３００１で取得した証明書がＰｒｉｎｔｉｎｇＤｅｖｉｃｅであれば、デフォルトクライアント種別はｔｅｎａｎｔを取得できる。ステップＳ３００３でクライアント種別登録モジュール３１０は、ステップＳ３００２で取得したデフォルトクライアントの種別を、表６に示すような第２のクライアント識別子テーブルで記憶する。例えばクライアント識別子がＡｐｐＡｍ００１であり、ステップＳ３００２で取得したデフォルトクライアント種別がｔｅｎａｎｔであった場合、表６に示されるように、ＡｐｐＡｍ００１のクライアント種別がｔｅｎａｎｔであるとして記憶される。
【００９１】
図１６（Ａ）は本実施の第３の形態に係る、クライアント種別を共有設定端末に変更するフローである。本フローは認証・認可サーバー１５１が、あるクライアント識別子のクライアント種別を共有設定端末に変更するよう、ユーザーから指示されたことにより開始される。なお本フローは図１５に示されるクライアント種別の初期値登録フローに続けて実施されてもよく、またそれ以降のタイミングで実施されてもよい。
【００９２】
ステップＳ３１０１でクライアント種別変更モジュール３１１は、図１７（Ａ）に示されるような第１のクライアント種別切り替え画面３５０１を表示し、クライアント種別を共有設定端末に変更してよいか、ユーザーに対して確認を行う。ステップＳ３１０２でクライアント種別変更モジュール３１１は、クライアント種別がユーザーに許可されたかを判断する。ここでユーザーに許可されたと判断された場合はステップＳ３１０３に遷移する。また許可されなかったと判断された場合はクライアント種別の変更を行わず、フローを終了する。
【００９３】
ステップＳ３１０３でクライアント種別変更モジュール３１１は、対象となったクライアント識別子のクライアント種別を、共有設定端末に変更する。ステップＳ３１０４でクライアント種別変更モジュール３１１は、対象となったクライアント識別子に関して、クライアント識別子とユーザーの紐付けをすべて解除する。ステップＳ３１０５でクライアント種別変更モジュール３１１は、対象となったクライアント識別子を、変更を許可したユーザーの所属テナントと紐付ける。テナントとの紐付けが完了すると、フローを終了する。
【００９４】
図１６（Ｂ）は本実施の第３の形態に係る、クライアント種別を個別設定端末に変更するフローである。本フローは認証・認可サーバー１５１が、あるクライアント識別子のクライアント種別を個別設定端末に変更するよう、ユーザーから指示されたことにより開始される。なお本フローは図１５に示されるクライアント種別の初期値登録フローに続けて実施されてもよく、またそれ以降のタイミングで実施されてもよい。
【００９５】
ステップＳ３２０１でクライアント種別変更モジュール３１１は、図１７（Ｂ）に示されるような第２のクライアント種別切り替え画面３５０２を表示し、クライアント種別を個別設定端末に変更してよいか、ユーザーに対して確認を行う。ステップＳ３２０２でクライアント種別変更モジュール３１１は、クライアント種別がユーザーに許可されたかを判断する。ここでユーザーに許可されたと判断された場合はステップＳ３２０３に遷移する。また許可されなかったと判断された場合はクライアント種別の変更を行わず、フローを終了する。
【００９６】
ステップＳ３２０３でクライアント種別変更モジュール３１１は、対象となったクライアント識別子のクライアント種別を、個別設定端末に変更する。ステップＳ３２０４でクライアント種別変更モジュール３１１は、対象となったクライアント識別子に関して、クライアント識別子とテナントの紐付けを解除する。ステップＳ３２０５でクライアント種別変更モジュール３１１は、対象となったクライアント識別子を、変更を許可したユーザーの所属テナントと同じテナントに属するすべてのユーザーと紐付ける。ユーザーとの紐付けが完了すると、フローを終了する。図１７は本実施の形態に係る、画面の表示例である。図１７（Ａ）はクライアント種別を共有設定端末に切り替える際の、第１のクライアント種別切り替え画面３５０１の例である。図１７（Ｂ）はクライアント種別を個別設定端末に切り替える際の、第２のクライアント種別切り替え画面３５０２の例である。
【００９７】
本実施の第３の形態によれば、端末ごとのクライアント種別の初期値を与えることができると共に、ユーザーが自身の使い方にあわせて各端末のクライアント種別を切り替えることができるようになり、利便性を向上させることができる。
【００９８】
（その他の実施例）
本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施例の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【符号の説明】
【００９９】
１５１  認証・認可サーバー
１９１  ユーザー端末
３０１  クライアント識別子管理モジュール
３０２  認証モジュール
３０３  クライアント識別子紐付け管理モジュール
３０４  認可モジュール
３０５  認可操作要否判断モジュール
３５１  クライアントモジュール
３５２  クライアント紐付け要求モジュール
【図１】
2016085641.tif 000010
【図２】
2016085641.tif 000011
【図３】
2016085641.tif 000012
【図４】
2016085641.tif 000013
【図５】
2016085641.tif 000014
【図６】
2016085641.tif 000015
【図７】
2016085641.tif 000016
【図８】
2016085641.tif 000017
【図９】
2016085641.tif 000018
【図１０】
2016085641.tif 000019
【図１１】
2016085641.tif 000020
【図１２】
2016085641.tif 000021
【図１３】
2016085641.tif 000022
【図１４】
2016085641.tif 000023
【図１５】
2016085641.tif 000024
【図１６】
2016085641.tif 000025
【図１７】
2016085641.tif 000026