(57)【要約】【課題】連携先サービスにおける必要な権限を必要なタイミングで適切に設定すること。【解決手段】ＲＰ側のアクセス管理サーバ１０２は、ＯＰ側から要求されたサービスの利用権限が、前記要求を行ったＯＰ側のアカウントに対応するＲＰ側のアカウントに対して設定されていない場合、ＯＰ側のアカウントに前記サービスに対応する権限が設定されているか否かを問い合わせる。ＯＰ側のアクセス管理サーバ１０７は、ＲＰ側からの問い合わせに応じ、ＯＰ側のアカウントに対して、前記サービスに対応する権限が設定されているか判定し、設定されている場合、ＲＰ側に対し、前記サービスの利用権限の設定を要求する。ＲＰ側のアクセス管理サーバ１０２は、上記問い合わせの応答として、ＯＰ側から前記サービスの利用権限の設定の要求を受信した場合、ＲＰ側のアカウントに対して、前記サービスの利用権限を設定する。【選択図】図１
2016206971.tif 000002
【特許請求の範囲】
【請求項１】
第１システムからの要求に応じて第２システムがサービスを提供する連携システムであって、
前記第２システムは、
前記第１システムから要求されたサービスの利用権限が、前記要求を行った前記第１システムのアカウントに対応する前記第２システムのアカウントに対して設定されているか否かを判定する第１判定手段と、
前記第１判定手段により前記第２システムのアカウントに前記サービスの利用権限が設定されていないと判定された場合、前記第１システムのアカウントに前記サービスに対応する権限が設定されているか否かを前記第１システムに問い合わせる問い合わせ手段と、
前記問い合わせ手段による問い合わせの応答として、前記第１システムから前記サービスの利用権限の設定の要求を受信した場合、前記第２システムのアカウントに対して、前記サービスの利用権限を設定する設定手段と、を有し、
前記第１システムは、
前記第２システムからの問い合わせに応じて、前記第１システムのアカウントに対して、前記サービスに対応する権限が設定されているか否かを判定する第２判定手段と、
前記第２判定手段により前記第１システムのアカウントに対して前記サービスに対応する権限が設定されていると判定された場合、前記第２システムに対し、前記サービスの利用権限の設定を要求する第１要求手段と、を有する、
ことを特徴とする連携システム。
【請求項２】
前記第１システムは、
前記第１システムのアカウントのログアウトを行う場合に、削除すべき前記第２システムの利用権限を特定する特定手段と、
前記特定手段により特定された前記第２システムの利用権限の削除を、前記第２システムに対して要求する第２要求手段と、を有し、
前記第２システムは、
前記第１システムからの前記第２システムの利用権限の削除の要求に応じて、前記ログアウトを行う前記第１システムのアカウントに対応する第２システムのアカウントから前記削除を要求された利用権限の設定を削除する削除手段を有する、
ことを特徴とする請求項１に記載の連携システム。
【請求項３】
前記第２システムは、
前記第１システムからサービスの要求を受けた場合に、前記第１システムからサービスの要求を行った前記第１システムのアカウントに対応する前記第２システムのアカウントが存在するか否かを判定する第３判定手段と、
前記第３判定手段により前記第２システムのアカウントが存在しないと判定された場合、前記第２システムのアカウントを作成する作成手段と、
を有することを特徴とする請求項１又は２に記載の連携システム。
【請求項４】
前記作成手段は、サービスの利用権限が設定されていないアカウントを作成することを特徴とする請求項３に記載の連携システム。
【請求項５】
前記第２システムは、
前記第２システムで提供されるサービスの情報を前記第１システムに通知し、前記第２システムの前記第１システムへの登録を要求する第３要求手段を有し、
前記第１システムは、
前記第２システムからの登録要求に応じて、該第２システムで提供されるサービスと、前記第１システムの機能とを対応付ける対応付け手段を有し、
前記第２判定手段は、前記第２システムからの問い合わせに応じて、前記対応付け手段による対応付けに基づいて、前記要求を行った前記第１システムのアカウントに対して、前記サービスに対応する機能を利用する権限が設定されているか否かを判定することを特徴とする請求項１乃至４のいずれか１項に記載の連携システム。
【請求項６】
第１システムからの要求に応じて第２システムがサービスを提供する連携システムの制御方法であって、
前記第２システムが実行する、
前記第１システムから要求されたサービスの利用権限が、前記要求を行った前記第１システムのアカウントに対応する前記第２システムのアカウントに対して設定されているか否かを判定する第１判定ステップと、
前記第１判定ステップにより前記第２システムのアカウントに前記サービスの利用権限が設定されていないと判定された場合、前記第１システムのアカウントに前記サービスに対応する権限が設定されているか否かを前記第１システムに問い合わせる問い合わせステップと、
前記問い合わせステップによる問い合わせの応答として、前記第１システムから前記サービスの利用権限の設定の要求を受信した場合、前記第２システムのアカウントに対して、前記サービスの利用権限を設定する設定ステップと、を有し、
前記第１システムが実行する、
前記第２システムからの問い合わせに応じて、前記第１システムのアカウントに対して、前記サービスに対応する権限が設定されているか否かを判定する第２判定ステップと、
前記第２判定ステップにより前記第１システムのアカウントに対して前記サービスに対応する権限が設定されていると判定された場合、前記第２システムに対し、前記サービスの利用権限の設定を要求する要求ステップと、を有する、
ことを特徴とする連携システムの制御方法。
【請求項７】
コンピュータを、請求項１乃至５のいずれか１項に記載の第１システムの手段として機能させるためのプログラムと、コンピュータを、請求項１乃至５のいずれか１項に記載の第２システムの手段として機能させるためのプログラムと、を有することを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、第１システムからの要求に応じて第２システムがサービスを提供する連携システム、連携システムの制御方法、及びプログラムに関するものである。
【背景技術】
【０００２】
近年、クラウドサービスと呼ばれるインターネットを介してソフトウェアの機能を提供するシステムが注目を集めている。最近では、個々のクラウドサービスが連携して、新しいシステムを提供するケースが増えている。また、クラウドサービス同士だけではなく、企業内に設置された端末、例えばＰＣ（パーソナルコンピュータ）、タブレット端末や画像形成装置が、インターネット上のクラウドサービスと連携し、ユーザに機能を提供するケースも増えている。
【０００３】
なお、企業内端末やクラウドサービスを利用する際には、不正利用の防止やユーザ識別のために、通常、ユーザ認証が必要となる。そのため、ユーザが企業内端末とクラウドサービスを連携させる場合や、クラウドサービス同士を連携させる場合には、複数回認証情報の入力を求められ、利便性にかけるという課題がある。
【０００４】
この課題を解決する手段として、複数の認証システム間で連携することで、１度の認証の結果によって複数の認証を受けることができるシングルサインオン技術の利用が広まっている。例えば、ＳＡＭＬ（Ｓｅｃｕｒｉｔｙ Ａｓｓｅｒｔｉｏｎ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）プロトコルや、ＯｐｅｎＩＤ Ｆｏｕｎｄａｔｉｏｎが規定しているＯｐｅｎＩＤ Ｃｏｎｎｅｃｔといった技術が知られている（非特許文献１参照）。
【０００５】
また、ユーザの認証情報によって連携するのではなく、連携先のシステムのアクセス権に限り、連携元のシステムに対してユーザのアクセス権限を委譲してサービス連携を行う、認可連携という方式も利用されている。認可連携としては、ＯＡｕｔｈプロトコルや、前述のＯｐｅｎＩＤ Ｃｏｎｎｅｃｔといった技術が知られている。
【０００６】
ここで、認証連携、認可連携のどちらの場合でも、連携を行うためには、連携元サービスと連携先サービスの両方に連携用アカウントが必要となる。そのため、連携元のユーザが増える度に、連携先のクラウドサービス側にアカウントを作成する必要があり、管理者の負担が大きくなるという課題がある。
【０００７】
この課題を解決する手段として、ユーザが初めてサービスを利用する時に、自動でアカウントを作成し、連携を行うＪｕｓｔ−Ｉｎ−Ｔｉｍｅプロビジョニング（以下ＪＩＴプロビジョニング）という技術が知られている。このＪＩＴプロビジョニングは、上述の非特許文献１でも実現方法が定義されている。
【０００８】
また、クラウドサービスや端末上のアプリケーションは、ユーザが利用できるサービスを制御するために、アカウント管理に加えて権限管理も行う場合がある。連携元サービスのアカウントが持つ権限を基に、連携先サービスのアカウントに権限を設定する方法として、特許文献１の方法が提案されている。
また、ＪＩＴプロビジョニング時に、設定する権限を、アカウントの属性情報に含めて通知することで、アカウント作成時に権限を設定することも出来る。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】特開２０１２−１０３８４６号公報
【非特許文献】
【００１０】
【非特許文献１】"ＯｐｅｎＩＤ Ｃｏｎｎｅｃｔ Ｃｏｒｅ １．０"、Ｎ．Ｓａｋｉｍｕｒａ、Ｊ．Ｂｒａｄｌｅｙ、Ｍ．Ｊｏｎｅｓ、Ｂ．ｄｅ Ｍｅｄｅｉｒｏｓ、Ｃ．Ｍｏｒｔｉｍｏｒｅ、２０１４年２月２５日、＜ＵＲＬ ｈｔｔｐ：／／ｏｐｅｎｉｄ．ｎｅｔ／ｓｐｅｃｓ／ｏｐｅｎｉｄ−ｃｏｎｎｅｃｔ−ｃｏｒｅ−１＿０．ｈｔｍｌ＞
【発明の概要】
【発明が解決しようとする課題】
【００１１】
上述した従来技術により、サービスやアプリケーションが連携している環境で、連携先のアカウントに権限を設定することが可能である。しかし、従来技術においては、必要な権限を必要なタイミングで設定できないという課題があった。
【００１２】
従来技術で連携先のアカウントに権限を設定する方法としては、管理者が指定した権限を一律で設定する方法（第１の方法）と、連携元のアカウントが持つ全ての権限を設定する方法（第２の方法）、利用しようとしているサービスの利用権限だけを設定する方法（第３の方法）がある。しかし、いずれの方法を取った場合でも、権限設定について課題がある。
【００１３】
以下、説明のための例として、端末上にスキャン機能と印刷機能があり、クラウドサービス上にスキャンサービスと印刷サービスがあり、それぞれスキャン機能とスキャンサービス、印刷機能と印刷サービスが連携している例を用いて説明する。
【００１４】
第１の方法では、例えば、管理者がスキャンサービスと印刷サービスの権限設定を指定していた場合、連携元の端末上のアカウントがスキャン機能しか使えない場合でも、連携先のアカウントがスキャンサービスも利用出来るようになってしまう。このように、この方法では、不要な権限が設定されてしまうという課題があった。
【００１５】
第２の方法では、例えば、連携元の端末上のアカウントがスキャン機能と印刷機能の利用権限を持っている場合、連携元でスキャン機能を利用すると連携先のアカウントにはスキャンサービスと印刷サービスの権限が設定される。ここで、サービス側で、サービスの利用権限と合わせて、サービスを利用できるアカウント数の上限を設けていた場合、この方法では利用しないサービスの権限も設定されてしまい、利用できるアカウント数が無駄に減ってしまうという課題があった。このため、無駄に利用権限を消費してしまい、他の利用者が利用できなくなってしまう事態が頻発してしまう等の可能性があった。
【００１６】
第３の方法では、例えば、連携元の端末上のアカウントがスキャン機能と印刷機能の利用権限を持っている場合、連携元でスキャン機能を利用すると連携先のアカウントにはスキャンサービスの権限だけが設定される。ここで、特許文献１の技術では、一度認証連携に成功すると、認証セッションが切れるまでなど一定の期間、連携先から連携元に問い合わせを行わずにサービスが利用可能となる。そのため、スキャン機能に連続して、印刷機能（印刷サービスと連携）を利用しようとすると、連携先において印刷サービスの利用権限なしとなり、利用出来なくなってしまう。このように第３の方法では、連続して異なるサービスを利用することができないという課題があった。
【００１７】
本発明は、上記の問題点を解決するためになされたものである。本発明の目的は、連携先サービスにおける必要な権限を必要なタイミングで適切に設定することができる仕組みを提供することである。
【課題を解決するための手段】
【００１８】
本発明は、第１システムからの要求に応じて第２システムがサービスを提供する連携システムであって、前記第２システムは、前記第１システムから要求されたサービスの利用権限が、前記要求を行った前記第１システムのアカウントに対応する前記第２システムのアカウントに対して設定されているか否かを判定する第１判定手段と、前記第１判定手段により前記第２システムのアカウントに前記サービスの利用権限が設定されていないと判定された場合、前記第１システムのアカウントに前記サービスに対応する権限が設定されているか否かを前記第１システムに問い合わせる問い合わせ手段と、前記問い合わせ手段による問い合わせの応答として、前記第１システムから前記サービスの利用権限の設定の要求を受信した場合、前記第２システムのアカウントに対して、前記サービスの利用権限を設定する設定手段と、を有し、前記第１システムは、前記第２システムからの問い合わせに応じて、前記第１システムのアカウントに対して、前記サービスに対応する権限が設定されているか否かを判定する第２判定手段と、前記第２判定手段により前記第１システムのアカウントに対して前記サービスに対応する権限が設定されていると判定された場合、前記第２システムに対し、前記サービスの利用権限の設定を要求する第１要求手段と、を有する、ことを特徴とする。
【発明の効果】
【００１９】
本発明によれば、連携先サービスにおける必要な権限を必要なタイミングで適切に設定することができる。
よって、連携元のアカウントが利用できない機能が連携先のアカウントで利用出来るようになってしまう等の不要な権限が設定されてしまうことを防止できる。また、連携先のアカウントの利用権限を無駄に消費してしまうことも防止できる。さらに、連続して異なるサービスを利用することも可能となる。従って、上述した課題を解決する権限のＪＩＴプロビジョニングシステムを提供することができる。
【図面の簡単な説明】
【００２０】
【図１】本実施例を示すシステムの構成を例示する図
【図２】本実施例のシステムを構成するサーバのハードウェア構成図
【図３】本実施例のシステムのソフトウェア構成図
【図４】クライアント登録処理のフローチャート
【図５】ＯＰ登録画面および連携設定画面を例示する図
【図６】ＪＩＴプロビジョニング処理を例示するフローチャート
【図７】ＯＰ選択画面および認可確認画面を例示する図
【図８】ログアウトを行う際の処理を例示するフローチャート
【図９】複数の機能を連続して利用する場合の処理を例示するフローチャート
【発明を実施するための形態】
【００２１】
以下、本発明を実施するための形態について図面を用いて説明する。
【実施例１】
【００２２】
インターネット上で、様々なサービス提供者が様々なオンラインサービスを提供している。ここで、複数のサービス提供者が運営している複数のオンラインサービスを組み合わせ、１つのソリューションを実現するという手法が存在する。この手法はマッシュアップと呼ばれ、表向きはあたかも１つのＷｅｂサイトあるいはＷｅｂサービスとして見える。しかし、マッシュアップサービスでは、実際にはバックエンドにおいて複数のオンラインサービスが連携・連動して、必要な機能を組み合わせてソリューションを実現している。
【００２３】
また、企業内端末がインターネット上のオンラインサービスと連携して、ユーザに機能を提供する形態も広がっている。なお、ここで言うオンラインサービスとは、Ｗｅｂサイト、Ｗｅｂアプリケーション、Ｗｅｂサービスなどが提供する機能群のことである。Ｗｅｂサイト、Ｗｅｂアプリケーション、Ｗｅｂサービスなどは、サーバコンピュータで実行されるソフトウェアである。
【００２４】
ここで、インターネット上のサービスと連携を行うための手法として、ＯｐｅｎＩＤ Ｃｏｎｎｃｅｔという技術がある。ＯｐｅｎＩＤ Ｃｏｎｎｃｅｔを利用することで、複数サービス間でシングルサインオンによる連携や、認可連携を実現できる。
【００２５】
図１は、本発明の一実施例を示すシステムの構成を例示する図であり、各種オンラインサービスが存在するネットワーク構成に対応する。
図１において、インターネット１００は、インターネットなどの外部から接続可能なパブリックなネットワークである。
【００２６】
イントラネット１０１は、ＬＡＮなどの外部から接続不可能なプライベートなネットワークである。
アクセス管理サーバ１０２は、ユーザの認証情報および認可情報を管理するサービスシステムである。アクセス管理サーバ１０２は、ＯｐｅｎＩＤ Ｃｏｎｎｅｃｔにおいては、Ｒｅｌｙｉｎｇ Ｐａｒｔｙ（以下ＲＰ）と呼ばれる。
リソースサーバ１０３は、印刷サービスやスキャンサービスといったリソースサービスを提供しているオンラインサービスシステムである。リソースサーバ１０３は、インターネット１００を介したクライアント端末１０６あるいは不図示の外部サービスシステムからのリクエストに応じて、リソースサービスを提供する。なお、リソースサーバ１０３に設置されるリソースサービスは１つでもよく、複数でもよい。
【００２７】
ここで、アクセス管理サーバ１０２とリソースサーバ１０３はそれぞれが連携し、ＲＰサービスシステム１０４を提供する。なお、アクセス管理サーバ１０２とリソースサーバ１０３は、同一のサーバ上に構成されていてもよいし、同一のＬＡＮ上に構成されてもよいし、それぞれ個別のＬＡＮ上に構成されてもよい。また、実施例１において各サーバは１台ずつ設置されているが、複数台で構成されていてもよい。
【００２８】
イントラネット１０５は、ＬＡＮなどの外部から接続不可能なプライベートなネットワークである。
クライアント端末１０６（以下、端末１０６）は、ＰＣ（パーソナルコンピュータ）や、スマートフォンやタブレット端末と呼ばれる携帯端末や、ＭＦＰ、プリンタ、スキャナ等の画像形成装置であり、Ｗｅｂブラウザやアプリケーションモジュールがインストールされている。なお、ＭＦＰは、Ｍｕｌｔｉｆｕｎｃｔｉｏｎ Ｐｅｒｉｐｈｅｒａｌを示す。
アクセス管理サーバ１０７は、端末１０６を利用するユーザの認証情報および認可情報を管理するサービスシステムである。アクセス管理サーバ１０７は、ＯｐｅｎＩＤ Ｃｏｎｎｃｅｔにおいては、ＯｐｅｎＩＤ Ｐｒｏｖｉｄｅｒ（以下ＯＰ）と呼ばれる。
【００２９】
リソースサーバ１０８は、印刷サービスやスキャンサービスといったリソースサービスを提供しているサービスシステムである。リソースサーバ１０８は、端末１０６あるいはイントラネット１０５に接続されている不図示のサービスシステムからのリクエストに応じて、リソースサービスを提供する。その際、リソースサーバ１０８は、ＲＰサービスシステム１０４と連携し、リソースサーバ１０３を呼び出してリソースサービスを提供することができる。なお、リソースサーバ１０８に設置されるリソースサービスは１つでもよく、複数でもよい。また、リソースサーバ１０８は、後述の端末１０６上のアプリケーションモジュール３２２として構成されてもよい。
【００３０】
なお、端末１０６、アクセス管理サーバ１０７、リソースサーバ１０８は同一のサーバ上に構成されてもよく、同一の端末上に構成されてもよく、同一のＬＡＮ上に構成されてもよい。
ここで、アクセス管理サーバ１０２とリソースサーバ１０３はそれぞれが連携し、ＲＰサービスシステム１０４に対して、ＯＰサービスシステム１０９を提供する。また、実施例１において各サーバは１台ずつ設置されているが、複数代で構成されてもよい。
【００３１】
なお、図１に示す本実施例のシステムは、ＯＰサービスシステム１０９からの要求に応じてＲＰサービスシステム１０４がサービスを提供する連携システムである。詳細は後述するが、本実施例のシステムは、ＲＰサービスシステム１０４のサービスを利用する時に、自動でアカウントを作成し、連携を行うＪｕｓｔ−Ｉｎ−Ｔｉｍｅプロビジョニングシステム（ＪＩＴプロビジョニングシステム）である。
【００３２】
図２は、図１に示した各種サービスが配置されているサーバのハードウェア構成を例示する図である。
図２において、ユーザインタフェース２０１は、ディスプレイ、キーボード、マウス、タッチパネルなどによる、情報の入出力を行うハードウェアである。これらのハードウェアを備えないコンピュータは、リモートデスクトップ機能等を用い、他のコンピュータから接続・操作することも可能である。
【００３３】
ネットワークインタフェース２０２は、ＬＡＮなどのネットワーク（有線でも無線でもよい）に接続して、他のコンピュータやネットワーク機器との通信を行うハードウェアである。
ＣＰＵ２０３は、ＲＯＭ２０４、ＲＡＭ２０５、二次記憶装置２０６などから読み込んだプログラムを実行し、各種サービスを実現する。ＲＯＭ２０４は、組込済みプログラムおよびデータが記録されている記憶装置である。ＲＡＭ２０５は、例えばＣＰＵ２０３の一時メモリ領域として使用される。二次記憶装置２０６は、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）やＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）に代表されるような外部記憶装置である。
なお、以上２０１〜２０６に示した各部は、バスなどの入出力インタフェース２０７を介して接続されている。
【００３４】
図３は、図１に示した本実施例のシステムのソフトウェア構成を例示する図である。
図３（Ａ）に示すように、アクセス管理サーバ１０２，１０７は、リクエスト処理部３００、アクセス制御部３０１、ユーザ管理部３０２等のソフトウェアモジュールを有する。なお、これらのソフトウェアモジュールは、アクセス管理サーバ１０２，１０７のＣＰＵ２０３が二次記憶装置２０６等に格納されたプログラムを読み出して実行することにより実現される。
【００３５】
リクエスト処理部３００は、アクセス管理サーバ１０２，１０７がインターネット及びイントラネットを経由して受信したアクセス管理サーバへのリクエストを処理する処理部である。また、リクエスト処理部３００は、アクセス制御部３０１から返される応答データを呼び出し元に返す。
【００３６】
アクセス制御部３０１は、ユーザ管理部３０２から取得するデータに基づき、認証および認可要求を処理する処理部である。また、アクセス制御部３０１は、ユーザ管理部３０２に対して、アカウント追加やアカウント情報変更を行う。
ユーザ管理部３０２は、ユーザカウントのデータや、認可情報を管理する。
【００３７】
図３（Ｂ）に示すように、リソースサーバ１０３，１０８は、リクエスト処理部３１０、機能制御部３１１等のソフトウェアモジュールを有する。なお、これらのソフトウェアモジュールは、リソースサーバ１０３，１０８のＣＰＵ２０３が二次記憶装置２０６等に格納されたプログラムを読み出して実行することにより実現される。
【００３８】
リクエスト処理部３１０は、リソースサーバ１０３，１０８がインターネット及びイントラネットを経由して受信したリソースサービスへのリクエストを処理する処理部である。また、リクエスト処理部３１０は、機能制御部３１１から返される処理結果を呼び出し元に返す。
機能制御部３１１は、リクエスト処理部３１０が受信したリクエストに応じて必要な処理を行い、応答データを呼び出し元に返す。
【００３９】
図３（Ｃ）に示すように、端末１０６は、Ｗｅｂブラウザ３２０、認証モジュール３２１、アプリケーションモジュール３２２等のソフトウェアモジュールを有する。なお、これらのソフトウェアモジュールは、端末１０６のＣＰＵ２０３が二次記憶装置２０６等に格納されたプログラムを読み出して実行することにより実現される。
【００４０】
Ｗｅｂブラウザ３２０は、ＷＷＷ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）を利用するためのユーザエージェントであり、インターネット１００を経由してＲＰサービスシステム１０４へのアクセスを行う。
認証モジュール３２１は、端末１０６において端末利用者を認証するための機能を備える。この認証モジュール３２１は、アクセス管理サーバ１０７と通信することで、端末利用者を認証するように構成できる。また、認証モジュール３２１は、不図示の端末内部で管理する認証情報を利用して端末利用者を認証するようにも構成できる。
【００４１】
アプリケーションモジュール３２２は、端末１０６にて動作するアプリケーションプログラムである。アプリケーションモジュール３２２は、リソースサーバ１０８と通信することで、ＯＰ機能を提供するように構成できる。また、アプリケーションモジュール３２２は、端末１０６内部のアプリケーションモジュールのみでＯＰ機能を提供するようにも構成できる。
【００４２】
図４は、ＯＰサービスシステム１０９とＲＰサービスシステム１０４を連携させるために、アクセス管理サーバ１０７にアクセス管理サーバ１０２の情報を登録する登録処理（クライアント登録処理）を例示するフローチャートである。なお、本クライアント登録処理の実行時には、ＯＰサービスシステム１０９およびＲＰサービスシステム１０４の両方に管理者権限のアカウントが用意されているものとする。
【００４３】
また、このフローチャートに示す端末１０６の処理は、端末１０６のＣＰＵ２０３が二次記憶装置２０６等に格納されたプログラムを読み出して実行することにより実現される。同じくアクセス管理サーバ１０７の処理は、アクセス管理サーバ１０７のＣＰＵ２０３が二次記憶装置２０６等に格納されたプログラムを読み出して実行することにより実現される。同じくアクセス管理サーバ１０２の処理は、アクセス管理サーバ１０２のＣＰＵ２０３が二次記憶装置２０６等に格納されたプログラムを読み出して実行することにより実現される。
【００４４】
ステップＳ４０１において、管理者が端末１０６にアクセスすると、端末１０６上の認証モジュール３２１が、ユーザが認証済みか否かを確認し、未認証と判定した場合には、アクセス管理サーバ１０７に対して認証を要求する。
この要求に応じて、アクセス管理サーバ１０７は、認証処理を行い（Ｓ４０２）、認証結果を端末１０６に返信する。この認証処理の際、アクセス管理サーバ１０７は、アクセス管理サーバ１０７のアカウントテーブル（例えば表１）を用いる。また、アクセス管理サーバ１０７は、該アカウントテーブルから、認証したアカウントが利用できる機能の情報を取得する。
表１に、アクセス管理サーバ１０７が管理しているアカウント情報の例を示す。なお、アクセス管理サーバ１０７が管理しているアカウント情報は、アクセス管理サーバ１０７の二次記憶装置２０６に格納されているものとする。
【００４５】
【表１】
2016206971.tif 000003
【００４６】
表１に示すように、アクセス管理サーバ１０７が管理しているアカウント情報は、ユーザＩＤ、パスワード、ＵＵＩＤ（Ｕｎｉｖｅｒｓａｌｌｙ Ｕｎｉｑｕｅ Ｉｄｅｎｔｉｆｉｅｒ）、権限、ロール等の情報を含む。ここで、アクセス管理サーバ１０７のアカウントテーブルで管理されているロールのうち、「スキャン」ロールはＯＰ機能の「スキャン機能」を利用する権限とし、「印刷」ロールはＯＰ機能の「印刷機能」を利用する権限とする。本実施例では、ユーザＩＤ「ａｄｍｉｎ１」で認証したものとする。なお、ユーザ認証済みの場合には、上記Ｓ４０２の認証は行われず、管理者は、以下のＳ４０３に示すＲＰ登録要求が可能となる。
【００４７】
アクセス管理サーバ１０７での認証に成功すると、管理者は、端末１０６上のＷｅｂブラウザ３２０を用いて、アクセス管理サーバ１０２に対してＲＰ登録要求を行う（Ｓ４０３）。
上記Ｓ４０３の要求に応じて、アクセス管理サーバ１０２は、認証処理を行う（Ｓ４０４）。この認証処理の際、アクセス管理サーバ１０２は、アクセス管理サーバ１０２のアカウントテーブル（例えば表２）を用いる。また、アクセス管理サーバ１０２は、該アカウントテーブルから、認証したアカウントが利用できるサービスの情報を取得する。
表２に、アクセス管理サーバ１０２が管理しているアカウント情報の例を示す。なお、アクセス管理サーバ１０２が管理しているアカウント情報は、アクセス管理サーバ１０２の二次記憶装置２０６に格納されているものとする。
【００４８】
【表２】
2016206971.tif 000004
【００４９】
表２に示すように、アクセス管理サーバ１０２が管理しているアカウント情報は、ユーザＩＤ、パスワード、ＵＵＩＤ、ＯＰ側ＵＵＩD，権限、ロール等の情報を含む。ここで、アクセス管理サーバ１０２のアカウントテーブルで管理されているロールのうち、「スキャンサービス」ロールは「スキャンサービス」を利用する権限とし、「印刷サービス」ロールは「印刷サービス」を利用する権限とする。本実施例では、ユーザＩＤ「ａｄｍｉｎＡ」で認証したものとする。
なお、表２のアカウントテーブルにおいて、データ未格納なカラムについては後述する。
【００５０】
次に、Ｓ４０５において、アクセス管理サーバ１０２は、図５（Ａ）に示すようなＯＰ登録画面５００から、登録先ＯＰ情報を受け付ける。この際、フローチャートには示していないが、アクセス管理サーバ１０２は、ＯＰ登録画面５００を端末１０６のＷｅｂブラウザ３２０に送信し、該Ｗｅｂブラウザ上から登録先ＯＰ情報を受け付ける。
【００５１】
図５（Ａ）は、本実施例のＯＰ登録画面を例示する図である。
ＯＰ登録画面５００は、ＯＰ名入力部５０１、ＲＰ登録エンドポイントＵＲＩ入力部５０２、認証エンドポイントＵＲＩ入力部５０３、登録ボタン５０４、登録キャンセルボタン５０５を有する。なお、ＯＰ名入力部５０１および認証エンドポイントＵＲＩ入力部５０３は必須ではなく、項目が存在しなくてもよいし、空を指定してもよい。
【００５２】
なお、登録ボタン５０４が押下されると、端末１０６のＷｅｂブラウザ３２０は、ＯＰ登録画面５００で入力された登録先ＯＰ情報を、アクセス管理サーバ１０２に送信し、アクセス管理サーバ１０２がこれを受信する。登録先ＯＰ情報には、必須情報としてアクセス管理サーバのＲＰ登録エンドポイントのＵＲＩが含まれる。また、任意情報としてＯＰ名と、認証エンドポイントＵＲＩが含まれる。本実施例では、ＲＰ登録エンドポイントＵＲＩとして「ｈｔｔｐｓ：／／ｌｏｃａｌ／ｒｅｇ」、ＯＰ名として「ＯＰ１」、認証エンドポイントＵＲＩとして「ｈｔｔｐｓ：／／ｌｏｃａｌ／ａｕｔｈ」が指定されたものとする。
【００５３】
次に、Ｓ４０６において、アクセス管理サーバ１０２は、自身のＲＰ情報からなるＲＰメタデータと、利用可能サービス情報を用意し、ＲＰ登録エンドポイントＵＲＩへのリダイレクト指示と共に、端末１０６にクライアント登録要求を返す。このＲＰメタデータには、アクセス管理サーバ１０２がＯｐｅｎＩＤ Ｃｏｎｎｅｃｔ連携時のレスポンスを受け取るＵＲＩである、リダイレクトＵＲＩを含んでいる。本実施例では、リダイレクトＵＲＩとして「ｈｔｔｐｓ：／／００２．ｘｘ／ｒｅｓ」を指定し、利用可能サービスとして「スキャンサービス」および「印刷サービス」を返したものとする。また、自身のＲＰ情報は、アクセス管理サーバ１０２の二次記憶装置２０６に格納されているものとする。
【００５４】
上記クライアント登録要求を受けると、端末１０６上のＷｅｂブラウザ３２０は、アクセス管理サーバ１０２から受け取った情報と共に、アクセス管理サーバ１０７にクライアント登録要求をリダイレクトする（Ｓ４０７）。
【００５５】
該リダイレクトされたクライアント登録要求を受けると、アクセス管理サーバ１０７は、クライアント登録を行う（Ｓ４０８）。このクライアント登録時に、アクセス管理サーバ１０７は、指定されたリダイレクトＵＲＩ（上述の例では「ｈｔｔｐｓ：／／００２．ｘｘ／ｒｅｓ」）が登録済みかを確認し、未登録の場合にはクライアントＩＤを発行し、アクセス管理サーバ１０７のＲＰテーブル（例えば表３）に登録を行う。さらに、アクセス管理サーバ１０７は、Ｘ．５０９の秘密鍵と公開鍵の鍵ペア（拡張子「．ｐ１２」の照明書ファイル）を生成して、例えばアクセス管理サーバ１０７の二次記憶装置２０６に格納する。
表３に、アクセス管理サーバ１０７のＲＰテーブルの例を示す。なお、アクセス管理サーバ１０７のＲＰテーブルは、アクセス管理サーバ１０７の二次記憶装置２０６に格納されているものとする。
【００５６】
【表３】
2016206971.tif 000005
【００５７】
以下に、アクセス管理サーバ１０７のＲＰテーブルに登録する情報の例を示す。
本実施例では、アクセス管理サーバ１０７は、指定されたリダイレクトＵＲＩ「ｈｔｔｐｓ：／／００２．ｘｘ／ｒｅｓ」を登録し、クライアントＩＤ「ＩＤ００２」を発行するものとする。
なお、上記Ｓ４０８で受け取ったリダイレクトＵＲＩが登録済みだった場合には、アクセス管理サーバ１０７は、クライアントの新規登録を行わずに登録済みのクライアント情報を利用してもよく、未登録の場合と同様に新規登録を行ってもよい。
【００５８】
なお、アクセス管理サーバ１０７は、後述するＳ４１０〜Ｓ４１１において、上記Ｓ４０８のクライアント登録結果としての登録情報を、クライアント登録リクエストのレスポンスとして、端末１０６のＷｅｂブラウザ３２０を介して、アクセス管理サーバ１０２に返す。このクライアント登録リクエストのレスポンスとして返すデータは、具体的には、上記発行したクライアントＩＤと、Ｘ．５０９形式の証明書から抽出した公開鍵（拡張子「．ｃｅｒ」のファイル）と、登録したリダイレクトＵＲＩを含む。
【００５９】
次に、Ｓ４０９において、アクセス管理サーバ１０７は、後述の連携設定画面５１０から、ＲＰサービスとＯＰ権限との連携設定を行う。この際、フローチャートには示していないが、アクセス管理サーバ１０７は、連携設定画面５１０を端末１０６のＷｅｂブラウザ３２０に送信し、該Ｗｅｂブラウザ上から連携設定情報を受け付ける。
【００６０】
図５（Ｂ）は、本実施例の連携設定画面を例示する図である。
連携設定画面５１０は、ＲＰサービス入力部５１１、ＯＰ権限入力部５１２、設定ボタン５１３、設定キャンセルボタン５１４を有する。ＲＰサービス入力部５１１とＯＰ権限入力部５１２は、前述のクライアント登録処理フローで取得されたサービス、権限の一覧から対象を選択する方式でもよい。
【００６１】
上記連携設定は、具体的には、図４のＳ４０２で認証したアカウントが管理しているＯＰ側の機能と、Ｓ４０６で送られてきたＲＰ側のサービスとのマッピングを設定するためのものである。
以下に、アクセス管理サーバ１０７が管理しているサービス連携情報の例を示す。
本実施例では、ＲＰ側のスキャンサービスとＯＰ側のスキャン権限、ＲＰ側の印刷サービスとＯＰ側の印刷権限をそれぞれ連携させたものとする。
【００６２】
なお、連携設定画面５１０の設定ボタン５１３が押下されると、端末１０６のＷｅｂブラウザ３２０は、連携設定画面５１０で入力された連携設定情報を、アクセス管理サーバ１０７に送信し、アクセス管理サーバ１０７がこれを受信する。アクセス管理サーバ１０７は、上記連携設定情報をサービステーブル（例えば表４）に格納して管理する。
表４に、アクセス管理サーバ１０７のサービステーブルの例を示す。なお、アクセス管理サーバ１０７が管理しているサービステーブルは、アクセス管理サーバ１０７の二次記憶装置２０６に格納されているものとする。
【００６３】
【表４】
2016206971.tif 000006
【００６４】
表４に示すように、アクセス管理サーバ１０７のサービステーブルでは、ＯＰ権限と、該ＯＰ権限と連携するＲＰサービスがマッピングされて登録される。なお、表４には示していないが、サービステーブル内のＲＰサービスには、該ＲＰサービスを提供するＲＰサービスシステムのクライアントＩＤが紐付けられている。
【００６５】
なお、表４に示すようなサービステーブルには、１のＯＰ権限に対して複数のＲＰサービスを対応付けることも可能である。この場合、例えばアクセス管理サーバ１０７が、機能利用時（後述する図６のＳ６０３〜Ｓ６０５、図９のＳ９０１等）にユーザに、ユーザが選択したＯＰ機能と連携させるＲＰサービスを選択させる選択画面を端末１０６のＷｅｂブラウザ３２０等に表示し、該選択結果を受け付けるようにしてもよいし、ユーザによるＯＰ機能選択の際にＯＰ機能とＲＰサービスとの組み合わせをユーザに選択させるようにしてもよい。
また逆に、サービステーブルでは、複数のＯＰ権限に対して１のＲＰサービスを対応付けることも可能である。
【００６６】
次に、Ｓ４１０において、アクセス管理サーバ１０７は、上記Ｓ４０８で受け付けたクライアント登録要求のレスポンスとして、上記Ｓ４０８のクライアント登録結果を、端末１０６に返す。この場合、アクセス管理サーバ１０７は、クライアントＩＤ「ＩＤ００２」と、リダイレクトＵＲＩ「ｈｔｔｐｓ：／／００２．ｘｘ／ｒｅｓ」と、公開鍵「００２．ｃｅｒ」をレスポンスとして返す。
【００６７】
該レスポンスを受け取ると、端末１０６上のＷｅｂブラウザ３２０は、アクセス管理サーバ１０２から受け取ったレスポンス（クライアント登録結果）を、アクセス管理サーバ１０２に対してリダイレクトする（Ｓ４１１）。
【００６８】
該リダイレクトされたクライアント登録結果を受け取ると、アクセス管理サーバ１０２は、該受け取ったクライアント登録結果を基に、アクセス管理サーバ１０２のＯＰテーブル（例えば表５）に、ＯＰ情報を登録する（Ｓ４１２）。その際、ＯＰへの認証リクエストを行う認証エンドポイントＵＲＩをＯＰＩＤとして登録する。なお、認証エンドポイントＵＲＩは、上述したＳ４０３で受け付けてもよく、端末１０６のＷｅｂブラウザ３２０を介してアクセス管理サーバのホストに問い合わせを行って取得してもよい。
【００６９】
表５に、アクセス管理サーバ１０２が管理しているＯＰテーブルの例を示す。なお、アクセス管理サーバ１０７が管理しているＯＰテーブルは、アクセス管理サーバ１０７の二次記憶装置２０６に格納されているものとする。
【００７０】
【表５】
2016206971.tif 000007
【００７１】
表５に示すように、アクセス管理サーバ１０２が管理しているＯＰテーブルには、ＯＰＩＤ、クライアントＩＤ、ＯＰ名、リダイレクトＵＲＩ、公開鍵等が格納される。
本実施例では、認証エンドポイントＵＲＩが「ｈｔｔｐｓ：／／ｌｏｃａｌ／ａｕｔｈ」、ＯＰ名が「ＯＰ１」、クライアントＩＤが「ＩＤ００２」、リダイレクトＵＲＩが「ｈｔｔｐｓ：／／００２．ｘｘｘ／ｒｅｓ」、公開鍵が「００２．ｃｅｒ」として登録されたものとして説明する。
【００７２】
図６は、クライアント登録処理が完了しているＯＰサービスシステムとＲＰサービスシステム間でＪＩＴプロビジョニングを行う場合の処理を例示するフローチャートである。なお、このフローチャートに示す端末１０６の処理は、端末１０６のＣＰＵ２０３が二次記憶装置２０６等に格納されたプログラムを読み出して実行することにより実現される。同じくアクセス管理サーバ１０７の処理は、アクセス管理サーバ１０７のＣＰＵ２０３が二次記憶装置２０６等に格納されたプログラムを読み出して実行することにより実現される。同じくアクセス管理サーバ１０２の処理は、アクセス管理サーバ１０２のＣＰＵ２０３が二次記憶装置２０６等に格納されたプログラムを読み出して実行することにより実現される。
【００７３】
まず、ステップＳ６０１において、端末の利用者が端末１０６にアクセスすると、端末上の認証モジュール３２１が、ユーザが認証済みかを確認し、未認証の場合はアクセス管理サーバ１０７に対して認証を要求する。
この要求に応じて、アクセス管理サーバ１０７は、認証処理を行い（Ｓ６０２）、認証結果を端末１０６に返信する。本実施例では、ユーザＩＤ「ｕｓｅｒ２」で認証したものとする。なお、ユーザ認証済みの場合には、上記Ｓ６０２の認証は行われず、端末の利用者は、以下のＳ６０３に示すＯＰ機能選択が可能となる。
【００７４】
アクセス管理サーバ１０７での認証に成功すると、端末の利用者は、端末１０６上のＷｅｂブラウザ３２０またはアプリケーションモジュールを用いて、利用するＯＰ機能を指定する（Ｓ６０３）。本実施例では、「スキャン機能」が指定されたものとする。なお、この指定は、Ｗｅｂブラウザ３２０からリソースサーバ１０８に通知される。
上記Ｓ６０３の指定に応じて、リソースサーバ１０８は、アクセス管理サーバ１０７に対し、端末の利用者が指定された機能を利用する権限があるかの確認を要求する（Ｓ６０４）。
【００７５】
上記Ｓ６０４の要求に応じて、アクセス管理サーバ１０７は、上記Ｓ６０２で認証されたユーザが指定された機能を利用する権限があるかを判断し（Ｓ６０５）、該判断結果をリソースサーバ１０８に返す。本実施例では、ユーザＩＤ「ｕｓｅｒ２」のアカウントは、「スキャン」ロールと「印刷」ロールを持つため、「スキャン機能」が利用可能と判断される。なお、Ｓ６０３で選択されたＯＰ機能に対応するＲＰサービスが複数存在する場合には、アクセス管理サーバ１０７等が、上記Ｓ６０３でユーザが選択したＯＰ機能と連携させるＲＰサービスをユーザに選択させる選択画面を端末１０６のＷｅｂブラウザ３２０等に表示し、該選択結果を受け付けるようにしてもよいし、上記Ｓ６０３のＯＰ機能選択の際にＯＰ機能とＲＰサービスとの組み合わせをユーザに選択させるようにしてもよい。なお、ユーザにより選択されたＲＰサービスは、アクセス管理サーバ１０７等によりリソースサーバ１０８に通知されるものとする。
【００７６】
該判断結果を受け取ると、リソースサーバ１０８は、端末１０６に対して、ユーザ指定されたＯＰ側の機能が連携しているＲＰサービスシステム１０４へのリダイレクト指示と共に、該ユーザ指定された機能が連携しているＲＰサービスの利用要求を送る（Ｓ６０６）。リソースサーバ１０８の機能とリソースサーバ１０３のサービスとの連携は、図４に示したクライアント登録処理の中で設定を行ってもよく、事前に設定しておいてもよい。本実施例では、事前にスキャン機能とスキャンサービスの連携が設定されているものとし、Ｗｅｂブラウザ３２０を介してＲＰサービスシステム１０４に対して、スキャンサービスの利用要求を送るものとする。
【００７７】
該ＲＰサービス利用要求を受信すると、端末１０６上のＷｅｂブラウザ３２０は、アクセス管理サーバに対してＲＰサービスの利用要求をリダイレクトする（Ｓ６０７）。
該リダイレクトされたＲＰサービス利用要求を受けたアクセス管理サーバ１０２は、図７に示すようなＯＰ選択画面７００を表示し、認証リクエストを行うＯＰの選択を受け付け、アクセス管理サーバ１０７に認証要求を行う（Ｓ６０８）。なお、ＯＰ選択の際、フローチャートには示していないが、アクセス管理サーバ１０２は、ＯＰ選択画面７００を端末１０６のＷｅｂブラウザ３２０に送信し、該Ｗｅｂブラウザ上からＯＰの選択を受け付ける。
【００７８】
図７（Ａ）は、本実施例のＯＰ選択画面を例示する図であり、ＪＩＴプロビジョニングを行う際に利用される画面に対応する。
ＯＰ選択画面７００は、ＯＰ選択部７０１、選択ボタン７０２を有する。ＯＰ選択部７０１には、アクセス管理サーバ１０２のＯＰテーブルに登録されているＯＰから抽出された認証先のＯＰの一覧が表示され、該一覧から１つのＯＰが選択される。
【００７９】
なお、選択ボタン７０２が押下されると、端末１０６のＷｅｂブラウザ３２０は、ＯＰ選択画面７００で入力されたＯＰ選択情報を、アクセス管理サーバ１０２に送信し、アクセス管理サーバ１０２がこれを受信する。その後、アクセス管理サーバ１０２は、選択されたＯＰのＯＰＩＤが示す認証エンドポイントＵＲＩへのリダイレクト指示と共に、端末１０６に認証リクエストを送る。
【００８０】
なお、この認証リクエストには、登録されているクライアントＩＤと、登録されているリダイレクトＵＲＩと、ＯｐｅｎＩＤ Ｃｏｎｎｅｃｔを示すスコープ「ＯｐｅｎＩＤ」が含まれる。本実施例では、ＯＰＩＤ「ｈｔｔｐｓ：／／ｌｏｃａｌ／ａｕｔｈ」、ＯＰ名「ＯＰ１」を選択したものとする。この場合、認証エンドポイント「ｈｔｔｐｓ：／／ｌｏｃａｌ／ａｕｔｈ」に対して、クライアントＩＤ「ＩＤ００２」、リダイレクトＵＲＩ「ｈｔｔｐｓ：／／００２．ｘｘ／ｒｅｓ」、スコープ「ＯｐｅｎＩＤ」を含む認証リクエストを送る。
【００８１】
該認証リクエストを受信すると、端末１０６上のＷｅｂブラウザは、アクセス管理サーバ１０２から受け取った認証リクエストを、アクセス管理サーバ１０７にリダイレクトする（Ｓ６０９）。
該リダイレクトされた認証リクエストを受信すると、アクセス管理サーバ１０７は、認証リクエストのパラメーターを確認し、図７（Ｂ）のような認可確認画面７１０を表示してＲＰサービスへのユーザ情報提供の認可を行う（Ｓ６１０）。なお、ユーザ情報提供の認可確認の際、フローチャートには示していないが、アクセス管理サーバ１０２は、認可確認画面７１０を端末１０６のＷｅｂブラウザ３２０に送信し、該Ｗｅｂブラウザ上から認可確認結果を受け付ける。
【００８２】
図７（Ｂ）は、本実施例の認可確認画面を例示する図であり、ＪＩＴプロビジョニングを行う際に利用される画面に対応する。
認可確認画面７１０は、認可内容表示部７１１と、認可ボタン７１２、認可キャンセルボタン７１３を有する。なお、認可ボタン７１２が押下されると、端末１０６のＷｅｂブラウザ３２０は、認可確認画面７１０で認可されたことを示す情報を、アクセス管理サーバ１０７に送信し、アクセス管理サーバ１０７がこれを受信する。
【００８３】
次に、Ｓ６１１において、アクセス管理サーバ１０７は、表６に示すようなＩＤトークンを生成し、Ｘ．５０９形式の証明書から抽出した秘密鍵を利用して署名を行う。また、アクセス管理サーバ１０７は、上記Ｓ６１０で認可した情報に従い、表７に示すようなアクセストークンを生成する。その上でアクセス管理サーバ１０７は、リダイレクトＵＲＩへのリダイレクト指示と共に、上記Ｓ６１０で受けた認証リクエストのレスポンスとして、端末１０６に作成したＩＤトークンとアクセストークンを送る。
【００８４】
表６に、アクセス管理サーバ１０７のＩＤトークンテーブルの例を示す。
ＩＤトークンは、発行者情報ｉｓｓ、Ｓｕｂｊｅｃｔ識別子ｓｕｂ、ＩＤトークンの対象を示すａｕｄ、ＩＤトークン有効期限ｅｘｐ、ＩＤトークン発行時刻ｉａｔを含む。なお、Ｓｕｂｊｅｃｔ識別子ｓｕｂには、上記Ｓ６０２で認証したアカウントのＵＵＩＤ（上述の例では「０００００００３」）が設定される。
【００８５】
【表６】
2016206971.tif 000008
【００８６】
表７に、アクセス管理サーバ１０７のアクセストークンテーブルの例を示す。アクセストークンテーブルには、アクセストークンＩＤ、ユーザＩＤ、ＵＵＩＤ、有効期限等が含まれる。
【００８７】
【表７】
2016206971.tif 000009
【００８８】
本実施例では、ｓｕｂに「ｕｓｅｒ２」のＵＵＩＤである「０００００００３」を設定したＩＤトークンが発行され、リダイレクトＵＲＩ「ｈｔｔｐｓ：／／００２．ｘｘ／ｒｅｓ」にＩＤトークン及びアクセストークンが返される。
【００８９】
該ＩＤトークン及びアクセストークンをレスポンスとして受信した端末１０６上のＷｅｂブラウザ３２０は、アクセス管理サーバ１０７から受け取ったレスポンスを、指定されたリダイレクトＵＲＩに対してリダイレクトする（Ｓ６１２）。
【００９０】
該リダイレクトされたアクセス管理サーバ１０７からのレスポンスを受け取ったアクセス管理サーバ１０２は、アクセス管理サーバ１０２のＯＰテーブル（例えば表５）に登録されている公開鍵を利用し、ＩＤトークンの検証を行う（Ｓ６１３）。
【００９１】
次に、Ｓ６１４において、アクセス管理サーバ１０２は、ＩＤトークンを発行したＯＰのアカウントに対応するアカウントが登録されているかを確認する。
具体的には、アクセス管理サーバ１０２のアカウントテーブル（例えば表２）から、ＩＤトークンのｓｕｂと一致するＯＰ側ＵＵＩＤとなるアカウントが存在するかを確認する。もし対応するアカウントが登録されていると判定した場合（Ｓ６１４で「アカウントあり」の場合）、アクセス管理サーバ１０２は、Ｓ６１６に処理を進め、そのアカウントが実行しているものとして処理を継続する。一方、もしアカウントが登録されていないと判定した場合（Ｓ６１４で「アカウントなし」の場合）、アクセス管理サーバ１０２は、Ｓ６１５に処理を進める。上述した例では、アクセス管理サーバ１０２のアカウントテーブルから、ＯＰ側ＵＵＩＤ「０００００００３」と一致するアカウントは存在しないと判断され、Ｓ６１５へと進む。
【００９２】
Ｓ６１５において、アクセス管理サーバ１０２は、受け取ったＯＰのアカウントに対応するＲＰ側アカウントとして、システムが自動で決定したユーザＩＤとパスワードでアカウントを作成する。その上で、作成したアカウントが実行しているものとして処理を継続する。なお、このアカウント作成時にはサービスの利用権限は設定しない。本実施例では、ユーザＩＤ「ａｕｔｏ１」、パスワード「１２３４５」のアカウントを作成し、ＯＰ側ＵＵＩＤに「０００００００３」を登録する。
表８に、アカウント追加後のアカウントテーブルの例を示す。
【００９３】
【表８】
2016206971.tif 000010
【００９４】
次に、Ｓ６１６において、アクセス管理サーバ１０２は、処理を実行するアカウントに対象サービスの利用権限があるか否かを確認する。そして、利用する権限があると判定した場合には、アクセス管理サーバ１０２は、Ｓ６２７に処理を進め、処理を継続する。一方、利用権限が無いと判定した場合には、アクセス管理サーバ１０２は、Ｓ６１７に処理を進める。上述した例では、ユーザ「ａｕｔｏ１」は「スキャンサービス」の利用権限なしと判断される。
【００９５】
Ｓ６１７において、アクセス管理サーバ１０２は、ＯＰの認証エンドポイントＵＲＩへのリダイレクト指示と共に、端末１０６に権限確認要求を送る。権限確認要求には、アクセストークンおよび対象サービス情報が含まれる。なお、権限確認要求は、認証エンドポイントではなく、権限確認エンドポイントなど他のエンドポイントを指定してもよい。認証エンドポイント以外のエンドポイントは、図４のクライアント登録処理で設定してもよく、前述のＳ６１３で指定されてもよく、不図示の方法で別途登録してもよい。本実施例では、認証エンドポイント「ｈｔｔｐｓ：／／ｌｏｃａｌ／ａｕｔｈ」に対して、アクセストークン「ＡＢＣＤ１２３」を送り、スキャンサービスの権限確認要求を行う。
【００９６】
該権限確認要求を受信すると、端末１０６上のＷｅｂブラウザは、アクセス管理サーバ１０２から受け取った権限確認要求をリダイレクトする（Ｓ６１８）。
該リダイレクトされた権限確認要求を受信すると、アクセス管理サーバ１０７は、指定されたサービスの利用権限があるかを確認する（Ｓ６１９）。アクセス管理サーバ１０７は、アクセストークンテーブル（例えば表７）を用いて、権限確認要求に含まれるアクセストークンが有効か否かを確認し、発行ユーザ（例えばｕｓｅｒ２）を取得する。また、アクセス管理サーバ１０７は、サービステーブル（例えば表４）を用いて、権限確認要求に含まれるサービス（例えばスキャンサービス）に対応している権限（例えばスキャン）を確認する。その上で、アカウントテーブル（例えば表１）の情報から、アクセストークン発行ユーザが対象権限（例えば「スキャン」権限）を持っているかを確認する。
【００９７】
そして、もし権限を持っていいないと判定した場合（Ｓ６１９で「権限なし」の場合）、アクセス管理サーバ１０７は、Ｓ６２１に進み、権限なしを応答する。
Ｓ６２１において、アクセス管理サーバ１０２は、権限設定するサービス情報を含めないＩＤトークンを発行する。その上でアクセス管理サーバ１０２は、リダイレクトＵＲＩへのリダイレクト指示と共に、上記Ｓ６１９で受けた権限確認要求のレスポンスとして、端末１０６に作成したＩＤトークンを送る。
【００９８】
一方、もし権限を持っていると判定した場合（Ｓ６１９で「権限あり」の場合）、アクセス管理サーバ１０７は、Ｓ６２０に処理を進め、権限設定要求を行う。
本実施例では、アクセストークン「ＡＢＣＤ１２３」から、発行ユーザ「ｕｓｅｒ２」が取得される。そしてサービステーブルから、「スキャンサービス」に対応するＯＰ権限は「スキャン」と判定される。その上でアカウントテーブルから、「ｕｓｅｒ２」は「スキャン」権限を持つため、指定された「スキャンサービス」の利用権限ありと判断され、Ｓ６２０に移行する。
【００９９】
Ｓ６２０において、アクセス管理サーバ１０２は、権限設定するサービス情報を含めたＩＤトークンを発行する。その上でアクセス管理サーバ１０２は、リダイレクトＵＲＩへのリダイレクト指示と共に、上記Ｓ６１９で受けた権限確認要求のレスポンスとして、端末１０６に作成したＩＤトークンを送る。本実施例では、対象サービスとして「スキャンサービス」を含んだＩＤトークンが発行される。
【０１００】
該レスポンスを受信した端末１０６上のＷｅｂブラウザは、アクセス管理サーバ１０７から受け取ったレスポンスを、指定されたリダイレクトＵＲＩに対してリダイレクトする（Ｓ６２２）。
該リダイレクトされたレスポンスを受信したアクセス管理サーバ１０２は、アクセス管理サーバ１０２のＯＰテーブルに登録されている公開鍵を利用し、ＩＤトークンの検証を行う（Ｓ６２３）。
【０１０１】
次に、Ｓ６２４において、アクセス管理サーバ１０２は、ＩＤトークンに権限設定するサービス情報が含まれているか否かを確認する。
そして、権限設定するサービス情報が含まれていないと判定した場合（Ｓ６２４で「権限なし」の場合）、アクセス管理サーバ１０２は、Ｓ６２６に処理を進め、上記Ｓ６１３で受けたサービス利用要求のレスポンスとして、端末１０６に権限なしエラーを生成して送る。
【０１０２】
一方、権限設定するサービス情報が含まれていると判定した場合（Ｓ６２４で「権限あり」の場合）、アクセス管理サーバ１０２は、Ｓ６２５に処理を進め、指定された権限を設定し、処理を継続する。本実施例では、アカウントテーブルの対応アカウント（ａｕｔｏ１）に「スキャンサービス」の設定情報が含まれているため、アクセス管理サーバ１０２は、Ｓ６２５において、ユーザ「ａｕｔｏ１」にスキャンサービス利用権限を設定する。
表９に、権限追加後のアカウントテーブルの例を示す。
【０１０３】
【表９】
2016206971.tif 000011
【０１０４】
Ｓ６２７において、リソースサーバ１０３は、要求されたＲＰリソース（例えばスキャンサービス）を提供する。その後、リソースサーバ１０３は、上記Ｓ６１３で受けたサービス利用要求のレスポンスとして、サービス利用による処理結果を、端末１０６に処理結果を送る。本実施例では、「スキャンサービス」の処理を行い、生成した処理結果を送る。
【０１０５】
該レスポンスを受信すると、端末１０６上のＷｅｂブラウザは、リソースサーバ１０３から受け取ったレスポンスを、リソースサーバ１０８にリダイレクトする（Ｓ６２８）。
該リダイレクトされたレスポンスを受信すると、リソースサーバ１０８は、受け取ったレスポンスを基に、ＯＰリソースの提供を行う（Ｓ６２９）。
【０１０６】
以上示したように、実施例１によれば、ＲＰサービス利用時に、ＯＰサービスシステムの認証情報からＲＰサービスの利用権限が自動で設定される。これにより、前もってＲＰサービスシステム側のアカウントにサービス利用権限を設定していなくとも、必要なタイミングでサービス利用権限が設定されるようになる。
よって、連携元のアカウントが利用できない機能が連携先のアカウントで利用出来るようになってしまう等の不要な権限が設定されてしまうことを防止できる。また、連携先のアカウントの利用権限を無駄に消費してしまうことも防止できる。
【実施例２】
【０１０７】
実施例２では、ＯＰサービスシステムからのログアウトと、ＲＰサービスシステムの権限削除を連携させる形態について説明する。
【０１０８】
図８は、ＯＰサービスシステムからログアウトを行う際の処理を例示するフローチャートである。なお、このフローチャートに示す端末１０６の処理は、端末１０６のＣＰＵ２０３が二次記憶装置２０６等に格納されたプログラムを読み出して実行することにより実現される。同じくアクセス管理サーバ１０７の処理は、アクセス管理サーバ１０７のＣＰＵ２０３が二次記憶装置２０６等に格納されたプログラムを読み出して実行することにより実現される。同じくアクセス管理サーバ１０２の処理は、アクセス管理サーバ１０２のＣＰＵ２０３が二次記憶装置２０６等に格納されたプログラムを読み出して実行することにより実現される。
【０１０９】
なお、本処理の実行時には、ＯＰサービスシステム１０９とＲＰサービスシステム１０４が図６に示した処理により連携しているものとする。その上で、アクセス管理サーバ１０７のアカウント「ｕｓｅｒ２」に対応するアカウントとして、アクセス管理サーバ１０２に「ａｕｔｏ１」が作成され、「スキャンサービス」利用権限が設定されているものとする。
【０１１０】
ステップＳ８０１において、端末の利用者が、端末１０６からログアウト操作を実行すると、端末上の認証モジュール３２１が、アクセス管理サーバに対してログアウトを要求する。本実施例では、「ｕｓｅｒ２」で認証済みの利用者がログアウト操作を実行したものとする。
【０１１１】
該ログアウトの要求を受けると、アクセス管理サーバ１０７は、アクセス管理サーバ１０７のアカウントテーブル（例えば表１）から、ログアウトしようとしているユーザの持つ権限を確認する（Ｓ８０２）。本実施例では、「ｕｓｅｒ２」は「スキャン」と「印刷」権限を持つと判断される。
【０１１２】
次に、Ｓ８０３において、アクセス管理サーバ１０７は、サービステーブル（例えば表４）から、対象アカウントが持つ権限と対応するＲＰサービスを特定し、権限削除するサービス情報を含めたＩＤトークンを発行する。その上で、アクセス管理サーバ１０７は、端末１０６に対するリダイレクト指示と共に、ＲＰサービスシステム１０４に対して、利用権限の削除要求（以下、権限削除要求）を送る。本実施例では、削除するサービスとして「スキャンサービス」と「印刷サービス」を含んだＩＤトークンが発行されるものとする。
【０１１３】
該権限削除要求を受信すると、端末１０６上のＷｅｂブラウザ３２０は、アクセス管理サーバ１０７から受け取った権限削除要求を、アクセス管理サーバ１０２にリダイレクトする（Ｓ８０４）。
該リダイレクトされた権限削除要求を受信すると、アクセス管理サーバ１０２は、アクセス管理サーバ１０２のＯＰテーブルに登録されている公開鍵を利用し、受信した権限削除要求に含まれるＩＤトークンの検証を行う（Ｓ８０５）。
【０１１４】
次に、Ｓ８０６において、アクセス管理サーバ１０２は、上記ＩＤトークンから権限削除対象アカウントと権限削除サービス情報を取得し、対象のアカウントから権限削除を行う。本実施例では、アクセス管理サーバ１０２のアカウントテーブル（例えば表９）から、ＯＰ側ＵＵＩＤ「０００００００３」と一致するアカウント「ａｕｔｏ１」が権限削除対象アカウントと判断される。その上で、アカウント「ａｕｔｏ１」からスキャンサービスの利用権限が削除される。
【０１１５】
次に、Ｓ８０７において、アクセス管理サーバ１０２は、上記Ｓ８０５で受けた権限削除要求のレスポンスとして、端末１０６に処理結果を送る。
該処理結果を受信すると、端末１０６上のＷｅｂブラウザ３２０は、アクセス管理サーバ１０２から受け取ったレスポンスを、アクセス管理サーバ１０７にリダイレクトする（Ｓ８０８）。
【０１１６】
該リダイレクトされた処理結果を受信すると、アクセス管理サーバ１０７は、対象アカウントのログアウト処理を行う（Ｓ８０９）。なお、アクセス管理サーバ１０７でのログアウト処理は、上記Ｓ８０３の時点で行ってもよい。その場合、本ステップではログアウトは行わないものとする。
【０１１７】
以上示したように、実施例２によれば、ＯＰサービスシステムのアカウントの権限を基に、ＲＰサービスシステムのアカウントの権限を自動で設定するシステムにおいて、ＯＰサービスシステムからのログアウト時に、自動で設定した権限を外すことができる。これにより、利用していないアカウントから権限を外すことができる。クラウドサービスにおいては、サービスを利用できるアカウント数が制限されている場合があるが、本実施例により、このような場合においても、サービスを利用できるアカウント数を最適にすることができる。
よって、実施例１の効果に加え、連携先のアカウントの利用権限の無駄をさらに防止することができる。
【実施例３】
【０１１８】
実施例３では、連携元の端末上のアカウントが異なるサービスと連携する複数の機能の利用権限（スキャンと印刷の利用権限）を持っている場合、これらの機能を連続して利用する形態について説明する。
【０１１９】
図９は、端末１０６から複数の機能を連続して利用する場合の処理を例示するフローチャートである。なお、このフローチャートに示す端末１０６の処理は、端末１０６のＣＰＵ２０３が二次記憶装置２０６等に格納されたプログラムを読み出して実行することにより実現される。同じくアクセス管理サーバ１０７の処理は、アクセス管理サーバ１０７のＣＰＵ２０３が二次記憶装置２０６等に格納されたプログラムを読み出して実行することにより実現される。同じくアクセス管理サーバ１０２の処理は、アクセス管理サーバ１０２のＣＰＵ２０３が二次記憶装置２０６等に格納されたプログラムを読み出して実行することにより実現される。
【０１２０】
なお、本処理は、ＯＰサービスシステム１０９とＲＰサービスシステム１０４が図６に示した処理により連携しているものとする。その上で、アクセス管理サーバ１０７のアカウント「ｕｓｅｒ２」に対応するアカウントとして、アクセス管理サーバ１０２に「ａｕｔｏ１」が作成され、「スキャンサービス」利用権限が設定されているものとする。
【０１２１】
図６の処理の後、ステップＳ９０１において、端末の利用者が、端末１０６上のＷｅｂブラウザ３２０またはアプリケーションモジュールを用いて、図６のＳ６０３で選択した機能に続いて、さらに利用しようとするＯＰ機能を指定する（Ｓ９０１）。本実施例では、「印刷機能」が指定されたものとする。なお、この指定は、Ｗｅｂブラウザ３２０からリソースサーバ１０８に通知される。
上記Ｓ９０１の指定に応じて、リソースサーバ１０８は、アクセス管理サーバ１０７に対し、端末の利用者が指定された機能を利用する権限があるかの確認を要求する（Ｓ９０２）。
【０１２２】
上記Ｓ９０２の要求に応じて、アクセス管理サーバ１０７は、図６のＳ６０２で認証されたユーザが指定された機能を利用する権限があるかを判断し（Ｓ９０３）、該判断結果をリソースサーバ１０８に返す。本実施例では、ユーザＩＤ「ｕｓｅｒ２」のアカウントは、「スキャン」ロールと「印刷」ロールを持つため、「印刷機能」が利用可能と判断される。
【０１２３】
該判断結果を受け取ると、リソースサーバ１０８は、端末１０６に対して、ユーザ指定されたＯＰ側の機能が連携しているＲＰサービスシステム１０４へのリダイレクト指示と共に、該ユーザ指定された機能が連携しているＲＰサービスの利用要求を送る（Ｓ９０４）。
該ＲＰサービス利用要求を受信すると、端末１０６上のＷｅｂブラウザ３２０は、アクセス管理サーバに対してＲＰサービスの利用要求をリダイレクトする（Ｓ９０５）。
【０１２４】
該リダイレクトされたＲＰサービス利用要求を受けたアクセス管理サーバ１０２は、図６の処理の際に既にＯＰ選択済み及びＯＰ認証済みであるため、Ｓ９０６に処理を進める。Ｓ９０６において、アクセス管理サーバ１０２は、認証済みのＯＰ側アカウントに対応するＲＰ側アカウントに、利用要求されたサービス（対象サービス）の利用権限があるか否かを確認する。そして、利用する権限があると判定した場合には、アクセス管理サーバ１０２は、Ｓ９１７に処理を進め、処理を継続する。一方、利用権限が無いと判定した場合には、アクセス管理サーバ１０２は、Ｓ９０７に処理を進める。上述した例では、ユーザ「ａｕｔｏ１」は「印刷サービス」の利用権限なしと判断される。
【０１２５】
Ｓ９０７において、アクセス管理サーバ１０２は、ＯＰの認証エンドポイントＵＲＩへのリダイレクト指示と共に、端末１０６に権限確認要求を送る。権限確認要求には、上記ＯＰ認証時に取得したアクセストークンおよび対象サービス情報が含まれる。本実施例では、認証エンドポイント「ｈｔｔｐｓ：／／ｌｏｃａｌ／ａｕｔｈ」に対して、アクセストークン「ＡＢＣＤ１２３」を送り、スキャンサービスの権限確認要求を行う。
なお、Ｓ９０８〜Ｓ９１９は、図６のＳ６１８〜Ｓ６２９と同一の処理であるので説明は省略する。
【０１２６】
なお、本図９の処理の後、さらに他の機能を連続して利用する場合には、本図９の処理を繰り返すものとする。
また、Ｓ９０５においてリダイレクトされる、ＲＰサービスの利用要求を受信したＲＰサービスシステムが図６で利用されたサービスを提供するＲＰサービスシステムとは別のＲＰサービスシステムである場合やタイムアウト等によりＯＰ未認証である場合には、該ＲＰサービスシステムのアクセス管理サーバは、該ＲＰサービスの利用要求の受信に応じて、図６のＳ６０８の認証要求を行い、以降、図６のＳ６０９〜Ｓ６２９と同様の処理が行われるものとする。
【０１２７】
以上示したように、実施例３によれば、連続して異なるＲＰサービスを利用する場合であっても、該ＲＰサービスシステム側に対象サービスの利用権限がないことをトリガーとして、ＲＰサービスの利用権限を該ＲＰサービスシステムに自動設定できる。これにより、前もってＲＰサービスシステム側のアカウントに複数のサービス利用権限を設定していなくとも、必要なタイミングでサービス利用権限が設定されるようになる。
よって、実施例１、２の効果に加えて、連続して異なるサービスを利用することも可能となる。
【０１２８】
以上の実施例に示したシステムは、複数のサービスが連携しているシステムであって、連携先サービスを利用する時に、ＯｐｅｎＩＤ Ｃｏｎｎｅｃｔの仕組みを利用し、連携元サービス上のアカウントの権限を確認し、連携元サービスのアカウントに連携先サービスを利用する権限があった場合、連携先サービスのアカウントにサービス利用権限を設定する権限のＪｕｓｔ−ｉｎ−Ｔｉｍｅプロビジョニングシステムである。この構成により、複数のサービスが連携しており、連携元サービス（ＯＰサービスシステム１０９）にはアカウントがあるが、連携先サービス（ＲＰサービスシステム１０４）には連携対応するアカウントがないという場合に、自動で連携先サービスに連携用アカウントを作成し、サービス連携を提供することができる。したがって、連携先サービスにおける必要な権限を必要なタイミングで適切に設定することができる。
【０１２９】
なお、上述した各種データの構成及びその内容はこれに限定されるものではなく、用途や目的に応じて、様々な構成や内容で構成されることは言うまでもない。
以上、一実施形態について示したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記憶媒体等としての実施態様をとることが可能である。具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
また、上記各実施例を組み合わせた構成も全て本発明に含まれるものである。
【０１３０】
（その他の実施例）
本発明は、上述の実施例の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
また、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用してもよい。
本発明は上記実施例に限定されるものではなく、本発明の趣旨に基づき種々の変形（各実施例の有機的な組合せを含む）が可能であり、それらを本発明の範囲から除外するものではない。即ち、上述した各実施例及びその変形例を組み合わせた構成も全て本発明に含まれるものである。
【符号の説明】
【０１３１】
１０２    アクセス管理サーバ
１０３    リソースサーバ
１０４    ＲＰサービスシステム
１０６    端末
１０７    アクセス管理サーバ
１０８    リソースサーバ
１０９    ＯＰサービスシステム
【図１】
2016206971.tif 000012
【図２】
2016206971.tif 000013
【図３】
2016206971.tif 000014
【図４】
2016206971.tif 000015
【図５】
2016206971.tif 000016
【図６】
2016206971.tif 000017
【図７】
2016206971.tif 000018
【図８】
2016206971.tif 000019
【図９】
2016206971.tif 000020