(57)【要約】【課題】認証サーバを別途設置することなく、端末への一度のログイン操作で端末利用者が各種機能を提供するサーバとシングルサインオンを実現することを可能とするシングルサインオンシステムを提供すること。【解決手段】情報処理装置４００は、自装置に対するログイン操作を受け付けて認可サーバ２００に認証連携要求を送信し、認可サーバ２００から第１の認証要求を受け付けたことに起因して第２の認証要求をサービス提供サーバ３００に送信し、サービス提供サーバ３００による第２の認証要求への応答に起因して、第３の認証要求をサービス提供サーバ３００に送信し、第３の認証要求に応答したサービス提供サーバ３００から、認可コードを含む認可サーバへのリダイレクト指示を受信し、リダイレクトに含まれる認可コードを用いて認証トークンを生成した認可サーバ２００から、認証トークンを含む認証連携要求に対する応答を受信する。【選択図】図１
2016009299.tif 000002
【特許請求の範囲】
【請求項１】
ユーザ認証を実行する認可サーバとウェブサービスを提供するサービス提供サーバとを備えるシステムを介して前記ウェブサービスを利用する情報処理装置であって、
自装置に対するログイン操作を受け付けて前記認可サーバに認証情報を含む認証連携要求を送信する第１の送信手段と、
前記認証連携要求に対し、前記認可サーバから第１の認証要求を受け付けたことに起因して、第２の認証要求を前記サービス提供サーバに送信する第２の送信手段と、
前記サービス提供サーバによる、第１のＩＤトークンを含む前記第２の認証要求への応答に起因して、該第１のＩＤトークンを含む第３の認証要求を前記サービス提供サーバに送信する第３の送信手段と、
前記第３の認証要求に応答した前記サービス提供サーバから、認可コードを含む前記認可サーバへのリダイレクト指示を受信する第１の受信手段と、
前記リダイレクトに含まれる前記認可コードを用いて認証トークンを生成した前記認可サーバから、前記認証トークンを含む前記認証連携要求に対する応答を受信する第２の受信手段と、を備える
ことを特徴とする情報処理装置。
【請求項２】
前記第２の認証要求は、前記情報処理装置を前記サービス提供サーバが認証を行う要求であり、前記サービス提供サーバによるシングルサインオン設定において前記サービス提供サーバにより発行された少なくとも情報処理装置の識別情報およびシークレットを含む
ことを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記第３の認証要求は、ユーザによる操作なしに前記サービス提供サーバにログインするための代理認証要求である
ことを特徴とする請求項１または２に記載の情報処理装置。
【請求項４】
ユーザ操作を受け付けて複数の情報処理装置をテナント毎に紐付けて前記認可サーバに登録要求を行う登録手段をさらに備える
ことを特徴とする請求項１乃至３のいずれか一項に記載の情報処理装置。
【請求項５】
前記登録要求に応答した前記認可サーバから、前記代理認証を実行させることを認可させる認可確認画面を受信して表示する表示手段を備え、
前記認可確認画面に対するユーザ操作の結果、前記認可サーバと前記サービス提供サーバとの間では、前記代理認証を実現させる設定が実行される
ことを特徴とする請求項４に記載の情報処理装置。
【請求項６】
前記表示手段は、前記テナントが複数登録されている場合は、前記設定画面に前記複数のテナントのいずれか一つを選択するための選択肢をさらに表示する
ことを特徴とする請求項４または５に記載の情報処理装置。
【請求項７】
ユーザ認証を実行する認可サーバと、ウェブサービスを提供するサービス提供サーバと、前記ウェブサービスを利用する情報処理装置を備えるシングルサインオンシステムであって、
前記情報処理装置は、
前記サービス提供サーバに対するログイン操作を受け付けて前記認可サーバに認証情報を含む認証連携要求を送信する第１の送信手段と、
前記認証連携要求に対し、前記認可サーバから第１の認証要求を受け付けたことに起因して、第２の認証要求を前記サービス提供サーバに送信する第２の送信手段と、
前記サービス提供サーバによる、第１のＩＤトークンを含む前記第２の認証要求への応答に起因して、該第１のＩＤトークンを含む第３の認証要求を前記サービス提供サーバに送信する第３の送信手段と、
前記第３の認証要求に応答した前記サービス提供サーバから、認可コードを含む前記認可サーバへのリダイレクト指示を受信する第１の受信手段と、
前記リダイレクトに含まれる前記認可コードを用いて認証トークンを生成した前記認可サーバから、前記認証トークンを含む前記認証連携要求に対する応答を受信する第２の受信手段とを備え、
前記認可サーバは、
前記認可コードを受信して該認可コードを送信することにより第２のＩＤトークンを前記サービス提供サーバから受信し、該第２のＩＤトークンを用いて前記認証トークンを生成する生成手段を備え、
前記サービス提供装置は、
前記第１および第２のＩＤトークンを生成する生成手段を備える
ことを特徴とする情報処理装置。
【請求項８】
ユーザ認証を実行する認可サーバとウェブサービスを提供するサービス提供サーバとを備えるシステムを介して前記ウェブサービスを利用する情報処理装置の制御方法であって、
前記情報処理装置に対するログイン操作を受け付けて前記認可サーバに認証情報を含む認証連携要求を送信する送信工程と、
前記認証連携要求に対し、前記認可サーバから第１の認証要求を受け付けたことに起因して、第２の認証要求を前記サービス提供サーバに送信する送信工程と、
前記サービス提供サーバによる、第１のＩＤトークンを含む前記第２の認証要求への応答に起因して、該第１のＩＤトークンを含む第３の認証要求を前記サービス提供サーバに送信する送信工程と、
前記第３の認証要求に応答した前記サービス提供サーバから、認可コードを含む前記認可サーバへのリダイレクト指示を受信する受信工程と、
前記リダイレクトに含まれる前記認可コードを用いて認証トークンを生成した前記認可サーバから、前記認証トークンを含む前記認証連携要求に対する応答を受信する第２の受信工程と、を有する
ことを特徴とする制御方法。
【請求項９】
請求項８に記載の制御方法をコンピュータにより実行させることを特徴とするコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、端末およびサーバから構成されるシングルサインオンシステムに関する。より詳細には、端末への信頼に基づいて端末の認証方式を問わずに端末がサーバへシングルサインオンする方法およびコンピュータプログラムに関する。
【背景技術】
【０００２】
近年、企業内に設置された端末、例えば、ＰＣ、タブレットや画像形成装置が、インターネット上に展開された所謂クラウドサービスと連携し、ユーザに各種機能を提供するシステムが提供されている。各端末は、クラウドサービスと連携する事によって、端末自身が持つ機能だけではなく、クラウドサービスの機能をもユーザに提供する事が可能である。一般的に、企業内に設置された端末やインターネット上に展開されたクラウドサービスを利用するためには、不正利用の防止やユーザを識別するために、ユーザ認証が必要である。従って、ユーザには端末とクラウドサービスの両方への認証情報の入力が必要とされ、利便性にかけるという課題がある。
【０００３】
この課題を解決する手段として、複数の認証システムが連携することで、１度の認証の結果をもって、複数の認証を受ける事ができるシングルサインオン技術の利用が広がっている。例えば、Ｓｅｃｕｒｉｔｙ  Ａｓｓｅｒｔｉｏｎ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ（以下ＳＡＭＬ）プロトコルの技術が知られている。また、ＯｐｅｎＩＤ  Ｆｏｕｎｄａｔｉｏｎ（ｈｔｔｐ：／／ｏｐｅｎｉｄ．ｎｅｔ／ｆｏｕｎｄａｔｉｏｎ／）が規定しているＯｐｅｎＩＤ  Ｃｏｎｎｅｃｔといった技術が知られている。
【０００４】
また、端末とクラウドサービスにおいてシングルサインオンを実現するために特許文献１は以下のシングスサインオンシステムを開示している。特許文献１が開示するシングスサインオンシステムでは、利用者端末のＯＳにてユーザ認証するための認証サーバ装置と、クラウドサービス側に備えた認証連携基盤装置とが認証情報を共有することでシングルサインオンを実現している。
【０００５】
上記従来技術では、端末でのユーザ認証を行うサーバ装置、つまり認証サーバが提供され、この認証サーバがクラウド−サービスとシングルサインオンをするための仕組みを提供する事で課題を解決している。つまり、端末は認証サーバが備える認証手段を用いてユーザ認証する必要がある。
【０００６】
一方、近年、セキュリティの確保およびユーザの利便性向上のために、ユーザを認証する手段として様々な手段が利用されている。例えば、指紋等の生体情報を利用する認証手段や、非接触型のＩＣカードを利用する手段、さらには、複数の認証手段を組み合わせる多要素認証手段、等がある。これら認証手段を備えた端末を利用する場合、従来技術、つまり、端末での認証を認証サーバで行う場合は、認証サーバがこれら複数の認証手段に対応する必要がある。特に、新しい認証手段を備えた端末を利用する場合は、そのたびに、認証サーバが新しい認証手段に対応しなければならないという課題がある。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２０１３−８１４０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
従来技術により、端末の認証を行う認証サーバと、クラウドサービス間で連携する事によってシングルサインオンを実現する事は可能である。しかしながら、従来技術においては、端末と連携する認証サーバが必要であり、かつ、端末の認証手段として、認証サーバが対応可能な認証手段しか選択できないという課題がある。
【０００９】
本発明は、認証サーバを別途設置することなく、端末への一度のログイン操作で端末利用者が各種機能を提供するサーバとシングルサインオンを実現することを可能とする仕組みを提供することを目的とする。
【課題を解決するための手段】
【００１０】
本発明の一実施形態の情報処理装置は、ユーザ認証を実行する認可サーバとウェブサービスを提供するサービス提供サーバとを備えるシステムを介して前記ウェブサービスを利用する。前記情報処理装置は、自装置に対するログイン操作を受け付けて前記認可サーバに認証情報を含む認証連携要求を送信する第１の送信手段と、前記認証連携要求に対し、前記認可サーバから第１の認証要求を受け付けたことに起因して、第２の認証要求を前記サービス提供サーバに送信する第２の送信手段と、前記サービス提供サーバによる、第１のＩＤトークンを含む前記第２の認証要求への応答に起因して、該第１のＩＤトークンを含む第３の認証要求を前記サービス提供サーバに送信する第３の送信手段と、前記第３の認証要求に応答した前記サービス提供サーバから、認可コードを含む前記認可サーバへのリダイレクト指示を受信する第１の受信手段と、前記リダイレクトに含まれる前記認可コードを用いて認証トークンを生成した前記認可サーバから、前記認証トークンを含む前記認証連携要求に対する応答を受信する第２の受信手段と、を備える。
【発明の効果】
【００１１】
本発明によれば、認証サーバを別途設置することなく、端末への一度のログイン操作で端末利用者が各種機能を提供するサーバとシングルサインオンを実現することが可能となる。本発明においては、端末利用者が、端末からクラウドサービスを利用する際に、端末にて認証されている事をもってクラウドサービスに対してシングルサインオンが実現される。従って、認証サーバ装置を別途設ける必要がなく、また端末の認証手段に関して制限を設ける必要もないため、シングスサインオンシステムにおけるユーザの利便性が向上する。
【図面の簡単な説明】
【００１２】
【図１】シングルサインオンシステムの全体構成例を示す図である。
【図２】各装置のハードウェア構成例を示す図である。
【図３】各装置のソフトウェアモジュール構成例を示す図である。
【図４】端末装置に表示される各種画面例を示す図である。
【図５】クライアント登録のシーケンスを示す図である。
【図６】シングルサインオン設定のシーケンスを示す図である。
【図７】シングルサインオン設定のシーケンスを示す図である。
【図８】端末装置に表示される各種画面例を示す図である。
【図９】シングルサインオンを行う際のシーケンスを示す図である。
【図１０】シングルサインオンを行う際のシーケンスを示す図である。
【図１１】組織選択画面例を示す図である。
【発明を実施するための形態】
【００１３】
以下、本発明を実施するための形態について図面を用いて説明する。本実施形態において、端末利用者が、端末からクラウドサービスを利用する際に、端末にて認証されている事をもってシングルサインオンを実現する。シングルサインオンを実現するためには、以下の処理が事前に必要となる。
【００１４】
まず、第一の設定として、端末の管理者が、クラウドサービスにてシングルサインオンをするための設定を実施する。これは、ＯｐｅｎＩＤ  Ｃｏｎｎｅｃｔでいうところの、ＯＰ（ＯｐｅｎＩＤ  Ｐｒｏｖｉｄｅｒ）、およびＲＰ（Ｒｅｌｙｉｎｇ  Ｐａｒｔｙ）の設定である。本実施形態では、シングルサインオン技術として、ＯｐｅｎＩＤ  Ｃｏｎｎｅｃｔを利用して説明するが、プロトコルを限定するわけではない。例えば、シングルサインオン技術であれば、ＳＡＭＬやＯｐｅｎＩＤを用いる事も可能である。
【００１５】
第二の設定として、端末をクラウドサービスに登録し、当該端末であることを証明するための情報を取得しておく必要がある。この情報は、ＯＡｕｔｈ  ２．０の場合、端末を識別するための識別情報であるクライアントＩＤおよびクライアントシークレットである。本実施形態では、この端末登録の方法として、ＳＳＬ／ＴＬＳのＸ．５０９証明書を用いたクライアント認証を用いて、端末自身が能動的に登録処理を実施し、クライアントＩＤ、クライアントシークレットを取得するフローで説明する。しかしながら、手段を限定するわけではない。例えば、端末がＩＤ、パスワード、何かしらのトークンを用いてクライアント認証をうけ、動的に登録処理するよう構成する事もできる。さらに、管理者が、別手段で取得したクライアントＩＤ、クライアントシークレットを端末に登録する構成でも登録を実現する事ができる。
【００１６】
そして、第三の設定として、端末の管理者が、端末がクラウドサービスとシングルサインオンする事を許可するための設定をする。ここで先ほど取得したクライアントＩＤ、クライアントシークレットを用いた、ＯＡｕｔｈ  ２．０をプロトコルとして許可するための処理を説明するが、プロトコルを限定するわけではない。例えば、取得したクライアントＩＤ、クライアントシークレットを用いたＢａｓｉｃ認証によって、端末自身が許可を得るよう構成する事も可能である。本実施の形態では、これら第一、第二、第三の設定を順次説明し、その後に、端末利用者によるシングルサインオン処理について説明する。
【００１７】
図１は、本発明の一実施形態のシングルサインオンシステムの全体構成例を示す。シングルサインオンシステムは、認可サーバ２００、シングルサインオンサーバ３００、端末４００、データベースサーバ５００を備える。認可サーバ２００、シングルサインオンサーバ３００及びデータベースサーバ５００は、ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）１０１により接続されている。認可サーバ２００、シングルサインオンサーバ３００及びデータベースサーバ５００は単一のサーバから構成されてよく、その場合、複数のウェブサービスを提供するシステムとして機能する。また、端末４００は、ＬＡＮ１０１によりＷＡＮ（Ｗｉｄｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）１００に接続され、ＷＡＮ１００を介して各サーバと接続される。本発明ではＷｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂ（ＷＷＷ）システムが構築されている。
【００１８】
認可サーバ２００は、ＯＡｕｔｈ  ２．０を実現するためのサーバである。シングルサインオンサーバ３００は認可サーバ２００とシングルサイオンを実現するためのサーバであり、ウェブサービスを提供するサービス提供サーバとして機能する場合もある。端末４００は一つまたは複数の端末であり、ＰＣや、スマートフォンやタブレットと呼ばれる携帯端末や、画像形成装置であり、端末利用者を認証するための認証モジュールを備える。この認証モジュールは不図示の認証サーバと通信することで端末利用者を認証するよう構成する事もできる。さらに、端末４００は、Ｗｅｂブラウザと、アプリケーションモジュールとを備える。ユーザは、Ｗｅｂブラウザやアプリケーションモジュールを用いて認可サーバ２００およびシングルサインオンサーバ３００と通信する。
【００１９】
データベースサーバ５００は、後述の認可モジュール６００やシングルサインオンモジュール７００が利用するデータを格納する。なお、データベースサーバ５００は、認可サーバ２００用と、シングルサインオンサーバ３００用で別サーバとして構成されてもよい。また、認可サーバ２００、シングルサインオンサーバ３００は同一のサーバ上に構成されていてもよい。また、データベースサーバ５００についても、認可サーバ２００、シングルサインオンサーバ３００と同一のサーバ上に構成されてもよい。
【００２０】
本実施形態に係るシングルサインオンシステムは、図２に示すような構成のサーバおよび端末から成るシステム上に実現される。図２は、認可サーバ２００、シングルサインオンサーバ３００、端末４００のハードウェア構成例を示す。図２に示されるハードウェアブロック図は一般的な情報処理装置のハードウェアブロック図に相当するものとし、本実施形態の各サーバおよび端末には一般的な情報処理装置のハードウェア構成を適用できる。
【００２１】
図２に示すハードウェア構成は、ＣＰＵ２０１乃至外部メモリ２１１を備える。ＣＰＵ２０１は、システムバス２０４に接続された各処理部を統合的に制御する。ＣＰＵ２０１は、ＲＯＭ２０３のプログラム用ＲＯＭに記憶、またはハードディスク（ＨＤ）等の外部メモリ２１１からＲＡＭ２０２にロードされたＯＳやアプリケーション等のプログラムを実行する。ＲＡＭ２０２は、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。ＲＯＭ２０３は、フォントＲＯＭ、プログラムＲＯＭ、データＲＯＭ等から構成される。ＣＰＵ、ＲＯＭおよびＲＡＭはそれぞれ、Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ、Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ、Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙの略称である。ＯＳは、コンピュータ上で稼動するオペレーティングシステムの略語であり、以下オペレーティングシステムのことをＯＳと呼ぶ。後述する各シーケンスの処理は、上述のプログラムをＣＰＵ２０１が実行することにより実現される。
【００２２】
キーボードコントローラ（ＫＢＣ）２０５は、キーボード２０９や不図示のポインティングデバイスからのキー入力を制御する。ＣＲＴコントローラ（ＣＲＴＣ）２０６は、ＣＲＴディスプレイ２１０の表示を制御する。ディスクコントローラ（ＤＫＣ）２０７は、各種データを記憶するハードディスク（ＨＤ）等の外部メモリ２１１に格納されたデータへのアクセスを制御する。ネットワークコントローラ（ＮＣ）２０８は、ＷＡＮ１００、ＬＡＮ１０１、もしくは公衆回線１０２を介して接続された他の機器との通信制御処理を実行する。
【００２３】
尚、後述の全ての説明においては、特に断りのない限りサーバにおける実行のハード上の主体はＣＰＵ２０１であり、ソフトウェア上の主体は外部メモリ２１１にインストールされたアプリケーションプログラムである。
【００２４】
図３は、本実施形態に係る、認可サーバ２００、シングルサインオンサーバ３００、端末４００それぞれのモジュール構成を示す図である。認可サーバ２００は、認可モジュール６００およびＨＴＴＰサーバモジュール６１０をアプリケーションプログラムとして備える。ＨＴＴＰサーバモジュール６１０は、ＷＡＮ１００を介して接続する端末４００とのＨＴＴＰ通信を行うためのモジュールである。また、ＨＴＴＰサーバモジュール６１０はＳＳＬ／ＴＬＳによる通信が可能に構成されており、不図示の証明書ストアを持つ。また、本実施形態では、後述するクライアント登録要求を受け付けるエンドポイントにて、要求元に対してＸ．５０９形式の証明書による認証を要求するよう構成している。
【００２５】
認可モジュール６００は、ＨＴＴＰサーバモジュール６１０上で、またはＨＴＴＰサーバモジュール６１０と連携して動作するＷｅｂアプリケーションである。認可モジュール６００はＨＴＴＰサーバモジュール６１０を介して端末４００からの要求を受け付け、処理し、応答する。以後、本実施形態では、端末４００からＨＴＴＰサーバモジュール６１０を介して認可モジュール６００とＨＴＴＰ通信する処理について、単に端末４００から認可モジュール６００への要求および応答として記載する。
【００２６】
また、本実施形態では、ＨＴＴＰサーバモジュール６１０は、後述するクライアント登録要求を受け付けた場合は、要求元にＸ．５０９証明書を用いたクライアント認証を要求するよう構成されている。そして、ＨＴＴＰサーバモジュール６１０は、クライアント認証が成功した場合、受信したクライアント認証情報を認可モジュール６００に通知するよう構成されている。
【００２７】
また、認可モジュール６００はＯＡｕｔｈ  ２．０に対応しており、端末４００からのＯＡｕｔｈ  ２．０に関するリクエストを処理し、応答する機能を備える。その際、認可モジュール６００は端末に対してユーザを認証するための画面を応答し、ユーザを認証する機能を備える。さらに認可モジュール６００は、ＯｐｅｎＩＤ  ＣｏｎｎｅｃｔのＲＰの機能を備えており、後述するシングルサインオンサーバ３００にて認証された情報をもって、シングルサインオンを受ける機能を備える。
【００２８】
シングルサインオンサーバ３００は、シングルサインオンモジュール７００およびＨＴＴＰサーバモジュール７１０をアプリケーションプログラムとして備える。ＨＴＴＰサーバモジュール７１０はＨＴＴＰサーバモジュール６１０と同様の機能を持つ。シングルサインオンモジュール７００は、ＨＴＴＰサーバモジュール７１０上で、またはＨＴＴＰサーバモジュール７１０と連携して動作するＷｅｂアプリケーションである。シングルサインオンモジュール７００は、ＨＴＴＰサーバモジュール７１０を介して端末４００からの要求を受け付け、処理し、応答する。以後、本実施形態では、端末４００からＨＴＴＰサーバモジュール７１０を介してシングルサインオンモジュール７００とＨＴＴＰ通信する処理について、単に端末４００からシングルサインオンモジュール７００への要求および応答として記載する。また、シングルサインオンモジュール７００はＯｐｅｎＩＤ  ＣｏｎｎｅｃｔのＯＰの機能を備えており、端末４００を介した認可サーバ２００からのＯｐｅｎＩＤ  Ｃｏｎｎｅｃｔに関するリクエストを処理し、応答する機能を備える。
【００２９】
端末４００は、認証モジュール８１０、Ｗｅｂブラウザ８２０、およびアプリケーションモジュール８００をアプリケーションプログラムとして備える。認証モジュール８１０は、端末４００にて端末利用者を認証するための機能を備える。認証モジュール８１０が不図示の認証サーバと通信することで端末利用者を認証するよう構成する事もできる。本実施形態では、認証モジュール８１０は端末内で管理している端末ユーザ情報を用いて認証する。アプリケーションモジュール８００は、端末４００で動作するアプリケーションプログラムである。アプリケーションモジュール８００は、後述する処理を行う事で、端末への認証を元に、認可モジュール６００へのシングルサインオンを実現する。
【００３０】
Ｗｅｂブラウザ８２０は、端末４００がＷＷＷを利用するためのユーザエージェントである。また、アプリケーションモジュール８００は、自身を証明するためのＸ．５０９形式の証明書およびその秘密鍵を保持している。そして、後述のＨＴＴＰサーバモジュール６１０との通信確立時に利用する事で、ＨＴＴＰサーバモジュール６１０はアプリケーションモジュール８００からの要求である事を証明する事ができる。
【００３１】
図４を用いて、第一の設定である、端末の管理者が認可モジュール６００にシングルサインオンをするための設定を説明する。管理者は、端末４００が備えるＷｅｂブラウザ８２０を用いて認可モジュール６００のシングルサインオン設定画面にアクセスする。認可モジュール６００はユーザが認証済みかどうかを検証し、未認証である場合はログイン画面を応答する。ユーザが認証済みかどうかを検証する方法としては、一般的には、認可モジュール６００は、Ｗｅｂブラウザ８２０からリクエストされるＨＴＴＰヘッダーのＣｏｏｋｉｅ情報に認証トークンが含まれているかを確認する。そして、認可モジュール６００は、認証トークンが含まれている場合は認証トークンが有効か、を検証する事によって行われる。
【００３２】
図４（Ａ）は、ログイン画面の例である。ログイン画面２０００は、ユーザＩＤを入力するためのユーザＩＤ入力領域２００１、パスワードを入力するためのパスワード入力領域２００２、および入力したユーザＩＤ、パスワードを用いてユーザ認証を実行するためのログインボタン２００３を備える。端末の管理者は、応答されたログイン画面２０００にて、認可モジュール６００へユーザ認証するためのユーザＩＤ、パスワードを入力し、ログインボタン２００３を押下する。Ｗｅｂブラウザ８２０は、ログインボタン２００３の押下を検知すると、ログイン要求として、ユーザＩＤ入力領域２００１、パスワード入力領域２００２に入力されている情報を認可モジュール６００に送信する。認可モジュールのユーザテーブルに、認可モジュール６００が保存しているユーザ情報の例を表１に示す。
【表１】
2016009299.tif 000003
ログイン要求を受けた認可モジュール６００は、受信したユーザＩＤ、パスワードの組が認可モジュールユーザテーブルに登録されている情報と合致するかを検証する事で、ユーザを認証する。例えば、認可モジュール６００は、ユーザＩＤが「ａｄｍｉｎ＠ｘｘ．ｃｏｍ」で、パスワードが「ａｄｍｉｎ」であった場合、ユーザＩＤ「ａｄｍｉｎ＠ｘｘ．ｃｏｍ」のユーザとして認証する。そして、認証された事を示す認証トークンを生成し、Ｃｏｏｋｉｅに設定し、認可モジュール６００のシングルサインオン設定画面にリダイレクトされるよう応答する。認証トークンは、ユーザＩＤ、またはユーザをユニークに特定するためのＵＵＩＤと紐づけられ、認可モジュール６００に保存される。ログイン要求の情報が合致しない場合は、不図示のログインエラー画面を応答する。
【００３３】
なお、本実施形態では、ユーザを認証するための情報として、ユーザＩＤとパスワードの組による手段を用いるが、この手段に限定するわけではない。例えば、ＳＳＬ／ＴＬＳのクライアント証明書を利用する方法や、複数の認証情報を入力する事による多要素認証といった手段を用いる事も可能である。
【００３４】
Ｗｅｂブラウザ８２０は、Ｃｏｏｋｉｅに設定された認証トークンを用いて、認可モジュール６００のシングルサインオン設定画面へアクセスする。認可モジュール６００は認証トークンを用いて、ユーザが認証済みかどうかを検証し、認証済みである場合は、認証トークンに紐づけられた情報からユーザを特定する。そして、認可モジュール６００は、特定したユーザの権限情報が「管理者」である場合に、シングルサインオン設定画面を応答する。
【００３５】
例えば、認証トークンに紐づけられた情報が「ＵＵＩＤ：１０００００００」であった場合は、認可モジュールのユーザテーブルのＵＵＩＤ列を検索し、一致する「行１」のユーザである事を特定する。行１のユーザの権限情報列を参照すると「管理者」である事がわかる。認可モジュール６００は、特定したユーザの権限情報が「管理者」ではなかった場合は、不図示の権限エラー画面をＷｅｂブラウザ８２０に応答する。
【００３６】
図４（Ｂ）は、シングルサインオン設定画面の例である。このシングルサインオン設定画面に対するユーザ操作により、テナント毎に複数の端末装置が紐付けて認可サーバに登録されることとなる。シングルサインオン設定画面２１００は、シングルサインオン設定を有効化するための有効ボタン２１０１、無効化するための無効ボタン２１０２を備える。また、シングルサインオン設定が有効な場合は、ユーザマッピングを設定するための機能である、マッピング情報のダウンロードボタン２１０３、アップロードボタン２１０５、およびアップロードするマッピング情報を参照するための参照ボタン２１０４を備える。それぞれのボタン押下時の処理について説明する。
【００３７】
シングルサインオン設定画面２１００にて、端末の管理者が有効ボタン２１０１を押下すると、認可モジュール６００へシングルサインオン有効化要求を通知する。認可モジュール６００は、シングルサインオン有効化要求を受け付けると、シングルサインオンモジュール７００へ、ＯＰの有効化要求を行う。その際、認可モジュール６００は、認証トークンから特定されたユーザのテナントＩＤを通知する。例えば、特定されたユーザが、認可モジュールのユーザテーブルの「ａｄｍｉｎ＠ｘｘ．ｃｏｍ」であった場合は、テナントＩＤとして「１００ＡＡ」が通知される。
【００３８】
シングルサインオンモジュール７００は、ＯＰの有効化要求を受けると、ＯＰを識別し、かつＯＰの認証要求ＵＲＩを示すためのＯＰＩＤを生成し、Ｘ．５０９形式の証明書の鍵ペアを生成し、ＯＰテーブルに情報を格納する。シングルサインオンモジュールのＯＰテーブルに、シングルサインオンモジュール７００が保存するＯＰ情報の例を表２に示す。なお、Ｘ．５０９形式の証明書については、ファイルの参照先として格納する例を示しているが、バイナリデータとして直接データを格納しても良い。なお、データ未格納なカラムについては後述する。
【表２】
2016009299.tif 000004
シングルサインオンモジュール７００は、生成したＯＰＩＤとＸ．５０９形式の証明書から公開鍵のみを抽出し、認可モジュール６００へ応答する。応答を受けた認可モジュール６００は、テナントＩＤと紐づけて、ＯＰＩＤ、公開鍵をＲＰテーブルに保存する。認可モジュールのＲＰテーブルの例を表３に示す。
【表３】
2016009299.tif 000005
認可モジュール６００は、保存時にＭＡＰＩＤを生成し、認可モジュールのユーザテーブル（表１）で保存されている、当該テナントＩＤの全ユーザ数分のマッピングデータを生成し、格納する。生成される認可モジュールのユーザマッピングテーブルの例を表４に示す。
【表４】
2016009299.tif 000006
認可モジュール６００は、端末の管理者の認証トークンから特定したテナントＩＤ「１００ＡＡ」を用いて、テナントＩＤ「１００ＡＡ」に紐付けられた全てのユーザＩＤ、およびＵＵＩＤを取得し、それぞれ格納する。その際、端末ＵＵＩＤは未格納の状態となる。認可モジュール６００は、ユーザマッピングテーブルを格納後、シングルサインオン有効化要求を終了し、シングルサインオン設定画面２１００を応答する。
【００３９】
次に、シングルサインオン設定画面２１００にて、端末の管理者がダウンロードボタン２１０３を押下すると、Ｗｅｂブラウザ８２０は認可モジュール６００へユーザマッピングデータのダウンロード要求を通知する。認可モジュール６００は、ユーザマッピングデータのダウンロード要求を受け付けると、ユーザマッピングテーブルのユーザＩＤ、ＵＵＩＤ、端末ＵＵＩＤのユーザマッピング表を生成し、応答する。このユーザマッピング表は、例えば、ＣＳＶ形式やＸＭＬ形式のテキストファイルであり、ユーザが確認し編集可能な形式であれば良い。端末の管理者は、ダウンロードしたユーザマッピング表の内、未入力である端末ＵＵＩＤにパラメーターを入力する。これは、端末４００において、ユーザを一意に認識するためのＩＤである。ユーザマッピング表の例を表５に示す。
【表５】
2016009299.tif 000007
端末の管理者は、シングルサインオン設定画面２１００にて、参照ボタン２１０４を押下し、編集したユーザマッピング表を選択する。そして、端末の管理者がアップロードボタン２１０５を押下すると、認可モジュール６００へユーザマッピング要求が通知される。その際、参照ボタン２１０４にて選択したユーザマッピング表が通知される。
【００４０】
ユーザマッピング要求を受け付けた認可モジュール６００は、通知内容を認可モジュールのユーザマッピングテーブルに格納する。ユーザマッピング表の情報を反映した認可モジュールのユーザマッピングテーブルを表６に示す。
【表６】
2016009299.tif 000008
以上が、第一の設定である、端末の管理者が認可モジュール６００にて行うシングルサインオンをするための設定である。
【００４１】
図５を用いて、第二の設定である、端末４００を認可モジュール６００に登録する処理（以後、クライアント登録処理と呼ぶ）に関するシーケンスを説明する。本シーケンスはユーザが端末４００において、認可モジュール６００に未登録であるアプリケーションモジュール８００を利用する際のフローを示している。ユーザが端末４００のアプリケーションモジュール８００利用時に、認可モジュール６００に未登録である、つまり後述するクライアントＩＤ、クライアントシークレットが未取得である場合に開始されるシーケンスである。
【００４２】
アプリケーションモジュール８００は、自身が未登録であった場合、Ｓ１１にて、認可モジュール６００に対して、クライアント登録要求を行う。なお、アプリケーションモジュール８００がクライアント登録要求を行うきっかけとして、本実施形態では、端末４００にて、ユーザが当該アプリケーションモジュール８００をインストールし、初めて起動したタイミングとして説明する。なお、他のタイミングとして、ユーザがアプリケーションモジュール８００の機能を選択し、リソースサーバであるシングルサインオンサーバ３００へのリソース要求が発生するタイミングが考えられる。また、アプリケーションモジュール８００が明示的に開始する操作を備え、ユーザが端末４００にて当該操作をしたタイミングが考えられる。
【００４３】
なお、クライアント登録要求は、クライアント名や、リダイレクトＵＲＩ等の、ＯＡｕｔｈのＡｕｔｈｏｒｉｚａｔｉｏｎ  Ｃｏｄｅ  Ｇｒａｎｔを利用するための情報を含む。また、その他の情報として、クライアントを説明するための文字列や、説明が記載されるサイトのＵＲＩ、等の付属情報を含むよう構成する事もできる。
【００４４】
クライアント登録要求は、認可サーバ２００のＨＴＴＰサーバモジュール６１０にて、クライアント認証が必要になるよう構成されているため、ＨＴＴＰサーバモジュール６１０による、クライアント認証の処理が実施される。アプリケーションモジュール８００からのクライアント登録要求を受け付けたＨＴＴＰサーバモジュール６１０は、ＳＳＬ／ＴＬＳ通信のネゴシエーションを開始する。ＨＴＴＰサーバモジュール６１０は、アプリケーションモジュール８００に対してクライアント認証を要求する。Ｓ１２にて、ＨＴＴＰサーバモジュール６１０は、不図示の証明書ストアにて設定されている証明書を用いて取得したクライアント認証情報を検証し、アプリケーションモジュール８００をデバイス登録の要求元として認証する。
【００４５】
なお、本実施の形態では、クライアントの認証方法として、ＳＳＬ／ＴＬＳのクライアント証明書による認証方式を用いるが、例えば、Ｂａｓｉｃ認証やＤｉｇｅｓｔ認証といった、ＩＤおよびパスワードを用いる方式等が用いられてよい。また、これら主体を認証する手段を経て、認証された主体に対してクライアントを登録するための認可トークンを発行する手段を設け、当該認可トークンを検証する事によってクライアント登録を受け付けるよう構成する事も可能である。
【００４６】
Ｓ１３にて、ＨＴＴＰサーバモジュール６１０は、アプリケーションモジュール８００を認証した後に、認可モジュール６００に対して、アプリケーションモジュール８００から受信したクライアント登録要求を通知する。その際、認証したアプリケーションモジュール８００を識別するためのクライアント認証情報も通知する。
【００４７】
Ｓ１４にて、認可モジュール６００は、ＨＴＴＰサーバモジュール６１０から通知されたクライアント認証情報を取得する。認可モジュール６００にて管理されているクライアント認証情報テーブルの例を表７に示す。
【表７】
2016009299.tif 000009
例えば、認可モジュール６００が取得したクライアント認証情報が、「Ｉｓｓｕｅｒ＝ｘｘ．ｃｏｍ，  Ｓｕｂｊｅｃｔ＝ｄｅｖ．ｘｘ．ｃｏｍ」だった場合、クライアント登録する際の権限は「ＳＳＯ可」となる。また、未登録だった場合は、認証エラーとなり、認可モジュール６００はアプリケーションモジュール８００に認証エラーを応答する。
【００４８】
Ｓ１５にて、認可モジュール６００は、クライアントＩＤ、およびクライアントを認証するための秘匿情報であるシークレットを発行し、クライアント登録要求にて取得した情報と合わせてデータを格納する。認可モジュール６００が格納する、認可モジュールのクライアントテーブルの例を表８に示す。
【表８】
2016009299.tif 000010
上記登録が完了した後に、Ｓ１６にて認可モジュール６００は、発行したクライアントＩＤとシークレットを、アプリケーションモジュール８００に応答する。アプリケーションモジュール８００は、取得したクライアントＩＤおよびシークレットを保存する。その際、アプリケーションモジュール８００は、認可モジュール６００へ認可要求を行うためのＵＲＩである認可ＵＲＩを格納する。この認可ＵＲＩは、クライアント登録の応答として認可モジュール６００へ応答するよう構成する事もできるし、アプリケーションモジュール８００が設定として保持しておくこともできる。アプリケーションモジュールのクライアントテーブルの例を表９に示す。
【表９】
2016009299.tif 000011
以上が、第二の設定であるクライアント登録処理である。このシーケンスによって、端末４００が認可モジュール６００に登録される。
【００４９】
図６および図７を用いて、第三の設定である、端末の管理者が端末４００からシングルサインオンモジュール７００を利用して、認可モジュール６００とシングルサインオンする事を許可する処理のシーケンスを説明する。
【００５０】
Ｓ２１にて、端末の管理者は、端末４００にてログイン操作を行う。このログイン操作は、端末４００が備える認証モジュール８１０が提供する認証手段によって行われる。本実施形態の特徴として、この認証手段はシングルサインオンシステムと関係する事なく選択する事ができる。認証手段としては、例えば、ユーザＩＤ、パスワードの組み合わせを検証する手段、指紋等の生体情報を利用する認証手段、非接触型のＩＣカードを利用する手段、さらには、複数の認証手段を組み合わせる多要素認証手段等が考えられる。また、認証モジュール８１０が、不図示の認証サーバと通信することで端末利用者を認証するよう構成する事もできる。本実施形態では、ユーザＩＤ、パスワードの組み合わせを検証する手段を認証手段として説明する。本実施の形態における認証モジュールのユーザテーブルの例を表１０に示す。
【表１０】
2016009299.tif 000012
認証モジュールのユーザテーブルにおいて、ユーザＩＤ、パスワードの組にてユーザ認証が行われる。また、ＵＵＩＤは端末４００のユーザを一意に識別するための情報である。このＵＵＩＤが、前述の端末の管理者によるシングルサインオン設定画面２１００にてアップロードしたユーザマッピング表の端末ＵＵＩＤに記載した情報と対応している。
【００５１】
Ｓ２２にて、認証モジュール８１０はユーザを認証する。例えば、ユーザＩＤが「ａｄｍｉｎ＠ｙｙ．ｄｅｖｉｃｅ．ｃｏｍ」で、パスワードが「ａｄｍｉｎ」であった場合、ユーザＩＤ「ａｄｍｉｎ＠ｙｙ．ｄｅｖｉｃｅ．ｃｏｍ」のユーザとして認証する。Ｓ２３にて、認証モジュール８１０は認証したユーザの認証情報を生成し保存する。この認証情報は、端末の管理者が不図示のログアウト操作を実施するか、設定された時刻が経過するまで有効な状態で保存される。認証情報には、認証したユーザのユーザＩＤ、ＵＵＩＤ、および権限情報が格納されている。なお、認証情報としては、各情報を直接格納するのではなく、ユーザＩＤ、ＵＵＩＤ、および権限情報とが参照可能に紐づけられたトークンでもよい。
【００５２】
端末の管理者は、認証モジュール８１０での認証を受けたのちに、Ｓ２４、Ｓ２５にて、Ｗｅｂブラウザ８２０を用いてアプリケーションモジュール８００にアクセスする。なお、アプリケーションモジュール８００へのアクセスを開始するきっかけとしては、アプリケーションモジュール８００へアクセスするためのブックマークが保存され、そのブックマークを選択した場合が考えられる。また、アプリケーションモジュール８００が明示的に開始するための操作、および画面を備え、端末の管理者が、端末４００にて当該操作をしたタイミングが考えられる。
【００５３】
Ｓ２６にてアプリケーションモジュール８００は、Ｗｅｂブラウザ８２０に対して操作画面を応答する。図８（Ａ）はアプリケーションモジュール８００が応答する操作画面の例である。操作画面２２００は、端末の管理者が認証連携を開始するための、認証連携ボタン２２０１と、後述するユーザが認可連携を開始するための認可連携ボタン２２０２から構成される。なお、本画面を応答する際に、アプリケーションモジュール８００は、認証モジュール８１０から認証情報を取得し、権限情報が「管理者」の場合にのみ認証連携ボタン２２０１を表示するよう構成する事ができる。
【００５４】
Ｓ２７にて、端末の管理者はＷｅｂブラウザ８２０に表示された操作画面にて、認証連携ボタン２２０１を押下する。Ｓ２８にて、Ｗｅｂブラウザ８２０は、アプリケーションモジュール８００に対して認証連携要求を行う。Ｓ２９にてアプリケーションモジュール８００は、端末４００を利用する複数のユーザがそれぞれ複数のテナントに所属する場合は、図８（Ｂ）に示す認証連携設定画面を応答するよう構成する事もできる。また、単数のテナントでの利用の場合は、図８（Ｂ）の認証連携設定画面をスキップし、Ｓ２１２に処理を移行する事もできる。その場合、後述の認証連携要求にて、デフォルトのＯＰ名を利用しても良いし、操作画面２２００にて通知するＯＰ名を指定するための入力領域を備え、入力されたＯＰ名を利用するよう構成してもよい。
【００５５】
図８（Ｂ）は、認証連携ボタン２２０１の押下を受けて、アプリケーションモジュール８００が応答する認証連携設定画面の例である。認証連携設定画面２３００は、登録するＯＰのＯＰ名を入力するためのＯＰ名入力領域２３０１、ＯＰの新規登録を開始する新規登録ボタン２３０２、および既存の登録済みのＯＰの情報を表示する登録済みＯＰリスト２３０３を備える。なお、認証連携設定画面２３００は、既にＯＰ名「組織Ｂ」、テナントＩＤ「１０２ＡＡ」のＯＰが登録済みである例を示している。
【００５６】
Ｓ２１０にて、端末の管理者は、Ｗｅｂブラウザ８２０に表示された認証連携設定画面にてＯＰ名を入力し、新規登録ボタン２３０２を押下する。ここで、ＯＰ名としては「組織Ａ」が入力されているものとして説明する。なお、図８（Ｂ）では、既にテナントＩＤ「１０２ＡＡ」のＯＰについて登録済みの画面例を提示したが、以降の処理については、まだ未登録の状態で、初めて認証連携を実施した場合を例として説明する。
【００５７】
Ｓ２１１にて、認証連携要求を受けたアプリケーションモジュール８００は、認証連携処理フローを開始する。認証連携処理フローは以下のフローから構想される。一つ目は、アプリケーションモジュール８００が、認可モジュール６００に対してＯＡｕｔｈ  ２．０による、認可トークンを取得するフローである。二つ目は、アプリケーションモジュール８００が、取得した認可トークンを用いて、シングルサインオンモジュール７００に対して認証連携を要求するフローである。つまり、端末４００は、認可モジュール６００から取得した認可トークンを用いてシングルサインオンモジュール７００との認証連携を確立する。ここで、ＯＡｕｔｈ  ２．０による認可トークンを取得するフローとして、本実施形態ではＯＡｕｔｈ  ２．０に定義されているＡｕｔｈｏｒｉｚａｔｉｏｎ  Ｃｏｄｅ  Ｇｒａｎｔを用いて説明するが、フローはこれに限定されない。例えば、別の実施形態として、Ｉｍｐｌｉｃｉｔ  Ｇｒａｎｔを用いる事も可能である。
【００５８】
Ｓ２１２、Ｓ２１３にて、アプリケーションモジュール８００は、Ｗｅｂブラウザ８２０を介して認可モジュール６００へ認可要求を行う。この認可要求には、少なくとも、クライアント登録の結果取得したクライアントＩＤおよび登録したリダイレクトＵＲＩ、そしてシングルサインオンモジュール７００の認証連携を実施するためのリソース範囲を示すスコープを含む。認可要求を受けた認可モジュール６００はユーザが認証済みかどうかを検証し、未認証である場合はＳ２１４にて、ログイン画面を応答する。Ｓ２１５、Ｓ２１６、Ｓ２１７にて行われる、認可モジュール６００におけるユーザ認証処理については前述のとおりである。ユーザ認証処理の結果、認証トークンが生成される。
【００５９】
Ｓ２１８にて、認可モジュール６００は、受信した認可要求のうち、クライアントＩＤとリダイレクトＵＲＩの組が正しいか検証する。より具体的には、認可要求に含まれるクライアントＩＤ、リダイレクトＵＲＩの組が、認可モジュールのクライアントテーブルに登録されているクライアントＩＤとリダイレクトＵＲＩの組が一致するか検証する。不一致の場合、認可モジュール６００は不図示のエラー画面を、Ｗｅｂブラウザ８２０に応答する。一致した場合、認可モジュール６００は認証トークンからユーザを特定する。特定したユーザの権限情報が「管理者」でない場合、認可モジュール６００はＷｅｂブラウザ８２０を介してアプリケーションモジュール８００に権限エラーを応答する。ユーザの権限情報が「管理者」である場合、認可モジュール６００はＳ２１９にてＷｅｂブラウザ８２０に対して認可確認画面を応答する。
【００６０】
図８（Ｃ）は、Ｗｅｂブラウザ８２０に応答される認可確認画面の例である。認可確認画面２４００は、後述する代理認証を実行させることを認可させるか否かを設定するための画面である。認可確認画面２４００は、認可要求に含まれるクライアントＩＤを元に認可モジュールのクライアントテーブルから取得したクライアント名を表示する領域であるアクセス元表示領域２４０１を備える。また、認可要求に含まれるスコープの説明を表示する領域であるスコープ表示領域２４０２を備える。さらに、認可確認画面２４００は、ユーザが上記情報の内容について認可操作を実行する許可ボタン２４０３、および拒否を実行する拒否ボタン２４０４を備える。ここで、ユーザが拒否ボタン２４０４を押下した場合は、認可モジュール６００はＷｅｂブラウザ８２０を介してアプリケーションモジュール８００に権限エラーを応答する。
【００６１】
Ｓ２２０にて、端末の管理者が認可確認画面２４００にて、許可ボタン２４０３を押下、つまり認可操作を行った場合、Ｗｅｂブラウザ８２０を介し、Ｓ２２１にて認可モジュール６００にアクセス許可が認可された事が通知される。Ｓ２２２にて、認可モジュール６００は認可コードを発行する。具体的には、認可モジュール６００はトークンＩＤを発行し、認可要求に含まれるスコープ、クライアントＩＤ、認証し、許可を得たユーザのＵＵＩＤを、トークンテーブルに登録する。その際、トークン種別は認可コードとし、有効期限に当該認可コードが有効である日時を登録する。認可モジュールのトークンテーブルの例を表１１に示す。
【表１１】
2016009299.tif 000013
【００６２】
図７のＳ２２３、Ｓ２２４にて、認可モジュール６００は、発行した認可コードのトークンＩＤを付与してＷｅｂブラウザ８２０を介し、アプリケーションモジュール８００に認可を応答する。具体的には、認可要求時に取得したリダイレクトＵＲＩに対してアプリケーションモジュール８００にリダイレクトするようＷｅｂブラウザ８２０に指示する。
【００６３】
Ｓ２２５にて、アプリケーションモジュール８００は、認可モジュール６００に対して認可トークンを要求する。この認可トークン要求には、少なくとも、取得した認可コード、保存しているクライアントＩＤ、シークレット、および認可要求時に送信したリダイレクトＵＲＩが含まれる。
【００６４】
Ｓ２２６にて、認可モジュール６００は取得したクライアントＩＤ、シークレットの組を用いてクライアントを認証する。具体的には、認可モジュールのクライアントテーブルに保存されたクライアントＩＤ、シークレットの組と一致するかを検証する。認可モジュール６００は、クライアント認証に失敗した場合はアプリケーションモジュール８００に認証エラーを応答する。認可モジュール６００は、クライアント認証に成功した場合、認証したクライアントＩＤによって特定されるクライアントの権限情報を確認する。
【００６５】
クライアントの権限情報が「ＳＳＯ可」でない場合、認可モジュール６００は、アプリケーションモジュール８００に権限エラーを応答する。「ＳＳＯ可」であった場合、認可モジュール６００は、取得した認可コードを検証する。認可コードの検証としては、取得した認可コードのトークンＩＤが認可モジュールのトークンテーブルに登録されているか、登録されている場合は、有効期限の範囲内かを検証する。
【００６６】
さらに、認可モジュール６００は、認可トークン要求にて取得したリダイレクトＵＲＩが、トークンＩＤに紐づくクライアントＩＤのリダイレクトＵＲＩと一致するかを検証する。認可コード検証の結果が無効であった場合、認可モジュール６００はアプリケーションモジュール８００にトークン不正エラーを応答する。そして、認可コード検証の結果が有効であった場合、Ｓ２２７にて認可モジュール６００は認可トークンを発行する。具体的には、認可モジュール６００はトークンＩＤを発行し、認可コードに紐づくスコープ、ユーザのＵＵＩＤ、認証したクライアントＩＤを認可モジュールのトークンテーブルに登録する。その際、トークン種別は認可トークンとし、有効期限に当該認可トークンが有効である日時を登録する。また、検証した認可コードを削除するか、有効期限を過去の日時に更新する事で無効化する。認可モジュールのトークンテーブルの例を表１２に示す。
【表１２】
2016009299.tif 000014
【００６７】
そして、Ｓ２２８にて、認可モジュール６００は、発行した認可トークンのトークンＩＤをアプリケーションモジュール８００に応答する。その際、認可トークンの有効期限を応答するよう構成する事もできる。本実施形態では、認可トークンを更新するためのリフレッシュトークンを発行しない例を説明したが、認可モジュールのトークンテーブルにて、リフレッシュトークンのトークンＩＤ、および有効期限を管理するよう構成する事もできる。その際、認可モジュール６００は認可トークン発行時に同時にリフレッシュトークンも発行し、認可トークンの応答時に発行したリフレッシュトークンのトークンＩＤも含めて応答するよう構成する事もできる。
【００６８】
Ｓ２２９にて、認可トークンを取得したアプリケーションモジュール８００は、取得した認可トークンを用いてシングルサインオンモジュール７００に認証連携要求を行う。認証連携要求には、少なくとも、認可トークンのトークンＩＤとアプリケーションモジュールの端末認証要求ＵＲＩを含む。端末認証要求ＵＲＩについては後述するが、例えば、「ｈｔｔｐｓ：／／ｌｏｃａｌ／ａｕｔｈ」が通知された場合として説明する。Ｓ２３０にてシングルサインオンモジュール７００は認証連携要求に含まれる認可トークンのトークンＩＤの検証を認可モジュール６００に要求する。
【００６９】
Ｓ２３１にて、認可モジュール６００は、検証要求された認可トークンのトークンＩＤを検証し、検証結果としてトークンに紐づく情報を取得する。具体的には、認可モジュールのトークンテーブルに登録されているか、かつ有効期限内かを検証し、結果が「利用不可」であれば、シングルサインオンモジュール７００に検証エラー応答を返す。検証の結果が「利用可」であれば、認可モジュール６００は特定された認可トークンに紐づく情報を認可トークン情報として取得する。この認可トークン情報としては、少なくとも、認可モジュールのトークンテーブルのクライアントＩＤ、ＵＵＩＤ、およびＵＵＩＤから特定される認可モジュールのユーザテーブルのユーザＩＤ、テナントＩＤを含む。
【００７０】
なお、認可トークンの検証要求時にスコープを指定する事も出来る。その場合、認可モジュール６００は、該認可トークンのトークンＩＤで特定される認可トークンのスコープに、指定のスコープが含まれているか否かを検証する。
【００７１】
Ｓ２３２にて、認可トークンの検証結果が「利用可」であった場合、認可モジュール６００は、認可トークン情報を認可トークン検証応答としてシングルサインオンモジュール７００に応答する。Ｓ２３３にて、シングルサインオンモジュール７００は、認証連携設定を行う。具体的には、認可トークン情報から得られたテナントＩＤ「１００ＡＡ」を参照可能な形式で新たなテナントＩＤを発行し、ＯＰテーブルに追加する。
【００７２】
本実施形態では、通知されたテナントＩＤが「１００ＡＡ」だった場合に、「１００ＡＡＲ１」というテナントＩＤを発行するものとして説明する。しかし、テナントＩＤは発行せずに別途ＯＰテーブルにカラムを追加し、その値にて参照可能なように構成する事もできる。そして、シングルサインオンモジュール７００は、取得した端末認証要求ＵＲＩ「ｈｔｔｐｓ：／／ｌｏｃａｌ／ａｕｔｈ」をＯＰＩＤとしてＯＰテーブルに追加する。さらに、Ｘ．５０９の秘密鍵と公開鍵の鍵ペアを生成し、シングルサインオンモジュールのＯＰテーブルに追加する。シングルサインオンモジュールのＯＰテーブルに当該データを追加した例を表１３に提示する。
【表１３】
2016009299.tif 000015
【００７３】
次に、シングルサインオンモジュール７００は、ＲＰを登録するためのＵＲＩであるＲＰ登録ＵＲＩ「ｈｔｔｐｓ：／／ａａ．ｃｏｍ／ｒｅｇ」を取得する。このＲＰ登録ＵＲＩは、予めシングルサインオンモジュール７００にて設定されているＵＲＩとして説明する。そして、当該ＵＲＩに対してＲＰ登録をするためのイニシャル認可トークンを生成し、シングルサインオンモジュールの認可テーブルに登録する。その際、新規に生成したテナントＩＤ「１００ＡＡＲ１」と紐づけて保存する事で、当該イニシャル認可トークンを利用してＲＰを登録した場合、テナントＩＤ「１００ＡＡＲ１」に紐づいて登録する事ができる。以下にシングルサインオンモジュールのトークンテーブルの例を提示する。
【表１４】
2016009299.tif 000016
Ｓ２３４にて、シングルサインオンモジュール７００は、認可モジュール６００にＯＰ登録要求を行う。ＯＰ登録要求では、少なくとも、生成したテナントＩＤ「１００ＡＡＲ１」、鍵ペア「１００ＡＡＲ１．ｐ１２」から抽出した公開鍵、およびイニシャル認可トークン「ｉ＿０００００１」を通知する。また、ＯＰ登録要求では、ＲＰ登録ＵＲＩ「ｈｔｔｐｓ：／／ａａ．ｃｏｍ／ｒｅｇ」、およびＯＰＩＤ「ｈｔｔｐｓ：／／ｌｏｃａｌ／ａｕｔｈ」を通知する。
【００７４】
Ｓ２３５にて、認可サーバモジュール６００は、取得した情報を元に、ＲＰテーブルにデータを登録する。その際、通知を受けたテナントＩＤ「１００ＡＡＲ１」から紐づくテナントＩＤ「１００ＡＡ」に登録されているユーザマッピングテーブルのＭＡＰＩＤ「１」を引き継いで登録する。さらに、認証要求の応答を受け付けるリダイレクトＵＲＩ「ｈｔｔｐｓ：／／１００ＡＡ．ｘｘ／ｒ１／ｒｅｓ」、およびイニシャルログインＵＲＩ「ｈｔｔｐｓ：／／１００ＡＡ．ｘｘ／ｒ１／ｌｏｇｉｎ」を生成し、格納する。イニシャルログインＵＲＩは、ＲＰ起点でシングルサインオン処理を開始するためのＵＲＩである。認可モジュールのＲＰテーブルの例を表１５に示す。
【表１５】
2016009299.tif 000017
認可モジュール６００は、取得した情報を用いてシングルサインオンモジュール７００にＲＰ登録要求を行う。ＲＰ登録要求には少なくとも、取得したイニシャル認可トークン「ｉ＿０００００１」、および、リダイレクトＵＲＩ、イニシャルログインＵＲＩを含む。
【００７５】
ステップＳ２３６にて、ＲＰ登録要求を受けたシングルサインオンモジュール７００は、イニシャル認可トークン「ｉ＿０００００１」を検証し、検証結果としてトークンに紐づくテナントＩＤを取得する。そして、イニシャル認可トークンに紐づくテナントＩＤ「１００ＡＡＲ１」を取得する。次に、クライアントＩＤ、シークレットを発行し、要求に含まれる「リダイレクトＵＲＩ」、「イニシャルログインＵＲＩ」と合わせて、ＯＰテーブルのテナントＩＤ「１００ＡＡＲ１」で特定される行にデータを追加する。以下に、シングルサインオンモジュールのＲＰテーブルの例を示す。
【表１６】
2016009299.tif 000018
Ｓ２３７にて、シングルサインオンモジュール７００は、ＲＰ登録応答として発行したクライアントＩＤ「ｃ００１＠ａａ．ｃｏｍ」、シークレット「ｘｘｘｘｘｘｘｘ」を認可モジュール６００に通知する。
【００７６】
Ｓ２３８にて、認可モジュール６００は、取得したクライアントＩＤ、シークレットをＲＰテーブルのテナントＩＤ「１００ＡＲ１」に追加する。以下に、認可モジュール６００のＲＰテーブルの例を示す。
【表１７】
2016009299.tif 000019
Ｓ２３９にて、認可モジュール６００は、ＯＰ登録応答をシングルサインオンモジュール７００に応答する。
【００７７】
Ｓ２４０にて、シングルサインオンモジュール７００は、アプリケーションモジュール８００に対して、認証連携応答を通知する。認証連携応答には、少なくとも、シングルサインオンモジュールのＲＰテーブルの「行２」の情報であるテナントＩＤ、クライアントＩＤ、シークレット、ＯＰＩＤ、リダイレクトＵＲＩ、およびイニシャルログインＵＲＩの情報を含む。さらに、テナントＩＤ「１００ＡＡＲ１」に紐づくＯＰ、より具体的にはＲＰテーブルの「行１」のＯＰＩＤ「ｈｔｔｐｓ：／／１００ＡＡ．ａａ／ａｕｔｈ」を合わせて通知する。Ｓ２４１にて、アプリケーションモジュール８００は、取得した情報をアプリケーションモジュールのＯＰテーブルに格納する。その際、Ｗｅｂブラウザ８２０から通知されたＯＰ名「組織Ａ」を格納する。以下、アプリケーションモジュールのＯＰテーブルの例を示す。
【表１８】
2016009299.tif 000020
Ｓ２４２にて、アプリケーションモジュール８００は、Ｗｅｂブラウザ８２０に対して操作画面を応答し、処理を終了する。ここで操作画面は図８（Ａ）にて説明した操作画面２２００である。その際、認証連携ボタン２２０１は実行済みであるとして無効状態で表示されるよう構成してもよい。
【００７８】
なお、本実施形態では、Ｓ２３０にて認証連携設定を実施したシングルサインオンモジュール７００は、Ｓ２３４にて認可モジュールにＯＰ登録要求を行うシーケンスで説明したが、以下のシーケンスでも実現できる。シーケンスとしては、シングルサインオンモジュール７００はＳ２３４のＯＰ登録要求を通知する前に、Ｓ２３６のＲＰ登録のためのクライアントＩＤ、シークレットの発行を行う。そして、それらをＳ２３４のＯＰ登録要求にてイニシャル認可トークンに代わって含めるよう構成する事もできる。そのシーケンスの場合、認可モジュール６００はＳ２３５のＲＰ登録要求をスキップする。そして、Ｓ２３９のＯＰ登録応答時に認可モジュール６００にて認証要求の認可応答を受け付けるリダイレクトＵＲＩ、ＲＰ起点でシングルサインオン処理を開始する最初のログインＵＲＩであるイニシャルログインＵＲＩを含め応答する。そして、ＯＰ登録応答を受けたシングルサインオンモジュール７００は、ここで、Ｓ２３６のＲＰ登録処理を実施するよう構成する事もできる。
【００７９】
以上が、第三の設定である、端末の管理者が、端末４００がシングルサインオンモジュール７００を利用して、認可モジュール６００とシングルサインオンする事が許可される。以上の第一、第二、第三の設定を行う事で、その後に、端末利用者によるシングルサインオン処理を行う事が可能となる。
【００８０】
図９、図１０、図１１を用いて、シングルサインオン処理の詳細について説明する。図９および図１０は第一、第二、第三の設定がなされた端末４００にて、端末利用者が不図示のクラウドサービスを利用するための認可トークンを取得するためのシーケンスである。より具体的には、端末４００にログインした事で、認可モジュールに対してシングルサインオンし、ＯＡｕｔｈ  ２．０の認可確認画面が提示されるまでのシーケンスである。
【００８１】
Ｓ３１にて、端末利用者は、端末４００にてログイン操作を行う。このログイン操作は、端末４００が備える認証モジュール８１０が提供する認証手段によって行われる。本実施の形態の特徴として、この認証手段はシングルサインオンシステムと関係する事なく選択する事ができる。認証手段としては、例えば、ユーザＩＤ、パスワードの組み合わせを検証する手段、指紋等の生体情報を利用する認証手段、非接触型のＩＣカードを利用する手段、さらには、複数の認証手段を組み合わせる多要素認証手段、等が考えられる。また、認証モジュール８１０が、不図示の認証サーバと通信することで端末利用者を認証するよう構成する事もできる。本実施の形態では、ユーザＩＤ、パスワードの組み合わせを検証する手段を認証手段として説明する。ここで、本実施の形態における認証モジュールのユーザテーブルは上述の通りである。
【００８２】
認証モジュールのユーザテーブルにおいて、ユーザＩＤ、パスワードの組にてユーザ認証が行われる。また、ＵＵＩＤは端末４００のユーザを一意に識別するための情報である。このＵＵＩＤが、前述の端末の管理者によるシングルサインオン設定画面２１００にてアップロードしたユーザマッピング表の端末ＵＵＩＤに記載した情報と対応している。
【００８３】
Ｓ３２にて、認証モジュール８１０はユーザを認証する。例えば、ユーザＩＤが「ｕｓｅｒ＠ｙｙ．ｄｅｖｉｃｅ．ｃｏｍ」で、パスワードが「ｕｓｅｒ」であった場合、ユーザＩＤ「ｕｓｅｒ＠ｙｙ．ｄｅｖｉｃｅ．ｃｏｍ」のユーザとして認証する。
【００８４】
Ｓ３３にて、認証モジュール８１０は認証したユーザの認証情報を生成し保存する。この認証情報は、端末の管理者が不図示のログアウト操作を実施するか、設定された時刻が経過するまで有効な状態で保存される。認証情報には、認証したユーザのユーザＩＤ、ＵＵＩＤ、および権限情報が格納されている。なお、認証情報としては、各情報を直接格納するのではなく、ユーザＩＤ、ＵＵＩＤ、および権限情報とが参照可能に紐づけられたトークンでもよい。
【００８５】
端末利用者は、認証モジュール８１０で認証を受けたのちに、Ｓ３４、Ｓ３５にて、Ｗｅｂブラウザ８２０を用いてアプリケーションモジュール８００にアクセスする。なお、アプリケーションモジュール８００へのアクセスを開始するきっかけとしては、アプリケーションモジュール８００へアクセスするためのブックマークが保存され、そのブックマークを選択した場合が考えられる。また、アプリケーションモジュール８００が明示的に開始するための操作、および画面を備え、端末の管理者が、端末４００にて当該操作をしたタイミングが考えられる。
【００８６】
Ｓ３６にて、アプリケーションモジュール８００はＷｅｂブラウザ８２０に対して操作画面を応答する。操作画面の例は、図８（Ａ）を用いて説明済みである。Ｓ３７にて、端末利用者はＷｅｂブラウザ８２０に表示された操作画面にて、認可連携ボタン２２０２を押下する。Ｓ３８にて、Ｗｅｂブラウザ８２０は、アプリケーションモジュール８００に対して認可要求を行う。
【００８７】
Ｓ３９にて、アプリケーションモジュール８００は登録されているＯＰ情報を取得する。より具体的には、アプリケーションモジュールのＯＰテーブルに登録されている全ての情報を取得する。ここで、アプリケーションモジュール８００は、登録されているＯＰ情報が複数の場合は、Ｓ３１０にて図１１で示す組織選択画面を応答する。また、単数の場合は図１１の組織選択画面の応答をスキップし、Ｓ３１３に処理を移行する事もできる。その場合、後述の認証連携認可要求にて、取得した単数のＯＰ名を利用して処理を実行する。さらに、アプリケーションモジュール８００は、ＯＰ情報が未登録の場合は、Ｓ３３７まで処理をスキップし、認可モジュール６００に対して認可要求を行うよう構成する事もできる。
【００８８】
図１１は、認可連携ボタン２２０２の押下を受けて、テナントが複数登録されている場合にアプリケーションモジュール８００が応答する組織選択画面の例である。組織選択画面２５００は、登録されているＯＰの情報を表示するためのＯＰリスト２５０１、各ＯＰを利用して認可要求を開始する実行ボタン２５０２、および、実行する際に、どのＯＰを利用するかを選択する選択肢であるＯＰ選択ボタン２５０３を備える。なお、組織選択画面２５００では、ＯＰ名「組織Ａ」、「組織Ｂ」のＯＰが登録済みである例が示されている。
【００８９】
Ｓ３１１にて、端末利用者はＷｅｂブラウザ８２０に表示された組織選択画面にて、自身が所属するＯＰ選択ボタン２５０３にて選択状態にし、実行ボタン２５０２を押下する。なお、図１１では、ＯＰ名「組織Ｂ」が登録されている画面例を提示したが、以降の処理については、「組織Ａ」のみが登録されている状態で、認可連携を実施した場合を例として説明する。
【００９０】
Ｓ３１２にて認証連携要求を受けたアプリケーションモジュール８００は、認証連携認可処理フローを開始する。認証連携認可処理フロー以下の３つのフローから構成される。一つ目は、アプリケーションモジュール８００が、シングルサインオンモジュール７００に対してＩＤトークン取得を行うフローである。二つ目は、アプリケーションモジュール８００が、取得したＩＤトークンを用いて、シングルサインオンモジュール７００を介して認可モジュール６００に対してシングルサインオンを行うフローである。そして、三つ目は、アプリケーションモジュール８００が、シングルサインオンをしたのちに、認可モジュール６００に対してＯＡｕｔｈ  ２．０による認可トークン取得を行うフローからなる。
【００９１】
Ｓ３１３、Ｓ３１４において、アプリケーションモジュール８００はＷｅｂブラウザ８２０を介して認可モジュール６００のイニシャルログインＵＲＩに対して認証連携要求を行う。イニシャルログインＵＲＩは、アプリケーションモジュールのＯＰテーブルに登録されている情報から、ＯＰ名「組織Ａ」により特定されるイニシャルログインＵＲＩ「ｈｔｔｐｓ：／／１００ＡＡ．ｘｘ／ｒ１／ｌｏｇｉｎ」を取得し、利用する。
【００９２】
また、この認証連携要求には、少なくとも、アプリケーションモジュールのＯＰテーブルのＯＰＩＤ１「ｈｔｔｐｓ：／／ｌｏｃａｌ／ａｕｔｈ」、クライアントテーブルに格納している認可ＵＲＩ「ｈｔｔｐｓ：／／ｘｘ／ａｕｔｈｚ」を含む。さらに、認可ＵＲＩのリクエストパラメーターは以下のパラメーターを含む。すなわち、認可モジュール６００に対して認可要求するためのパラメーターである、クライアントＩＤ「ｃ００１＠ｘｘ．ｃｏｍ」、クライアント登録時に設定したリダイレクトＵＲＩ「ｈｔｔｐｓ：／／ｌｏｃａｌ／ｒｅｓ」を含む。また、不図示のクラウドサービスを利用するための認可トークン取得であれば、そのサービスのリソース範囲を示すスコープを含むよう構成する事もできる。
【００９３】
Ｓ３１５にて、認証連携認可要求を受けた認可モジュール６００は、アクセスを受けたイニシャルログインＵＲＩを用いて確認処理を行う。具体的には、認可モジュール６００は、認可モジュールのＲＰテーブルに登録されているＲＰ情報から特定されたＯＰＩＤ「ｈｔｔｐｓ：／／ｌｏｃａｌ／ａｕｔｈ」が通知されたＯＰＩＤと一致するか確認する。一致した場合に、認可モジュール６００は要求に含まれる認可ＵＲＩ「ｈｔｔｐｓ：／／ｘｘ／ａｕｔｈｚ」、および付随するパラメーターを保存する。その際、認可モジュール６００は、ランダムで重複しない値であるｓｔａｔｅを生成し、紐づけて保存する。ここでは、ｓｔａｔｅとして「１２３４５」を生成したとして説明する。表１９は、認可モジュールのＳＴＡＴＥテーブルの例を示す。
【表１９】
2016009299.tif 000021
【００９４】
次に、認可モジュール６００は、ＯＰＩＤ「ｈｔｔｐｓ：／／ｌｏｃａｌ／ａｕｔｈ」、つまりアプリケーションモジュール８００のＵＲＬを宛先として、Ｓ３１６にてＷｅｂブラウザ８２０を介して認証要求を通知する。認証要求には、少なくとも、認可モジュールのＲＰテーブルに登録されているクライアントＩＤ「ｃ００１＠ａａ．ｃｏｍ」、およびリダイレクトＵＲＩ「ｈｔｔｐｓ：／／１００ＡＡ．ｘｘ／ｒ１／ｒｅｓ」を含む。また、認証要求は、先ほど生成したＳＴＡＴＥ「１２３４５」、およびスコープとして「ｏｐｅｎｉｄ」を含む。
【００９５】
Ｓ３１７にてアプリケーションモジュール８００は、認証要求に含まれるパラメーターを検証する。より具体的には、通知されたクライアントＩＤ、リダイレクトＵＲＩがアプリケーションモジュールのＯＰテーブルに登録されている情報と一致するかを検証する。一致する場合は、ＯＰテーブルからＯＰＩＤ２を取得する。本実施形態では、特定されるＯＰＩＤ２は「ｈｔｔｐｓ：／／１００ＡＡ．ａａ／ａｕｔｈ」である。
【００９６】
Ｓ３１８にて、アプリケーションモジュール８００は、認証モジュール８１０に対して認証情報の取得を要求する。Ｓ３１９にて、認証モジュールは保存されている認証情報をアプリケーションモジュール８００に応答する。本実施形態では、認証情報としてユーザＩＤ「ｕｓｅｒ＠ｙｙ．ｄｅｖｉｃｅ．ｃｏｍ」、ＵＵＩＤ「ＡＡＡＡＡＡＢ」が応答されるものとして説明する。
【００９７】
Ｓ３２０にて、アプリケーションモジュール８００は、認可モジュール６００から認証要求を受け付けたことに起因して、クライアント認証要求をシングルサインオンモジュール７００に送信する。具体的には、アプリケーションモジュール８００は、特定したＯＰＩＤ２「ｈｔｔｐｓ：／／１００ＡＡ．ａａ／ａｕｔｈ」、つまりシングルサインオンモジュール７００に対してクライアント認証要求を通知する。クライアント認証要求には、少なくともアプリケーションモジュールのＯＰテーブルに格納されているクライアントＩＤ「ｃ００１＠ａａ．ｃｏｍ」、シークレット「ｘｘｘｘｘｘｘｘ」、およびスコープとして「ｏｐｅｎｉｄ」が含まれる。
【００９８】
Ｓ３２１にて、シングルサインオンモジュール７００はクライアントを認証する。より具体的には、受信したクライアントＩＤ、シークレットの組が、シングルサイオンモジュールのＯＰテーブルに格納されている組と一致するかを検証する。一致した場合は、シングルサインオンモジュール７００は、Ｓ３２２にてＩＤトークンを生成する保存する。
【００９９】
ＩＤトークンは、発行者情報ｉｓｓ、Ｓｕｂｊｅｃｔ識別子ｓｕｂ、この場合は認証したクライアントを一意に識別するためのクライアントＩＤを含む。さらには、ＯｐｅｎＩＤ  ＣｏｎｎｅｃｔのＩＤトークンとして定義された、ＩＤトークンの対象を示すａｕｄ、ＩＤトークンの有効期限であるｅｘｐ、ＩＤトークンを発行した日時ｉａｔを含む事ができる。
【０１００】
また、ＩＤトークンはＯｐｅｎＩＤ  Ｃｏｎｎｅｃｔの定義に従いＪＷＴ（ＪＳＯＮ  Ｗｅｂ  Ｔｏｋｅｎ）形式の文字列として生成され、さらに、ＪＷＳ（ＪＳＯＮ  Ｗｅｂ  Ｓｉｇｎａｔｕｒｅ）で定義された署名が付与される。署名には、シングルサインモジュールのＯＰオンテーブルにて、クライアントＩＤにて特定される鍵ペアを用いる。さらには、ＪＷＥ（ＪＳＯＮ  Ｗｅｂ  Ｅｎｃｒｙｐｔｉｏｎ）で定義された暗号化手段により暗号化が施される事もある。暗号化には、例えば、クライアントのシークレットを用いてもよい。また、署名と同じ鍵ペアを用いても良い。また、さらには、認可モジュール６００からＲＰ登録要求を受ける際に共通鍵を指定されるよう構成してもよい。その場合は、シングルサインオンモジュール７００は、認証連携応答としてアプリケーションモジュール８００に共通鍵を応答するよう構成する。以下に、シングルサインオンモジュールのＩＤトークンテーブルの例を示す。
【表２０】
2016009299.tif 000022
【０１０１】
図１０のＳ３２３にて、シングルサインオンモジュール７００は生成したＩＤトークンをアプリケーションモジュール８００に応答する。その際、ＩＤトークンはＪＷＴで定義された文字列として応答される。
【０１０２】
Ｓ３２４、Ｓ３２５にて、Ｗｅｂブラウザ８２０は、シングルサインオンモジュール７００による、クライアント認証要求への応答に起因して、代理認証要求をングルサインオンモジュール７００に送信する。具体的には、アプリケーションモジュール８００は、Ｗｅｂブラウザ８２０を介してＯＰＩＤ２「ｈｔｔｐｓ：／／１００ＡＡ．ａａ／ａｕｔｈ」つまり、シングルサインオンモジュール７００に対して代理認証要求を行う。代理認証要求は、ユーザに再度のログインを求めることなく端末が動的にシングルサインオンモジュールへのログインを代理する要求である。この代理認証要求には、少なくとも、アプリケーションモジュールのＯＰテーブルに格納されているクライアントＩＤ「ｃ００１＠ａａ．ｃｏｍ」、およびリダイレクトＵＲＩ「ｈｔｔｐｓ：／／１００ＡＡ．ｘｘ／ｒ１／ｒｅｓ」が含まれる。また、代理認証要求は、生成したｓｔａｔｅ「１２３４５」、およびスコープとして「ｏｐｅｎｉｄ」も含まれる。さらに、少なくとも、認証モジュール８１０から認証情報として取得したＵＵＩＤ「ＡＡＡＡＡＡＢ」、先ほどシングルサインオンモジュール７００から取得したＩＤトークンを含む。これら、ＵＵＩＤ、ＩＤトークンを格納する方法として、例えば、ＯｐｅｎＩＤ  Ｃｏｎｎｅｃｔで定義されている、ｌｏｇｉｎ＿ｈｉｎｔ  にＵＵＩＤを、ｉｄ＿ｔｏｋｅｎ＿ｈｉｎｔにＩＤトークンを格納してもよい。さらに、ＯｐｅｎＩＤ  Ｃｏｎｎｅｃｔで定義されているｐｒｏｍｐｔパラメーターとしてｎｏｎｅを指定してもよい。
【０１０３】
Ｓ３２６にて、シングルサインオンモジュール７００は代理認証要求を検証する。具体的には、シングルサインオンモジュールのＯＰテーブルのクライアントＩＤ、リダイレクトＵＲＩの組が、通知されたクライアントＩＤ、リダイレクトＵＲＩの組と一致するか検証する。次に、シングルサインオンモジュール７００は、シングルサインオンモジュールのＩＤトークンテーブルに登録されているＩＤトークンと通知されたＩＤトークンが一致するかを検証する。
【０１０４】
次に、シングルサインオンモジュール７００はＩＤトークンに含まれるｓｕｂ「ｃ００１＠ａａ．ｃｏｍ」がシングルサインオンモジュールのＯＰテーブルに登録されているクライアントＩＤからテナントＩＤ、ＯＰＩＤを取得する。本実施形態では、テナントＩＤ「１００ＡＡＲ１」、ＯＰＩＤ「ｈｔｔｐｓ：／／ｌｏｃａｌ／ａｕｔｈ」となる。
【０１０５】
この時、テナントＩＤおよびＯＰＩＤが代理認証要求を受けたＵＲＬと違う場合、かつＵＵＩＤが通知されている場合は、代理認証要求であるとして処理を行う。ＯｐｅｎＩＤ  Ｃｏｎｎｅｃｔの場合、通常、認証要求を受けると、ユーザの認証後、認可確認画面を応答し、ユーザの許可を得て処理をすすめるが、代理認証要求の場合、認可確認画面は応答しないよう構成される。これにより、ユーザの操作を簡易化することが可能となる。
【０１０６】
Ｓ３２７にて、シングルサインオンモジュール７００は代理認証処理として認可コードを生成する。より具体的には、トークンＩＤを発行し、テナントＩＤ、クライアントＩＤ、通知されたＵＵＩＤを、トークンテーブルに登録する。その際、トークン種別は認可コードとし、有効期限に当該認可コードが有効である日時を登録する。以下にシングルサインオンモジュールのトークンテーブルの例を示す。
【表２１】
2016009299.tif 000023
【０１０７】
Ｓ３２８、Ｓ３２９にて、シングルサインオンモジュールはＷｅｂブラウザ８２０を介して、リダイレクトＵＲＩ「ｈｔｔｐｓ：／／１００ＡＡ．ｘｘ／ｒ１／ｒｅｓ」、つまり認可モジュール６００に対して生成した認可コードを応答する。その際、通知されたｓｔａｔｅ「１２３４５」を付与して応答する。換言すれば、シングルサインオンモジュール７００は、代理認証要求に含まれるリダイレクトＵＲＩ「ｈｔｔｐｓ：／／１００ＡＡ．ｘｘ／ｒ１／ｒｅｓ」を用いて、Ｗｅｂブラウザに認可モジュール６００に認可応答するようリダイレクト指示を送信する。
【０１０８】
Ｓ３３０にて、認可モジュール６００は、取得した認可コードを用いてシングルサインオンモジュール７００に対してトークン取得要求を通知する。このトークン取得要求には、少なくとも認可モジュールのＲＰテーブルにてリダイレクトＵＲＩにて特定されたクライアントＩＤ、シークレット、リダイレクトＵＲＩ、および取得した認可コードを含む。
【０１０９】
Ｓ３３１にて、シングルサインオンモジュール７００は、トークン取得要求を検証する。具体的には、シングルサイオンモジュールのトークンテーブルにて認可コードが登録されているか、有効期限内かを検証する。そして、認可コードにて特定されるクライアントＩＤを取得する。次に、取得したクライアントＩＤを用いてシングルサイオンモジュールのＯＰテーブルに格納されているクライアントＩＤ、シークレット、リダイレクトＵＲＩの組が通知されたクライアントＩＤ、シークレット、リダイレクトＵＲＩの組と一致するかを検証する。
【０１１０】
Ｓ３３２にて、シングルサインオンモジュール７００は、取得した認可コードを元にＩＤトークンを生成し保存する。ＩＤトークンは、発行者情報ｉｓｓ、Ｓｕｂｊｅｃｔ識別子ｓｕｂ、この場合は認可コードに紐づくＵＵＩＤを含む。このとき、発行者情報ｉｓｓには、認可トークンから特定されたテナントＩＤに紐づくＯＰＩＤとなる。具体的には、シングルサインオンモジュールのＯＰテーブルから、テナントＩＤ「１００ＡＡＲ１」に紐づくＯＰＩＤ「ｈｔｔｐｓ：／／ｌｏｃａｌ／ａｕｔｈ」となる。さらに、ＯｐｅｎＩＤ  ＣｏｎｎｅｃｔのＩＤトークンとして定義された、ＩＤトークンの対象を示すａｕｄ、この場合は認可コードに紐づくクライアントＩＤを含む。さらに、ＩＤトークンは、ＩＤトークンの有効期限であるｅｘｐ、ＩＤトークンを発行した日時ｉａｔを含む事ができる。
【０１１１】
また、ＩＤトークンはＯｐｅｎＩＤ  Ｃｏｎｎｅｃｔの定義に従いＪＷＴ（ＪＳＯＮ  Ｗｅｂ  Ｔｏｋｅｎ）形式の文字列として生成され、さらに、ＪＷＳ（ＪＳＯＮ  Ｗｅｂ  Ｓｉｇｎａｔｕｒｅ）で定義された署名が付与される。署名には、シングルサインモジュールのＯＰオンテーブルにて、クライアントＩＤにて特定される鍵ペアを用いる。さらには、ＪＷＥ（ＪＳＯＮ  Ｗｅｂ  Ｅｎｃｒｙｐｔｉｏｎ）で定義された暗号化手段により暗号化が施される事もある。暗号化には、例えば、クライアントのシークレットを用いてもよい。また、署名と同じ鍵ペアを用いても良い。また、さらには、認可モジュール６００からＲＰ登録要求を受ける際に共通鍵を指定されるよう構成してもよい。以下に、シングルサインオンモジュールのＩＤトークンテーブルの例を示す。
【表２２】
2016009299.tif 000024
【０１１２】
Ｓ３３３にて、シングルサインオンモジュール７００は生成したＩＤトークンを認可モジュール６００に応答する。その際、ＩＤトークンはＪＷＴで定義された文字列として応答される。なお、本実施形態では、生成されるトークンをＩＤトークンのみとして説明したが別途認可トークンも生成して応答してもよい。
【０１１３】
Ｓ３３４にて、認可モジュール６００は、ＩＤトークンを検証する。より具体的には、ＩＤトークンが暗号化されている場合は、予め取り決められて手段にて復号する。次に、ＩＤトークンに含まれる発行元であるｉｓｓが、認可モジュールのＲＰテーブルに登録されているＯＰＩＤと一致するかを検証する。
【０１１４】
次に、ＩＤトークンに署名が付与されている場合は、認可モジュールのＲＰテーブルに格納されている情報を、ＩＤトークンに含まれるｉｓｓのＯＰＩＤとして特定し、その情報に含まれる公開鍵にて署名検証を行う。なお、署名検証については、ＩＤトークン取得要求の通信が十分に安全である事が検証される場合は、省略してもよい。例えば、通信がＳＳＬ／ＴＬＳで暗号化されており、その際に取得されるシングルサイオンサーバ３００のサーバ証明書が信頼できるものであった場合は、省略可能である。
【０１１５】
次に、認可モジュール６００は、ＩＤトークンに含まれるＩＤトークンの有効期限であるｅｘｐが、現在の日時範囲内であるかを検証する。そして、ＩＤトークンの対象であるａｕｄに、認可モジュールのＲＰテーブルに登録されているクライアントＩＤが含まれているかを検証する。その他、ＯｐｅｎＩＤ  Ｃｏｎｎｅｃｔで定義されているオプションを用いて検証項目を増やす事も可能である。
【０１１６】
Ｓ３３５にて、認可モジュール６００はＩＤトークンに含まれるユーザを一意に識別するＩＤであるＵＵＩＤを用いて認証トークンを生成する。具体的には、ＩＤトークンに含まれるｉｓｓを用いて、認可モジュールのＲＰテーブルからＯＰＩＤを特定する。次に、特定したＯＰＩＤのＭＡＰＩＤを取得する。本実施形態では、ＯＰＩＤ「ｈｔｔｐｓ：／／ｌｏｃａｌ／ａｕｔｈ」からＭＡＰＩＤ「１」が取得される。
【０１１７】
次に、認可モジュールのユーザマッピングテーブルから、ＭＡＰＩＤ「１」およびＩＤトークンに含まれるＵＵＩＤの組から、ユーザＩＤ、ＵＵＩＤを特定する。本実施形態では、ＵＵＩＤ「ＡＡＡＡＡＡＢ」かつ、ＭＡＰＩＤ「１」であるため、ユーザＩＤ「ｕｓｅｒ＠ｘｘ．ｃｏｍ」、ＵＵＩＤ「１００００００１」が取得される。そして、認証トークンは、取得したユーザＩＤまたはＵＵＩＤと紐づけられ、認可モジュール６００にて保存される。
【０１１８】
Ｓ３３６にて、認可モジュール６００は認証連携応答として、Ｗｅｂブラウザ８２０に対して、生成した認証トークンをＣｏｏｋｉｅに設定し、認可モジュール６００のＵＲＩにリダイレクトするよう応答する。ここで、認可モジュール６００のＵＲＩは、認可モジュールのＳＴＡＴＥテーブルにて、ｓｔａｔｅ「１２３４５」で特定されるＵＲＩとなる。結果として、Ｓ３３７にてＷｅｂブラウザ８２０は、設定されたＣｏｏｋｉｅ情報を付与した状態で、認可モジュール６００に対して認可要求する事となる。
【０１１９】
Ｓ３３８にて、認可モジュール６００は、Ｃｏｏｋｉｅとして受信した認証トークンを用いて、ユーザが認証済みかどうかを検証し、認証済みである場合は、認証トークンに紐づけられた情報をもってユーザを特定する。Ｓ３３９にて、認可モジュール６００は、受信した認可要求のうち、クライアントＩＤとリダイレクトＵＲＩの組が正しいか検証する。具体的には、認可要求に含まれるクライアントＩＤ、リダイレクトＵＲＩの組が、認可モジュールのクライアントテーブルに登録されているクライアントＩＤとリダイレクトＵＲＩの組が一致するか検証する。不一致の場合、認可モジュール６００は不図示のエラー画面を、Ｗｅｂブラウザ８２０に応答する。一致する場合、認可モジュール６００は、Ｓ３４０にてＷｅｂブラウザ８２０に対して認可確認画面を応答する。認可確認画面の例としては、図８（Ｃ）の認可確認画面２４００において、認可要求に含まれるスコープの説明を表示する領域であるスコープ表示領域２４０２が、認可要求に含まれるスコープに対応した内容に変更された画面が応答される。
【０１２０】
以下の認可フローについては、図６および図７で説明したシーケンスと同様であるため、説明を省略する。以上の処理により、認証サーバを別途設置することなく、端末への一度のログイン操作で端末利用者が各種機能を提供するサーバとシングルサインオンを実現することが可能となる。本発明においては、端末利用者が、端末からクラウドサービスを利用する際に、端末にて認証されている事をもってクラウドサービスに対してシングルサインオンが実現される。従って、認証サーバ装置を別途設ける必要がなく、また端末の認証手段に関して制限を設ける必要もないため、シングスサインオンシステムにおけるユーザの利便性が向上する。
【０１２１】
（その他の実施形態）
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（コンピュータプログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給する。そしてそのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。この場合、そのプログラム、及び該プログラムを記憶した記憶媒体は本発明を構成することになる。
【符号の説明】
【０１２２】
２００  認可サーバ
３００  シングルサインオンサーバ
４００  端末
【図１】
2016009299.tif 000025
【図２】
2016009299.tif 000026
【図３】
2016009299.tif 000027
【図４】
2016009299.tif 000028
【図５】
2016009299.tif 000029
【図６】
2016009299.tif 000030
【図７】
2016009299.tif 000031
【図８】
2016009299.tif 000032
【図９】
2016009299.tif 000033
【図１０】
2016009299.tif 000034
【図１１】
2016009299.tif 000035