JP2016085638A - サーバー装置、端末装置、システム、情報処理方法及びプログラム - Google Patents

Abstract

【課題】各ユーザーの作業負荷を増やすことなく、かつ、管理者によるＩＤマッピング情報の生成の負荷を軽減する。
【解決手段】端末装置とネットワークを介して通信可能なサーバー装置であって、前記端末装置のユーザーの固有ＩＤを含むユーザー情報を前記端末装置から受信する受信手段と、前記受信手段により受信されたユーザー情報のうち前記端末装置により指定された属性情報を含むユーザー情報に含まれる固有ＩＤと、前記サーバー装置において認証されるユーザー情報のうち前記属性情報を含むユーザー情報に含まれるユーザーの固有ＩＤとを紐付けて、前記端末装置と前記サーバー装置との認証連携に係るＩＤマッピング情報を生成する生成手段と、を有することによって課題を解決する。
【選択図】図６

Description

本発明は、サーバー装置、端末装置、システム、情報処理方法及びプログラムに関する。

近年、企業内に設置されたＰＣ、タブレット、画像形成装置等の端末が、インターネット上に展開された所謂クラウドサービスと連携し、ユーザーに機能を提供する形態が拡大している。各端末は、クラウドサービスと連携することによって、端末自身が持つ機能だけではなく、それ以外の機能もユーザーに提供することができる。
企業内に設置された端末やインターネット上に展開されたクラウドサービスを利用するためには、正当でない利用の防止やユーザーを識別するために、通常、ユーザー認証を必要とする。その結果、ユーザーは端末を用いてクラウドサービスと連携する機能を利用するために、端末及びクラウドサービスのそれぞれにて、認証情報の入力を求められることになり、利便性にかけるという課題がある。
この課題を解決する方法として、複数の認証システム間で連携することで、一方の認証システムでの認証結果をもって、他方の認証システムにて認証することができるシングルサインオン技術の利用が広がっている。例えば、Ｓｅｃｕｒｉｔｙ Ａｓｓｅｒｔｉｏｎ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ（以下ＳＡＭＬ）プロトコルや、ＯｐｅｎＩＤ Ｆｏｕｎｄａｔｉｏｎ（ｈｔｔｐ：／／ｏｐｅｎｉｄ．ｎｅｔ／ｆｏｕｎｄａｔｉｏｎ／）が規定しているＯｐｅｎＩＤ Ｃｏｎｎｅｃｔといった技術が知られている。これらのシングルサインオン技術では、一方の認証システムで認証されたユーザーを特定するＩＤと、他方の認証システムでのユーザーを特定するＩＤとを対応付けたＩＤマッピング情報を用いることで、シングルサインオンするユーザーを特定している。

シングルサインオン技術を用いることで、ユーザーは、一度だけ認証情報を入力することで複数の認証システムから認証を受けることが可能となる。しかしながら、複数の認証システムを利用する場合、それら複数の認証システム間におけるユーザー情報のＩＤマッピング情報を事前に生成しておく必要がある。そのため、認証システムの数が増大すると、ＩＤマッピング情報を生成するための作業負荷が増大するという課題がある。
特許文献１には、ＩＤマッピング情報を自動生成する技術が開示されている。特許文献１には、複数の認証システムと、それら複数の認証システムと連携して共通で利用される認証基盤とから構成される技術が開示されている。認証基盤には共通ＩＤと呼ばれる、認証基盤にてユーザーを識別するためのユーザーＩＤが登録されている。また、各認証システムのＩＤと、認証基盤の共通ＩＤとのＩＤマッピング情報を認証基盤にて管理する構成となっている。そして、各認証システムのＩＤと共通ＩＤとのＩＤマッピング情報は、ユーザーが各認証システムでの認証を受けた後に共通ＩＤへの認証を行うことによって動的に生成される。即ち、認証基盤の共通ＩＤへの認証を介して各認証システムのＩＤが紐付けられることになる。この認証基盤の共通ＩＤへの認証を介することで、セキュアに、かつ、各ユーザーの操作によってＩＤマッピング情報が動的に生成されることを実現している。結果、管理者による、大量のユーザーに対するＩＤマッピング情報の生成や管理の負荷を軽減することができる。

特開２０１２−２３４４３５号公報

従来技術により、各認証システムと認証基盤の共通ＩＤとにおいて認証情報を入力することで自動的にＩＤマッピング情報が生成されるため、管理者による大量ユーザーのＩＤマッピング情報の生成及び管理のための作業負荷を軽減することができる。しかしながら、各ユーザーが全ての認証システムと共通ＩＤとについて認証情報の入力を少なくとも一度は行う必要があり、各ユーザーの作業負荷をなくすことはできていない。
本発明は、各ユーザーの作業負荷を増やすことなく、かつ、管理者によるＩＤマッピング情報の生成の負荷を軽減することを目的とする。

そこで、本発明のサーバー装置は、端末装置とネットワークを介して通信可能なサーバー装置であって、前記端末装置のユーザーの固有ＩＤを含むユーザー情報を前記端末装置から受信する受信手段と、前記受信手段により受信されたユーザー情報のうち前記端末装置により指定された属性情報を含むユーザー情報に含まれる固有ＩＤと、前記サーバー装置において認証されるユーザー情報のうち前記属性情報を含むユーザー情報に含まれるユーザーの固有ＩＤとを紐付けて、前記端末装置と前記サーバー装置との認証連携に係るＩＤマッピング情報を生成する生成手段と、を有する。

本発明によれば、各ユーザーの作業負荷を増やすことなく、かつ、管理者によるＩＤマッピング情報の生成の負荷を軽減することができる。

シングルサインオンシステムのシステム構成の一例を示す図である。 認可サーバー及び端末のハードウェア構成の一例を示す図である。 認可サーバー及び端末のソフトウェア構成の一例を示す図である。 端末に表示される画面の一例を示す図（その１）である。 システムにおける処理の一例を示すシーケンス図（その１）である。 システムにおける処理の一例を示すシーケンス図（その２）である。 端末に表示される画面の一例を示す図（その２）である。 システムにおける処理の一例を示すシーケンス図（その３）である。 システムにおける処理の一例を示すシーケンス図（その４）である。 端末に表示される画面の一例を示す図（その３）である。

以下、本発明を実施するための形態について図面を用いて説明する。
＜実施形態１＞
本実施形態においては、端末利用者が、端末からクラウドサービスを利用する際に、端末にて認証されていることをもってシングルサインオンを実現する。そのシングルサインオンを実現するためには、以下の処理が事前に必要となる。
まず、第一の設定として端末の管理者が、クラウドサービスにてシングルサインオンをするための設定を実施する。なお本実施形態では、シングルサインオン技術として、ＯｐｅｎＩＤ Ｃｏｎｎｅｃｔを利用して説明するが、プロトコルを限定するわけではない。例えば、シングルサインオン技術であれば、ＳＡＭＬやＯｐｅｎＩＤを用いることも可能である。
次に、第二の設定として端末をクラウドサービスに登録し、当該端末であることを証明するための情報を取得しておく必要がある。この情報は、ＯＡｕｔｈ２．０でいうところのクライアントＩＤ及びシークレットである。本実施形態では、この端末登録の方法として、ＳＳＬ／ＴＬＳのＸ．５０９証明書を用いたクライアント認証を用いて、端末自身が能動的に登録処理を実施し、クライアントＩＤ、シークレットを取得するフローで説明する。しかしながら、この方法に限定するわけではない。例えば、ＩＤ、パスワードや、何かしらのトークンを用いてクライアント認証を受け、動的に登録処理するよう構成することもできる。更に、管理者が、別の方法で取得したクライアントＩＤ、シークレットを端末に登録する構成でも実現することができる。

次に、第三の設定として端末の管理者が、端末がクラウドサービスとシングルサインオンすることを許可するための設定をする。ここでは、先ほど取得したクライアントＩＤ、シークレットを用いた、ＯＡｕｔｈ２．０をプロトコルとして許可するための処理を説明するが、プロトコルを限定するわけではない。例えば、取得したクライアントＩＤ、シークレットを用いたＢａｓｉｃ認証によって、端末自身が許可を得るよう構成することも可能である。
そして、第四の設定として、複数の端末間でのユーザー情報の同期と、端末とクラウドサービスとのユーザーのＩＤマッピング情報の生成を行う。この第四の設定は、第三の設定の中で実施される場合と、端末にて端末のユーザー情報の更新を行った際に実施される場合とがある。
本実施形態では、これら第一、第二、第三、第四の設定を順次説明し、その後に、端末利用者によるシングルサインオン処理について説明する。

本実施形態に係るシングルサインオンシステムは、図１に示すような構成のネットワーク上に実現される。図１は、本実施形態に係るシングルサインオンシステムのシステム構成の一例を示す図である。１００は、Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＷＡＮ）であり、本実施形態ではＷｏｒｌｄ Ｗｉｄｅ Ｗｅｂ（ＷＷＷ）システムが構築されている。１０１は、各構成要素を接続するＬｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＬＡＮ）である。２００は、ＯＡｕｔｈ２．０を実現するための認可サーバー装置（以下、単に認可サーバーとする）である。４００Ａ、４００Ｂ（以下、４００とする）は、端末装置（以下、単に端末とする）である。端末４００は、ＰＣや、スマートフォンやタブレットと呼ばれる携帯端末や、画像形成装置等であり、端末利用者を認証するための認証モジュールを備える。この認証モジュールは不図示の認証サーバーと通信することで端末利用者を認証するよう構成することもできる。更に、端末４００は、Ｗｅｂブラウザーと、アプリケーションモジュールとを備える。ユーザーはそれらのＷｅｂブラウザーやアプリケーションモジュールを用いて認可サーバー２００と通信する。５００は、データベースサーバー装置（以下、単にデータベースサーバーとする）である。データベースサーバー５００は、認可サーバー２００とＬＡＮ１０１を介して接続しており、認可モジュールが利用するデータが格納されている。また、認可サーバー２００と端末４００とはＷＡＮ１００及びＬＡＮ１０１を介して接続されている。なお、データベースサーバー５００は、認可サーバー２００と同一のサーバー上に構成されてもよい。
このように本実施形態に係るシングルサインオンシステムでは、認可サーバー２００、データベースサーバー５００、端末４００がネットワークを介して通信可能に接続されている。

図２は、認可サーバー２００、端末４００のハードウェア構成の一例を示す図である。なお、図２に示されるハードウェアブロック図は、ＰＣ等の一般的な情報処理装置のハードウェアブロック図に相当するものとし、本実施形態の各サーバー及び端末には一般的な情報処理装置のハードウェア構成を適用できる。以下、図２のハードウェア構成を認可サーバー２００のハードウェア構成とした場合を例に説明する。
ＣＰＵ２０１は、ＲＯＭ２０３のプログラム用ＲＯＭに記憶された、或いはハードディスク（ＨＤ）等の外部メモリ２１１からＲＡＭ２０２にロードされたＯＳやアプリケーション等のプログラムを実行し、システムバス２０４に接続される各ブロックを制御する。ここでＯＳとはコンピュータ上で稼動するオペレーティングシステムの略語であり、以下オペレーティングシステムのことをＯＳと呼ぶ。ＲＡＭ２０２は、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。キーボードコントローラ（ＫＢＣ）２０５は、キーボード２０９や不図示のポインティングデバイスからのキー入力を制御する。ＣＲＴコントローラ（ＣＲＴＣ）２０６は、ＣＲＴディスプレイ２１０の表示を制御する。ディスクコントローラ（ＤＫＣ）２０７は、各種データを記憶するハードディスク（ＨＤ）等の外部メモリ２１１におけるデータアクセスを制御する。ネットワークコントローラ（ＮＣ）２０８は、ＷＡＮ１００、ＬＡＮ１０１、もしくは公衆回線を介して接続された他の機器との通信制御処理を実行する。

後述する説明においては、特に断りのない限り、認可サーバー２００における実行のハード上の主体はＣＰＵ２０１であるものとする。そして、ＣＰＵ２０１が外部メモリ２１１等に記憶されているアプリケーションプログラムを実行することにより、後述する認可サーバー２００のソフトウェア構成及びシーケンス図における認可サーバー２００の処理が実現される。
端末４００のハードウェア構成についても上述した図２の通りである。即ち、端末４００のＣＰＵ２０１が端末４００の外部メモリ２１１等に記憶されているアプリケーションプログラムを実行することにより、後述する端末４００のソフトウェア構成及びシーケンス図における端末４００の処理が実現される。

図３は、認可サーバー２００、端末４００のソフトウェア構成の一例を示す図である。認可サーバー２００は、認可モジュール６００、ＨＴＴＰサーバーモジュール６１０をアプリケーションとして備える。ＨＴＴＰサーバーモジュール６１０は、ＷＡＮ１００を介して接続する端末４００とのＨＴＴＰ通信を行うためのモジュールである。また、ＨＴＴＰサーバーモジュール６１０は、ＳＳＬ／ＴＬＳによる通信が可能に構成されており、不図示の証明書ストアを持つ。また、本実施形態におけるＨＴＴＰサーバーモジュール６１０は、後述するクライアント登録要求を受け付けるエンドポイントにて、要求元に対してＸ．５０９形式の証明書による認証を要求するよう構成されている。
認可モジュール６００は、ＨＴＴＰサーバーモジュール６１０上で動作したり、ＨＴＴＰサーバーモジュール６１０と連携して動作したりするＷｅｂアプリケーションである。認可モジュール６００は、ＨＴＴＰサーバーモジュール６１０を介して端末４００からの要求を受け付け、処理し、応答する。以後、本実施形態では、端末４００からＨＴＴＰサーバーモジュール６１０を介して認可モジュール６００とＨＴＴＰ通信する処理について、単に端末４００からの認可モジュール６００への要求及び応答として記載する。また、本実施形態では、ＨＴＴＰサーバーモジュール６１０にて、後述するクライアント登録要求を受け付けた場合は、要求元にＸ．５０９証明書を用いたクライアント認証を要求するよう構成されている。そして、クライアント認証に成功した場合、受信したクライアント認証情報を認可モジュール６００に通知するよう構成されている。また、認可モジュール６００は、ＯＡｕｔｈ２．０に対応しており、端末４００からのＯＡｕｔｈ２．０に関するリクエストを処理して応答する機能を備える。その際、認可モジュール６００は、端末４００に対して、ユーザーを認証するための画面を応答し、ユーザーを認証する機能を備える。更に、認可モジュール６００は、ＯｐｅｎＩＤ ＣｏｎｎｅｃｔのＲＰ（Ｒｅｌｙｉｎｇ Ｐａｒｔｙ）の機能を備えており、後述する端末４００にて認証された情報をもって、シングルサインオンを受ける機能を備える。

端末４００は、認証モジュール８１０、Ｗｅｂブラウザー８２０及びアプリケーションモジュール８００をアプリケーションとして備える。認証モジュール８１０は、端末４００を利用する端末利用者を認証するための機能を備える。認証モジュール８１０は、不図示の認証サーバーと通信することで端末利用者を認証するよう構成することもできる。本実施形態では、端末４００内で管理している端末ユーザー情報を用いて認証する構成で説明する。アプリケーションモジュール８００は、端末４００にて動作するアプリケーションである。アプリケーションモジュール８００は、後述する処理を行うことで、端末４００への認証を基に、認可モジュール６００へのシングルサインオンを実現する。端末４００は、ＷＷＷを利用するためのユーザーエージェントであるＷｅｂブラウザー８２０を備える。また、アプリケーションモジュール８００は、自身を証明するためのＸ．５０９形式の証明書及びその秘密鍵を保持している。そして、アプリケーションモジュール８００は、それらをＨＴＴＰサーバーモジュール６１０との通信確立時に利用することで、ＨＴＴＰサーバーモジュール６１０に対してアプリケーションモジュール８００からの要求であることを証明することができる。

図４を用いて第一の設定である、端末４００の管理者が認可モジュール６００にてシングルサインオンをするための設定を説明する。管理者は、端末４００が備えるＷｅｂブラウザー８２０を用いて認可モジュール６００のシングルサインオン設定画面にアクセスする。認可モジュール６００は、ユーザーが認証済みかどうかを検証し、未認証である場合はログイン画面を応答する。ユーザーが認証済みかどうかを検証するために、一般的には、Ｗｅｂブラウザー８２０からリクエストされるＨＴＴＰヘッダーのＣｏｏｋｉｅ情報に認証トークンが含まれているかを確認する。そして、認証トークンが含まれている場合は、認証トークンが有効か否かを検証することによって行われる。
図４（ａ）は、ログイン画面の例である。ログイン画面２０００は、ユーザーＩＤを入力するためのユーザーＩＤ入力領域２００１、パスワードを入力するためのパスワード入力領域２００２及び入力したユーザーＩＤ、パスワードを用いてユーザー認証を実行するためのログインボタン２００３を備える。端末４００の管理者は、応答されたログイン画面２０００にて、認可モジュール６００へユーザー認証するためのユーザーＩＤ、パスワードを入力し、ログインボタン２００３を押下する。Ｗｅｂブラウザー８２０は、ログインボタン２００３の押下を検知すると、ログイン要求として、ユーザーＩＤ入力領域２００１及びパスワード入力領域２００２に入力されている情報を認可モジュール６００に送信する。

表１に、認可モジュール６００のユーザーテーブルに登録されているユーザー情報の例を示す。
ログイン要求を受けた認可モジュール６００は、受信したユーザーＩＤ、パスワードの組が認可モジュール６００のユーザーテーブルに登録されているユーザー情報と合致するかを検証することで、ユーザーを認証する。例えば、認可モジュール６００は、受信したユーザーＩＤが「ａｄｍｉｎ＠ｘｘ．ｃｏｍ」で、パスワードが「ａｄｍｉｎ」であった場合、ユーザーＩＤ「ａｄｍｉｎ＠ｘｘ．ｃｏｍ」のユーザーとして認証する。そして、認可モジュール６００は、認証したことを示す認証トークンを生成し、Ｃｏｏｋｉｅに設定し、認可モジュール６００のシングルサインオン設定画面にリダイレクトされるよう応答する。認証トークンは、ユーザーＩＤ、もしくは、ユーザーをユニークに特定するためのＵＵＩＤと紐付けられ、認可モジュール６００にて保存される。認可モジュール６００は、ログイン要求の情報が合致しない場合は、不図示のログインエラー画面を応答する。なお、本実施形態では、ユーザーを認証するための情報として、ユーザーＩＤとパスワードとの組を利用する方法で説明しているが、この方法に限定するわけではない。例えば、ＳＳＬ／ＴＬＳのクライアント証明書を利用する方法や、複数の認証情報を入力することによる多要素認証といった方法を用いることも可能である。

Ｗｅｂブラウザー８２０は、Ｃｏｏｋｉｅに設定された認証トークンを用いて、認可モジュール６００のシングルサインオン設定画面へアクセスする。認可モジュール６００は、認証トークンを用いてユーザーが認証済みかどうかを検証し、認証済みである場合は認証トークンに紐付けられた情報をもってユーザーを特定する。そして、認可モジュール６００は、特定したユーザーの権限情報が「管理者」である場合に、シングルサインオン設定画面を応答する。例えば、認可モジュール６００は、認証トークンに紐付けられた情報が「ＵＵＩＤ：１０００００００」であった場合は、認可モジュール６００のユーザーテーブルのＵＵＩＤ列を検索し、一致する「行１」のユーザーであることを特定する。そして、認可モジュール６００は、行１のユーザーの権限情報列を参照すると「管理者」であることがわかる。ここで、認可モジュール６００は、特定したユーザーの権限情報が「管理者」ではなかった場合は、不図示の権限エラー画面を応答する。
図４（ｂ）は、シングルサインオン設定画面の例である。シングルサインオン設定画面２１００は、シングルサインオン設定を有効化するための有効ボタン２１０１、無効化するための無効ボタン２１０２を備える。また、シングルサインオン設定が有効な場合は、ユーザー情報のＩＤマッピング情報の生成を自動で行うか手動で行うかを選択するための自動マッピング選択ボタン２１０３を備える。自動マッピングが選択された場合は、ユーザー情報のどの属性の一致によってＩＤマッピングするか、即ち、マッピング条件を選択するための属性選択ボタン２１０４を備える。この属性選択ボタン２１０４は、本実施形態ではメールアドレスかユーザー名を選択可能に構成しているが、その他の属性を追加することも可能である。なお、自動マッピングしない場合は、不図示の画面にて、手動でＩＤマッピング情報を設定することになる。そして、これらＩＤマッピング設定を反映するためのＩＤマッピング設定ボタン２１０５を備える。本実施形態ではシングルサインオン設定が有効で、かつ、ＩＤマッピング設定としてメールアドレスによる自動マッピングが設定されているとして説明する。
以上が、第一の設定である、端末４００の管理者が認可モジュール６００にて行うシングルサインオンをするための設定である。

図５を用いて、第二の設定である端末４００を認可モジュール６００に登録する処理（以下、クライアント登録処理とする）に関するシーケンスを説明する。本シーケンスは、ユーザーが端末４００において、認可モジュール６００に未登録であるアプリケーションモジュール８００を利用する際のフローを示している。ユーザーが端末４００のアプリケーションモジュール８００利用時に認可モジュール６００に未登録である、即ち後述するクライアントＩＤ、シークレットが未取得である場合に開始されるシーケンスである。
アプリケーションモジュール８００は、自身が未登録であった場合、Ｓ１．１にて、認可モジュール６００に対して、クライアント登録要求を行う。なお、本実施形態ではアプリケーションモジュール８００がクライアント登録要求を行うきっかけを、端末４００にてユーザーが当該アプリケーションモジュール８００をインストールし、初めて起動したタイミングとして説明する。なお、他のきっかけとしては、ユーザーがアプリケーションモジュール８００の機能を選択し、不図示のリソースサーバーへのリソース要求が発生するタイミングが考えられる。また、アプリケーションモジュール８００が明示的に開始される操作を受け付ける操作画面を備え、ユーザーが端末４００にて当該操作をしたタイミングが考えられる。なお、クライアント登録要求は、クライアント名や、リダイレクトＵＲＩ等の、ＯＡｕｔｈのＡｕｔｈｏｒｉｚａｔｉｏｎ Ｃｏｄｅ Ｇｒａｎｔを利用するための情報を含む。また、その他の情報として、クライアントを説明するための文字列や、説明が記載されるサイトのＵＲＩ等の付属情報を含むよう構成することもできる。

認可サーバー２００のＨＴＴＰサーバーモジュール６１０ではクライアント認証が必要になるよう構成されている。そのため、アプリケーションモジュール８００からのクライアント登録要求に対してＨＴＴＰサーバーモジュール６１０によるクライアント認証の処理が実施される。アプリケーションモジュール８００からのクライアント登録要求を受け付けたＨＴＴＰサーバーモジュール６１０は、ＳＳＬ／ＴＬＳ通信のネゴシエーションを開始する。ＨＴＴＰサーバーモジュール６１０は、アプリケーションモジュール８００に対してクライアント認証を要求する。Ｓ１．２にて、ＨＴＴＰサーバーモジュール６１０は、不図示の証明書ストアにて設定されている証明書を用いて、取得したクライアント認証情報を検証し、アプリケーションモジュール８００をデバイス登録の要求元として認証する。なお、本実施形態ではクライアントの認証方法として、ＳＳＬ／ＴＬＳのクライアント証明書による認証方式にて説明したが、その他にも例えば、Ｂａｓｉｃ認証やＤｉｇｅｓｔ認証といった、ＩＤ及びパスワードを用いる方式等が考えられる。更には、これら主体を認証する機能を経て、認証された主体に対してクライアントを登録するための認可トークンを発行する機能を設け、当該認可トークンを検証することによってクライアント登録を受け付けるよう構成することも可能である。
Ｓ１．３にて、ＨＴＴＰサーバーモジュール６１０は、アプリケーションモジュール８００を認証した後に、認可モジュール６００に対して、アプリケーションモジュール８００から受信したクライアント登録要求を通知する。その際、ＨＴＴＰサーバーモジュール６１０は、認証したアプリケーションモジュール８００を識別するためのクライアントの認証情報も通知する。Ｓ１．４にて、認可モジュール６００は、ＨＴＴＰサーバーモジュール６１０より通知されたクライアント認証情報を取得する。

表２に、認可モジュール６００のクライアント認証情報テーブルの例を示す。
例えば、認可モジュール６００にて取得したクライアント認証情報が、「Ｉｓｓｕｅｒ＝ｘｘ．ｃｏｍ，Ｓｕｂｊｅｃｔ＝ｄｅｖ．ｘｘ．ｃｏｍ」だった場合、クライアント登録する際の権限は「ＳＳＯ可」となる。また、前記取得したクライアント認証情報が未登録だった場合は、認証エラーとなり、認可モジュール６００は、アプリケーションモジュール８００に認証エラーを応答する。
Ｓ１．５にて、認可モジュール６００は、クライアントＩＤ及びクライアントを認証するための秘匿情報であるシークレットを発行し、クライアント登録要求にて取得した情報と合わせてデータを格納する。表３に、認可モジュール６００が格納する、認可モジュール６００のクライアントテーブルの例を示す。

上記登録が完了した後に、Ｓ１．６にて、認可モジュール６００は、発行したクライアントＩＤとシークレットとを、アプリケーションモジュール８００に応答する。アプリケーションモジュール８００は、取得したクライアントＩＤ及びシークレットを保存する。その際、アプリケーションモジュール８００は、認可モジュール６００への認可要求を行うためのＵＲＩである認可ＵＲＩを格納する。この認可ＵＲＩは、クライアント登録の応答として認可モジュール６００に応答するよう構成される。表４に、アプリケーションモジュール８００のクライアントテーブルの例を示す。
以上が第二の設定であるクライアント登録処理である。このシーケンスによって、端末４００が認可モジュール６００に登録される。

図６を用いて、第三の設定である、端末４００が認可モジュール６００とシングルサインオンすることを許可するために端末４００の管理者により行われる設定に係る処理のシーケンスを説明する。また、本シーケンスにて、第四の設定である、ユーザー情報の同期処理、端末４００とクラウドサービスとにおけるユーザーのＩＤマッピング情報の生成処理についても説明する。
Ｓ２．１にて、端末４００の管理者は、端末４００にてログイン操作を行う。このログイン操作は、端末４００が備える認証モジュール８３０において定められている認証方法によって行われる。本実施形態の特徴として、この認証方法はシングルサインオンシステムと関係することなく選択することができる。認証方法としては、例えば、ユーザーＩＤ、パスワードの組み合わせを検証する方法、指紋等の生体情報を利用する方法、非接触型のＩＣカードを利用する方法、更には、複数の認証方法を組み合わせる多要素認証方法等が考えられる。また、認証モジュール８３０が、不図示の認証サーバーと通信することで端末利用者を認証するよう構成することもできる。本実施形態では、ユーザーＩＤ、パスワードの組み合わせを検証する認証方法を用いた場合を例として説明する。表５に、本実施形態における認証モジュール８１０のユーザーテーブルの例を示す。
認証モジュール８１０は、認証モジュール８１０のユーザーテーブルを参照し、ユーザーＩＤ、パスワードの組にてユーザー認証を行う。また、ＵＵＩＤは、端末４００のユーザーを一意に識別するための情報（固有ＩＤ）である。このＵＵＩＤが、後述するＩＤマッピング情報に登録されるＩＤとなる。

Ｓ２．２にて、認証モジュール８３０は、ユーザーを認証する。例えば、ユーザーＩＤが「ａｄｍｉｎ」で、パスワードが「ａｄｍｉｎ」であった場合、認証モジュール８３０は、ユーザーＩＤ「ａｄｍｉｎ」のユーザーとして認証する。Ｓ２．３にて、認証モジュール８３０は、認証したユーザーの認証情報を生成し保存する。この認証情報は、端末４００の管理者が不図示のログアウト操作を実施するか、設定された時刻が経過するまで有効な状態で保存される。認証情報には、認証したユーザーのユーザーＩＤ、ＵＵＩＤ及び権限情報が格納されている。なお、認証情報としては、各情報を直接格納するのではなく、ユーザーＩＤ、ＵＵＩＤ及び権限情報が参照可能に紐付けられたトークンでもよい。
端末４００の管理者は、認証モジュール８３０での認証を受けた後に、Ｓ２．４、Ｓ２．５にて、Ｗｅｂブラウザー８２０を用いてアプリケーションモジュール８００にアクセスする。なお、アプリケーションモジュール８００へのアクセスを開始するきっかけとしては、アプリケーションモジュール８００へアクセスするためのブックマークが保存され、そのブックマークを選択した場合が考えられる。また、アプリケーションモジュール８００が明示的に開始される操作を受け付ける操作画面を備え、端末４００の管理者が、端末４００にて当該操作をしたタイミングが考えられる。

Ｓ２．６にて、アプリケーションモジュール８００は、Ｗｅｂブラウザー８２０に対して操作画面を応答する。図７（ａ）は、アプリケーションモジュール８００が応答する操作画面の例である。操作画面２２００は、端末４００の管理者が認証連携を開始するための認証連携ボタン２２０１と、後述するユーザーが認可連携を開始するための認可連携ボタン２２０２とを備える。なお、本画面を応答する際に、アプリケーションモジュール８００は、認証モジュール８３０から認証情報を取得し、権限情報が「管理者」の場合にのみ認証連携ボタン２２０１を表示するよう構成することができる。Ｓ２．７にて、端末４００の管理者は、Ｗｅｂブラウザー８２０に表示された操作画面２２００にて、認証連携ボタン２２０１を押下する。Ｓ２．８にて、Ｗｅｂブラウザー８２０は、アプリケーションモジュール８００に対して認証連携要求を行う。
認証連携要求を受けたアプリケーションモジュール８００は、認証連携処理フローを開始する。認証連携処理フローは、アプリケーションモジュール８００が、認可モジュール６００に対してＯＡｕｔｈ２．０による認可トークン取得を行うフローと、取得した認可トークンを用いて認可モジュール６００に対して認証連携を要求するフローとからなる。ＯＡｕｔｈ２．０による認可トークン取得を行うフローとして、本実施形態ではＯＡｕｔｈ２．０に定義されているＡｕｔｈｏｒｉｚａｔｉｏｎ Ｃｏｄｅ Ｇｒａｎｔを用いて説明するが、これに限定するわけではない。例えば、Ｉｍｐｌｉｃｉｔ Ｇｒａｎｔを用いることも可能である。

Ｓ２．９、Ｓ２．１０にて、アプリケーションモジュール８００は、Ｗｅｂブラウザー８２０を介して認可モジュール６００へ認可要求を行う。この認可要求は、表４のクライアントテーブルに登録されている認可ＵＲＩ「ｈｔｔｐｓ：／／ａｕｔｈｚ／Ｃ００１／ａｕｔｈｚ」に対して行われる。また、この認可要求には、少なくとも、クライアント登録の結果取得したクライアントＩＤ及び登録したリダイレクトＵＲＩ、そして認可モジュール６００の認証連携を実施するためのリソース範囲を示すスコープが含まれる。認可要求を受けた認可モジュール６００は、ユーザーが認証済みかどうかを検証し、未認証である場合はＳ２．１１にて、ログイン画面を応答する。Ｓ２．１２、Ｓ２．１３、Ｓ２．１４にて行われる、認可モジュール６００におけるユーザー認証処理については前述の通りである。ユーザー認証処理の結果、認証トークンが生成される。
Ｓ２．１５にて、認可モジュール６００は、受信した認可要求のうち、クライアントＩＤとリダイレクトＵＲＩとの組が正しいか検証する。より具体的には、認可モジュール６００は、認可要求に含まれるクライアントＩＤ、リダイレクトＵＲＩの組が、認可モジュール６００のクライアントテーブルに登録されているクライアントＩＤ、リダイレクトＵＲＩの組と一致するか検証する。不一致の場合、認可モジュール６００は、不図示のエラー画面をＷｅｂブラウザー８２０に応答する。一致した場合、認可モジュール６００は、認証トークンからユーザーを特定する。特定したユーザーの権限情報が「管理者」でない場合、認可モジュール６００は、Ｗｅｂブラウザー８２０を介してアプリケーションモジュール８００に権限エラーを応答する。ユーザーの権限情報が「管理者」である場合、認可モジュール６００は、Ｓ２．１６にてＷｅｂブラウザー８２０に対して認可確認画面を応答する。

図７（ｂ）は、応答される認可確認画面の例である。認可確認画面２３００は、認可要求に含まれるクライアントＩＤを基に認可モジュール６００のクライアントテーブルから取得したクライアント名を表示する領域であるアクセス元表示領域２３０１を備える。また、認可確認画面２３００は、認可要求に含まれるスコープの説明を表示する領域であるスコープ表示領域２３０２を備える。更に、認可確認画面２３００は、ユーザーが上記情報の内容について認可操作を実行する許可ボタン２３０３及び拒否を実行する拒否ボタン２３０４を備える。ここで、ユーザーが拒否ボタン２３０４を押下した場合、認可モジュール６００は、Ｗｅｂブラウザー８２０を介してアプリケーションモジュール８００に権限エラーを応答する。Ｓ２．１７にて、端末４００の管理者が認可確認画面２３００で許可ボタン２３０３を押下、即ち認可操作を行った場合、Ｗｅｂブラウザー８２０は、Ｓ２．１８にて認可モジュール６００に認可されたことを通知する。
Ｓ２．１９にて、認可モジュール６００は、認可コードを発行する。より具体的には、認可モジュール６００は、トークンＩＤを発行し、認可要求に含まれるスコープ、クライアントＩＤ、認証して許可を得たユーザーのＵＵＩＤを、トークンテーブルに登録する。その際、認可モジュール６００は、トークン種別を認可コードとし、有効期限に当該認可コードが有効である日時を登録する。表６Ａに認可モジュール６００のトークンテーブルの例を示す。

Ｓ２．２０、Ｓ２．２１にて、認可モジュール６００は、発行した認可コードのトークンＩＤを付与してＷｅｂブラウザー８２０を介し、アプリケーションモジュール８００に認可を応答する。より具体的には、認可モジュール６００は、認可要求時に取得したリダイレクトＵＲＩに対してＷｅｂブラウザー８２０をリダイレクトするようＷｅｂブラウザー８２０にリダイレクト応答する。Ｓ２．２２にて、アプリケーションモジュール８００は、認可モジュール６００に対して認可トークンを要求する。この認可トークン要求には、少なくとも、取得した認可コード、保存しているクライアントＩＤ、シークレット及び認可要求時に送信したリダイレクトＵＲＩが含まれる。
Ｓ２．２３にて、認可モジュール６００は、取得したクライアントＩＤ、シークレットの組をもってクライアントを認証する。より具体的には、認可モジュール６００は、取得したクライアントＩＤ、シークレットの組が、認可モジュール６００のクライアントテーブルのクライアントＩＤ、シークレットの組と一致するかを検証することでクライアントを認証する。認可モジュール６００は、クライアント認証に失敗した場合はアプリケーションモジュール８００に認証エラーを応答する。一方、認可モジュール６００は、クライアント認証に成功した場合、認証したクライアントＩＤにて特定されるクライアントの権限情報を確認する。クライアントの権限情報が「ＳＳＯ可」でない場合、認可モジュール６００は、アプリケーションモジュール８００に権限エラーを応答する。一方、クライアントの権限情報が「ＳＳＯ可」であった場合、認可モジュール６００は、取得した認可コードを検証する。より具体的には、認可モジュール６００は、取得した認可コードのトークンＩＤが認可モジュール６００のトークンテーブルに登録されているかを検証し、登録されている場合は有効期限の範囲内かを検証する。更に、認可モジュール６００は、認可トークン要求にて取得したリダイレクトＵＲＩが、トークンＩＤに紐付くクライアントＩＤのリダイレクトＵＲＩと一致するかを検証する。

認可コード検証の結果が無効であった場合、認可モジュール６００は、アプリケーションモジュール８００にトークンエラーを応答する。そして、認可コード検証の結果が有効であった場合、認可モジュール６００は、Ｓ２．２４にて認可トークンを発行する。より具体的には、認可モジュール６００は、トークンＩＤを発行し、認可コードに紐付くスコープ、ユーザーのＵＵＩＤ、認証したクライアントＩＤを認可モジュール６００のトークンテーブルに登録する。その際、認可モジュール６００は、トークン種別を認可トークンとし、有効期限に当該認可トークンが有効である日時を登録する。また、認可モジュール６００は、検証した認可コードを削除するか、有効期限を過去の日時に更新することで無効化する。表６Ｂに、認可モジュール６００のトークンテーブルの例を示す。
Ｓ２．２５にて、認可モジュール６００は、発行した認可トークンのトークンＩＤをアプリケーションモジュール８００に応答する。その際、認可トークンの有効期限を応答するよう構成することもできる。本実施形態では、認可トークンを更新するためのリフレッシュトークンを発行しない例で説明したが、認可モジュール６００のトークンテーブルにて、リフレッシュトークンのトークンＩＤ及び有効期限を管理するよう構成することもできる。その際、認可モジュール６００が、認可トークン発行時にリフレッシュトークンも発行し、認可トークンの応答時に発行したリフレッシュトークンのトークンＩＤも含めて応答するよう構成することもできる。

Ｓ２．２６にて、認可トークンを取得したアプリケーションモジュール８００は、クライアントＩＤ、シークレット及びＸ．５０９形式の鍵ペアを発行し、自身のＯＰテーブルに登録する。この際、ＯＰＩＤは自身が認証要求を受け付けるＵＲＬとなる。表７Ａにアプリケーションモジュール８００のＯＰテーブルの例を示す。
Ｓ２．２７にて、アプリケーションモジュール８００は、取得した認可トークンを用いて認可モジュール６００に認証連携要求を行う。認証連携要求には、少なくとも、認可トークンのトークンＩＤ、ＯＰテーブルに登録したＯＰＩＤ、発行した鍵ペアの公開鍵、アプリケーションモジュール８００で発行したクライアントＩＤ、シークレットが含まれる。Ｓ２．２８にて、認可モジュール６００は、検証要求された認可トークンのトークンＩＤを検証し、検証結果としてトークンに紐付く情報を取得する。より具体的には、認可モジュール６００は、認可モジュール６００のトークンテーブルに登録されていて、かつ、有効期限内であるかを検証し、結果が「利用不可」であれば、アプリケーションモジュール８００に検証エラーの応答を返す。一方、認可モジュール６００は、検証の結果が「利用可」であれば、特定された認可トークンに紐付く情報を認可トークン情報として取得する。この認可トークン情報には、少なくとも、認可モジュール６００のトークンテーブルのクライアントＩＤ、ＵＵＩＤ及びＵＵＩＤから特定される認可モジュール６００のユーザーテーブルのユーザーＩＤが含まれる。なお、認可トークンの検証時にスコープを検証することもできる。その場合、認可モジュール６００は、認可トークンのトークンＩＤで特定される認可トークンのスコープに、必要なスコープが含まれているか否かを検証する。

Ｓ２．２９にて、認可トークンの検証結果が「利用可」であった場合、認可モジュール６００は、認証連携設定を行う。より具体的には、認可モジュール６００は、取得した情報を基に、ＲＰテーブルにデータを登録する。その際、認可モジュール６００は、認証要求の応答を受け付けるリダイレクトＵＲＩ「ｈｔｔｐｓ：／／ａｕｔｈｚ／ＲＰ００１／ｒｅｓ」及び認可トークンに紐付くクライアントＩＤを認可クライアントＩＤとして格納する。表８に、認可モジュール６００のＲＰテーブルの例を示す。
Ｓ２．３０にて、認可モジュール６００は、アプリケーションモジュール８００に認証連携応答を返す。この認証連携応答には、少なくとも、ＲＰテーブルに登録したリダイレクトＵＲＩが含まれる。Ｓ２．３１にて、アプリケーションモジュール８００は、ＯＰテーブルを更新する。より具体的には、アプリケーションモジュール８００は、取得した「リダイレクトＵＲＩ」を追加する。表７Ｂに、アプリケーションモジュール８００のＯＰテーブルの例を示す。
以上が第三の設定である。次に、第四の設定について説明する。

Ｓ２．３２にて、アプリケーションモジュール８００は、認可モジュール６００に対してユーザー情報確認要求を行う。Ｓ２．３３にて、認可モジュール６００は、後述するＩＤマッピングマスターテーブルの有無を確認する。この場合は、まだＩＤマッピングマスターテーブルは生成されていない、もしくはデータが入っていないため、Ｓ２．３４にて、認可モジュール６００は、アプリケーションモジュール８００に対して未登録であることを応答する。Ｓ２．３５にて、アプリケーションモジュール８００は、Ｗｅｂブラウザー８２０に対してユーザー情報登録確認画面を応答する。図７（ｃ）は、アプリケーションモジュール８００が応答するユーザー情報登録確認画面の例である。ユーザー情報登録確認画面２４００は、端末４００のユーザー情報を認可モジュール６００に登録するか否かを確認する画面である。ユーザー情報登録確認画面２４００は、登録を許可するボタン２４０１、拒否するボタン２４０２を備える。なお、拒否するボタン２４０２が押下された場合は、処理が終了する。
Ｓ２．３６にて、端末４００の管理者は、Ｗｅｂブラウザー８２０に表示されたユーザー情報登録確認画面２４００にて、ユーザー情報の登録を許可するボタン２４０１を押下する。Ｓ２．３７にて、Ｗｅｂブラウザー８２０は、アプリケーションモジュール８００に対してユーザー登録要求を行う。Ｓ２．３８にて、ユーザー登録要求を受けたアプリケーションモジュール８００は、認証モジュール８３０に対してユーザー情報取得要求を行う。Ｓ２．３９にて、ユーザー情報取得要求を受けた認証モジュール８３０は、表５に示す認証モジュール８３０のユーザーテーブルに登録されているユーザー情報を取得し、アプリケーションモジュール８００に取得したユーザー情報を応答する。なお、このユーザー情報には、メールアドレス等の表５に示されていない他の情報が含まれていてもよい。Ｓ２．４０にて、ユーザー情報の応答を受けたアプリケーションモジュール８００は、認可モジュール６００に対してユーザー情報登録要求を行う。ユーザー情報登録要求には、自身のＯＰＩＤ及び認証モジュール８３０から取得したユーザー情報が含まれる。

Ｓ２．４１にて、ユーザー情報登録要求を受けた認可モジュール６００は、取得した情報をＩＤマッピングマスターテーブルに保存する。その際、認可モジュール６００は、マッピングキーとして、第一の設定のシングルサインオン設定画面２１００にて設定されたＩＤマッピング設定の内容を反映する。本実施形態では、ＩＤマッピング設定としてメールアドレスによる自動マッピングが設定されている。表９に、認可モジュール６００のＩＤマッピングマスターテーブルの例を示す。
Ｓ２．４２にて、認可モジュール６００は、取得したＯＰＩＤ、ユーザー情報、ＩＤマッピングマスターテーブル及び表１に示す認可モジュール６００のユーザーテーブルの情報を基に、ＩＤマッピング情報を生成する。より具体的には、認可モジュール６００は、ＩＤマッピングマスターテーブルから、マッピングキーで指定された属性に関する情報（属性情報）を取得し、この属性の値がユーザーテーブルに登録されているユーザーとのＩＤマッピング情報を生成する。例えば、本実施形態では、メールアドレス「ａｄｍｉｎ＠ｘｘ．ｃｏｍ」が一致するとする。この場合、ＩＤマッピングマスターテーブルの端末ユーザー名「ａｄｍｉｎ」と、表１に示すユーザーテーブルのユーザーＩＤ「ａｄｍｉｎ＠ｘｘ．ｃｏｍ」が同一ユーザーとしてマッピングされる。その際、認可モジュール６００は、認証モジュール８３０から取得した端末ユーザーのＵＵＩＤと、表１に示すユーザーテーブルのＵＵＩＤとを紐付けて、ＩＤマッピングテーブルに保存する。表１０Ａに、生成された認可モジュール６００のＩＤマッピングテーブルの例を示す。

Ｓ２．４３にて、認可モジュール６００は、アプリケーションモジュール８００に対してユーザー情報登録応答を返す。Ｓ２．４４にて、アプリケーションモジュール８００は、Ｗｅｂブラウザー８２０に対して操作画面を応答し、処理を終了する。ここで応答される操作画面は、図７（ａ）にて説明した操作画面２２００である。その際、認証連携ボタン２２０１は実行済みであるとして無効状態で表示されるよう構成してもよい。
以上が、第三及び第四の設定である。これら処理の結果、端末４００の管理者にて、端末４００が認可モジュール６００とシングルサインオンすることが許可される。また、以上の第一、第二、第三、第四の設定を行うことで、その後に、端末利用者によるシングルサインオン処理を行うことが可能となる。

次に、図８、図９を用いて、シングルサインオン処理の詳細について説明する。図８は、第一、第二、第三、第四の設定がなされた端末４００にて、端末利用者が不図示のクラウドサービスを利用するための認可トークンを取得するためのシーケンスである。より具体的には、端末４００にログインしたことで、認可モジュール６００に対してシングルサインオンし、ＯＡｕｔｈ２．０の認可確認画面が提示されるまでのシーケンスである。
Ｓ３．１にて、端末利用者は、端末４００にてログイン操作を行う。このログイン操作は、端末４００が備える認証モジュール８３０において定められている認証方法によって行われる。本実施形態の特徴として、この認証方法はシングルサインオンシステムと関係することなく選択することができる。認証方法としては、例えば、ユーザーＩＤ、パスワードの組み合わせを検証する方法、指紋等の生体情報を利用する方法、非接触型のＩＣカードを利用する方法、更には、複数の認証方法を組み合わせる多要素認証方法等が考えられる。また、認証モジュール８３０が、不図示の認証サーバーと通信することで端末利用者を認証するよう構成することもできる。本実施形態では、ユーザーＩＤ、パスワードの組み合わせを検証する認証方法を用いた場合を例として説明する。ここで、本実施形態における認証モジュール８３０のユーザーテーブルは、表５を用いて上述した通りである。認証モジュール８３０のユーザーテーブルにおいて、ユーザーＩＤ、パスワードの組にてユーザー認証が行われる。また、ＵＵＩＤは、端末４００のユーザーを一意に識別するための情報（固有ＩＤ）である。このＵＵＩＤが、前述の第四の設定にて生成したＩＤマッピングテーブルの端末ＵＵＩＤに記載した情報と対応している。

Ｓ３．２にて、認証モジュール８３０は、ユーザーを認証する。例えば、ユーザーＩＤが「ｕｓｅｒ」で、パスワードが「ｕｓｅｒ」であった場合、認証モジュール８３０は、ユーザーＩＤ「ｕｓｅｒ」のユーザーとして認証する。
Ｓ３．３にて、認証モジュール８３０は、認証したユーザーの認証情報を生成し保存する。この認証情報は、端末４００の管理者が不図示のログアウト操作を実施するか、設定された時刻が経過するまで有効な状態で保存される。認証情報には、認証したユーザーのユーザーＩＤ、ＵＵＩＤ及び権限情報が格納されている。なお、認証情報としては、各情報を直接格納するのではなく、ユーザーＩＤ、ＵＵＩＤ及び権限情報が参照可能に紐付けられたトークンでもよい。端末利用者は、認証モジュール８３０での認証を受けた後に、Ｓ３．４、Ｓ３．５にて、Ｗｅｂブラウザー８２０を用いてアプリケーションモジュール８００にアクセスする。なお、アプリケーションモジュール８００へのアクセスを開始するきっかけとしては、アプリケーションモジュール８００へアクセスするためのブックマークが保存され、そのブックマークを選択した場合が考えられる。また、アプリケーションモジュール８００が明示的に開始される操作を受け付ける操作画面を備え、端末４００の管理者が端末４００にて当該操作をしたタイミングが考えられる。
Ｓ３．６にて、アプリケーションモジュール８００は、Ｗｅｂブラウザー８２０に対して操作画面を応答する。操作画面の例については、図７（ａ）を用いて説明した通りである。Ｓ３．７にて、端末利用者は、Ｗｅｂブラウザー８２０に表示された操作画面２２００にて、認可連携ボタン２２０２を押下する。Ｓ３．８にて、Ｗｅｂブラウザー８２０は、アプリケーションモジュール８００に対して認可要求を行う。

Ｓ３．９、Ｓ３．１０にて、アプリケーションモジュール８００は、Ｗｅｂブラウザー８２０を介して認可モジュール６００に対して認可要求を行う。この認可要求は、クライアントテーブルに登録されている認可ＵＲＩ「ｈｔｔｐｓ：／／ａｕｔｈｚ／Ｃ００１／ａｕｔｈｚ」に対して行われる。また、この認可ＵＲＩのリクエストパラメーターとして、クライアントＩＤ「Ｃ００１」、クライアント登録時に設定したリダイレクトＵＲＩ「ｈｔｔｐｓ：／／ＯＰ００１／ｒｅｓ」が含まれる。また、不図示のクラウドサービスを利用するための認可トークン取得であれば、そのサービスのリソース範囲を示すスコープを含むよう構成することもできる。
認可要求を受けた認可モジュール６００は、ユーザーが認証済みかどうかを検証し、未認証である場合はＲＰテーブルから情報を取得する。その際、認可モジュール６００は、認可要求に含まれるクライアントＩＤが認可クライアントＩＤに登録されているＲＰ情報を取得する。ここで取得できなかった場合、認可モジュール６００は、上述したＳ２．１１と同様にログイン画面を応答する。本実施形態では、クライアントＩＤ「Ｃ００１」を認可クライアントＩＤとして登録済みであるため、ＯＰＩＤ「ｈｔｔｐｓ：／／ＯＰ００１」の情報が取得される。そして、認可モジュール６００は、認可要求に含まれる認可ＵＲＩ「ｈｔｔｐｓ：／／ａｕｔｈｚ／Ｃ００１／ａｕｔｈｚ」及び付随するパラメーターを保存する。その際、認可モジュール６００は、ランダムで重複しない値であるｓｔａｔｅを生成し、紐付けて保存する。ここでは、ｓｔａｔｅとして「１２３４５」を認可モジュール６００が生成したとして説明する。表１１に、認可モジュール６００のＳＴＡＴＥテーブルの例を示す。

Ｓ３．１１、Ｓ３．１２にて、認可モジュール６００は、Ｗｅｂブラウザー８２０を介して、アプリケーションモジュール８００に認証要求を行う。この認証要求は、ＯＰＩＤ「ｈｔｔｐｓ：／／ＯＰ００１」、即ちアプリケーションモジュール８００のＵＲＬを宛先とする。この認証要求には、少なくとも、認可モジュール６００のＲＰテーブルに登録されているクライアントＩＤ「ＲＰ００１」、リダイレクトＵＲＩ「ｈｔｔｐｓ：／／ａｕｔｈｚ／ＲＰ００１／ｒｅｓ」、先ほど生成したｓｔａｔｅ「１２３４５」及びスコープとして「ｏｐｅｎｉｄ」が含まれる。
Ｓ３．１３にて、アプリケーションモジュール８００は、認証要求に含まれるパラメーターを検証する。より具体的には、アプリケーションモジュール８００は、通知されたクライアントＩＤ、リダイレクトＵＲＩがアプリケーションモジュール８００のＯＰテーブルに登録されている情報と一致するかを検証する。Ｓ３．１４にて、アプリケーションモジュール８００は、認証モジュール８３０に対して認証情報の取得を要求する。Ｓ３．１５にて、認証モジュール８３０は、保存されている認証情報をアプリケーションモジュール８００に応答する。本実施形態では、認証情報としてユーザーＩＤ「ｕｓｅｒ」、ＵＵＩＤ「ＡＡＡＡＡＡ２」が応答されるものとして説明する。

Ｓ３．１６にて、アプリケーションモジュール８００は、ＩＤトークンを生成し保存する。ＩＤトークンには、発行者情報ｉｓｓ、Ｓｕｂｊｅｃｔ識別子ｓｕｂ、この場合は認証モジュール８３０から取得したＵＵＩＤが含まれる。このとき、発行者情報ｉｓｓは、ＯＰＩＤとなる。更には、ＯｐｅｎＩＤ ＣｏｎｎｅｃｔのＩＤトークンとして定義された、ＩＤトークンの対象を示すａｕｄ、この場合は認証要求に含まれるクライアントＩＤとなる。更に、ＩＤトークンは、ＩＤトークンの有効期限であるｅｘｐ、ＩＤトークンを発行した日時ｉａｔを含むことができる。また、ＩＤトークンは、ＯｐｅｎＩＤ Ｃｏｎｎｅｃｔの定義に従いＪＷＴ（ＪＳＯＮ Ｗｅｂ Ｔｏｋｅｎ）形式の文字列として生成され、更に、ＪＷＳ（ＪＳＯＮ Ｗｅｂ Ｓｉｇｎａｔｕｒｅ）で定義された署名が付与される。署名には、アプリケーションモジュール８００のＯＰテーブルに登録されている鍵ペアを用いる。更には、ＪＷＥ（ＪＳＯＮ Ｗｅｂ Ｅｎｃｒｙｐｔｉｏｎ）で定義された暗号化手段により暗号化が施されることもある。暗号化には、例えば、クライアントのシークレットを用いてもよい。また、署名と同じ鍵ペアを用いてもよい。更には、認可モジュール６００から認証連携応答を受ける際に共通鍵を指定されるよう構成してもよい。表１２に、アプリケーションモジュール８００のＩＤトークンテーブルの例を示す。

Ｓ３．１７、Ｓ３．１８にて、アプリケーションモジュール８００は、Ｗｅｂブラウザー８２０を介して認可モジュール６００に認証応答を返す。認証応答には、少なくとも、生成したＩＤトークンと、認証要求に含まれるｓｔａｔｅとが含まれる。なお、本実施形態では、生成されるトークンをＩＤトークンのみとして説明したが、アプリケーションモジュール８００は、別途認可トークンを生成して応答してもよい。
Ｓ３．１９にて、認可モジュール６００は、ＩＤトークンを検証する。より具体的には、認可モジュール６００は、ＩＤトークンが暗号化されている場合は、予め取り決められた方法にて復号する。次に、認可モジュール６００は、ＩＤトークンに含まれる発行元であるｉｓｓが、認可モジュール６００のＲＰテーブルに登録されているＯＰＩＤと一致するかを検証する。次に、認可モジュール６００は、ＩＤトークンに署名が付与されている場合は、認可モジュール６００のＲＰテーブルに格納されている情報をＩＤトークンに含まれるｉｓｓのＯＰＩＤとして特定し、その情報に含まれる公開鍵にて署名検証を行う。次に、認可モジュール６００は、ＩＤトークンに含まれるＩＤトークンの有効期限であるｅｘｐが現在の日時範囲内であるかを検証する。そして、認可モジュール６００は、ＩＤトークンの対象であるａｕｄに、認可モジュール６００のＲＰテーブルに登録されているクライアントＩＤが含まれているかを検証する。更に、認可モジュール６００は、認証応答に含まれるｓｔａｔｅがＳＴＡＴＥテーブルに保存されているか確認する。その他、ＯｐｅｎＩＤ Ｃｏｎｎｅｃｔで定義されているオプションを用いて検証項目を増やすことも可能である。

Ｓ３．２０にて、認可モジュール６００は、ＩＤマッピング情報を取得する。より具体的には、認可モジュール６００は、ＩＤトークンに含まれるｉｓｓをＯＰＩＤとして、また、ｓｕｂを端末ＵＵＩＤとして、認可モジュール６００のＩＤマッピングテーブルからユーザーＩＤを取得する。本実施形態では、ＯＰＩＤ「ｈｔｔｐｓ：／／ＯＰ００１」、端末ＵＵＩＤ「ＡＡＡＡＡＡ１」であるため、ユーザーＩＤ「ａｄｍｉｎ＠ｘｘ．ｃｏｍ」が取得される。Ｓ３．２１にて、認可モジュール６００は、取得したユーザーＩＤを用いて、認証トークンを生成する。そして、認可モジュール６００は、生成した認証トークンを、取得したユーザーＩＤ、もしくはＵＵＩＤと紐付けて保存する。
Ｓ３．２２にて、認可モジュール６００は、認証連携応答として、Ｗｅｂブラウザー８２０に対して、生成した認証トークンをＣｏｏｋｉｅに設定し、認可モジュール６００のＵＲＩにリダイレクトするよう応答する。ここで、認可モジュール６００のＵＲＩは、認可モジュール６００のＳＴＡＴＥテーブルにて、ｓｔａｔｅ「１２３４５」で特定されるＵＲＩとなる。結果として、Ｓ３．２３にて、Ｗｅｂブラウザー８２０は、設定されたＣｏｏｋｉｅ情報を付与した状態で、認可モジュール６００に対して認可要求することとなる。

認可モジュール６００は、Ｃｏｏｋｉｅとして受信した認証トークンを用いて、ユーザーが認証済みかどうかを検証し、認証済みである場合は、認証トークンに紐付けられた情報をもってユーザーを特定する。そして、認可モジュール６００は、受信した認可要求のうち、クライアントＩＤとリダイレクトＵＲＩとの組が正しいか検証する。より具体的には、認可モジュール６００は、認可要求に含まれるクライアントＩＤ、リダイレクトＵＲＩの組が、認可モジュール６００のクライアントテーブルに登録されているクライアントＩＤ、リダイレクトＵＲＩの組と一致するか検証する。不一致の場合、認可モジュール６００は、不図示のエラー画面をＷｅｂブラウザー８２０に応答する。一致する場合、認可モジュール６００は、Ｓ３．２４にてＷｅｂブラウザー８２０に対して認可確認画面を応答する。認可確認画面の例については、図７（ｂ）を用いて説明した通りである。
以下の認可フローについては、図６で説明したシーケンスと同様であるため、説明を省略する。以上の処理により、端末４００の認証方法に関して制限を設けることなく、端末利用者が、端末４００からクラウドサービスを利用する際に、端末４００にて認証されていることをもってクラウドサービスに対してシングルサインオンを実現することが可能となる。

次に、図９、図１０を用いて、本実施形態の特徴である、ある端末４００にて既に第四の設定がなされている状態で、別の端末４００にて第三の設定を実施した場合のシーケンスを説明する。なお、図９のシーケンス図では、図６で説明したＳ２．３２の認可モジュール６００におけるユーザー情報確認要求までのシーケンスは同様であるため説明を省略する。
ユーザー情報確認要求を受けた認可モジュール６００は、Ｓ２．３３にて、ＩＤマッピングマスターテーブルの有無を確認する。この場合は、既にＩＤマッピングマスターテーブルに図６にて説明した情報が登録済みであるため、Ｓ４．１にて、認可モジュール６００は、アプリケーションモジュール８００に対してユーザー情報が登録済みであることを応答する。Ｓ４．２にて、アプリケーションモジュール８００は、Ｗｅｂブラウザー８２０に対してユーザー情報同期確認画面を応答する。

図１０は、アプリケーションモジュール８００が応答するユーザー情報同期確認画面の例である。ユーザー情報同期確認画面２５００は、認可モジュール６００のＩＤマッピングマスターテーブルから取得されたユーザー情報を端末４００に同期するか否かを確認する画面である。ユーザー情報同期確認画面２５００は、同期する際のモードを選択するためのモード選択ボタン２５０１、同期を許可するボタン２５０２、拒否するボタン２５０３を備える。また、同期モードとしてマージモードが選択された際は、マージする際に同一ユーザーとみなすための属性（マージ条件）を選択するための属性選択ボタン２５０４を備える。なお、拒否するボタン２５０３が押下された場合は、処理が終了する。同期モードとしては上書きモードとマージモードとの２種から選択できる。上書きモードは、端末４００のユーザー情報をクリアし、ＩＤマッピングマスターテーブルから取得したユーザー情報のみが登録されるモードである。マージモードは、ＩＤマッピングマスターテーブルから取得したユーザー情報と端末４００に登録されているユーザー情報とを、属性選択ボタン２５０４にて選択された属性を用いてマージし、登録するモードである。ここでは、属性として、ユーザー名やメールアドレス等が選択可能であるものとしているが、他のユーザー属性を選択可能とすることもできる。なお、データの整合性を考慮すると、図４（ｂ）のＩＤマッピング設定にて選択した属性と同じ属性を選択することが好ましい。

Ｓ４．３にて、端末４００の管理者は、Ｗｅｂブラウザー８２０に表示されたユーザー情報同期確認画面にて、ユーザー情報の同期を許可するボタン２５０２を押下する。Ｓ４．４にて、Ｗｅｂブラウザー８２０は、アプリケーションモジュール８００に対してユーザー同期要求を行う。このユーザー同期要求には選択された同期モードの情報が含まれる。Ｓ４．５にて、ユーザー同期要求を受けたアプリケーションモジュール８００は、認可モジュール６００に対してユーザー情報取得要求を行う。Ｓ４．６にて、ユーザー情報取得要求を受けた認可モジュール６００は、ＩＤマッピングマスターテーブルに保存されているユーザー情報を取得し、Ｓ４．７にてアプリケーションモジュール８００に応答する。
Ｓ４．８にて、認可モジュール６００のユーザー情報を取得したアプリケーションモジュール８００は、認証モジュール８３０に対してユーザー情報取得要求を行う。Ｓ４．９にて、ユーザー情報取得要求を受けた認証モジュール８３０は、認証モジュール８３０のユーザーテーブルの情報を取得し、アプリケーションモジュール８００にユーザー情報を応答する。Ｓ４．１０にて、ユーザー情報の応答を受けたアプリケーションモジュール８００は、設定された同期モードを確認する。ここで、選択された同期モード毎のシーケンスについてそれぞれ説明する。

同期モードとして上書きモードが選択された場合、Ｓ４．１１にて、アプリケーションモジュール８００は、認証モジュール８３０から取得したユーザー情報が存在した場合は、認証モジュール８３０に対して全ユーザー情報の削除を行う。その後、端末４００の管理者は、アプリケーションモジュール８００の操作画面を介して、アプリケーションモジュール８００が認可モジュール６００から取得したユーザー情報の登録を実施する。なお、認証モジュール８３０から取得したユーザー情報が存在しなかった場合、アプリケーションモジュール８００は、全ユーザー情報の削除をスキップし、認可モジュール６００から取得したユーザー情報の登録を実施する。
次に、同期モードとしてマージモードが選択された場合、アプリケーションモジュール８００は、認可モジュール６００から取得したユーザー情報と、認証モジュール８３０から取得したユーザー情報との比較を行う。より具体的には、アプリケーションモジュール８００は、マージ属性として選択された属性を比較し、一致するユーザーを同一ユーザーとして扱う。次に、Ｓ４．１１にて、アプリケーションモジュール８００は、属性比較にて属性が一致しなかったユーザー情報のうち、認可モジュール６００にのみ存在するユーザーの登録を認証モジュール８３０に対して要求する。以上が、選択された同期モード毎の説明である。なお、ここでは上述のマージモードに係るマージ処理が端末４００で実行されるものとして説明したが、マージ処理は認可サーバー２００で実行されるように構成されてもよい。より具体的には、認可モジュール６００が、アプリケーションモジュール８００から受け付けたマージ属性に従って、認可モジュール６００のユーザー情報と、アプリケーションモジュール８００から新たに受け付けたユーザー情報とをマージする。そして、認可モジュール６００は、マージしたユーザー情報をアプリケーションモジュール８００に送信する。

Ｓ４．１３にて、アプリケーションモジュール８００は、認証モジュール８３０に対してユーザー情報取得要求を行う。Ｓ４．１４にて、ユーザー情報取得要求を受けた認証モジュール８３０は、認証モジュール８３０のユーザーテーブルの情報を取得し、アプリケーションモジュール８００にユーザー情報を応答する。Ｓ４．１５にて、ユーザー情報の応答を受けたアプリケーションモジュール８００は、認可モジュール６００に対してユーザー情報登録要求を行う。ユーザー情報登録要求には、自身のＯＰＩＤ及び認証モジュール８３０から取得したユーザー情報が含まれる。
Ｓ４．１６にて、ユーザー情報登録要求を受けた認可モジュール６００は、取得した情報のうち、ＩＤマッピングマスターテーブルに登録されていないユーザー情報のみ登録を行う。ここで、登録されているか否かの判定は、第一の設定のシングルサインオン設定画面２１００にて設定されたＩＤマッピング設定に従って行われる。本実施形態では、ＩＤマッピング設定としてメールアドレスによる自動マッピングが設定されているため、メールアドレスが未登録のユーザーのみ追加登録が行われる。

Ｓ４．１７にて、認可モジュール６００は、取得したＯＰＩＤ、ユーザー情報、ＩＤマッピングマスターテーブル及び認可モジュール６００のユーザーテーブルの情報を基に、ＩＤマッピング情報を生成する。より具体的には、ＩＤマッピングマスターテーブルから、マッピングキーで指定された属性に関する情報（属性情報）を取得し、この属性の値がユーザーテーブルに登録されているユーザーとのＩＤマッピング情報を生成する。表１０Ｂに、端末４００のＯＰＩＤが「ｈｔｔｐｓ：／／ＯＰ００２」であり、同期モードとして上書きモードが設定された場合における認可モジュール６００のＩＤマッピングテーブルの例を示す。

このとき、ＯＰＩＤが「ｈｔｔｐｓ：／／ＯＰ００２」から登録されたユーザーの端末ＵＵＩＤと、既に登録されていたＯＰＩＤが「ｈｔｔｐｓ：／／ＯＰ００１」から登録されたユーザーの端末ＵＵＩＤとは異なるとしているが、端末４００の動作仕様によっては、同一のＵＵＩＤとして上書き登録され、同一のＵＵＩＤとなることもある。しかしながら、ＵＵＩＤを同一にすることは名寄せに利用される可能性があるため、ＵＵＩＤはユニークなＩＤであることが好ましい。なお、以降の処理は図６におけるＳ２．４３以降のシーケンスと同様のため説明を省略する。
以上の処理を行うことで、複数の端末４００にて管理者が第三の設定であるＯＰ登録を実施することに伴って、各ユーザーのＩＤマッピングが自動生成される。結果として、各ユーザーにおける、複数の端末４００と認可モジュール６００との間でのシングルサインオンを実現するためのＩＤマッピング情報の生成における負荷をなくすことができる。更に、管理者はＯＰ登録という操作のみでＩＤマッピング情報が生成されるため、別途ＩＤマッピング情報を生成するという作業を実施する必要がない。

次に、既に第三の設定であるＯＰ登録されている端末４００にて、端末４００の管理者が認証モジュール８３０のユーザー情報を追加した場合の処理を説明する。本処理については、図６及び図９を用いて説明した処理との差分のみ説明する。
端末４００の管理者は、図６における、Ｓ２．１、Ｓ２．３までの端末４００での認証処理の後に、Ｗｅｂブラウザー８２０を介し、アプリケーションモジュール８００の操作画面にアクセスする。そして、端末４００の管理者は、ユーザー情報の管理を選択する。ユーザー情報の管理が選択されると、アプリケーションモジュール８００は、認証モジュール８３０からユーザー情報を取得し、Ｗｅｂブラウザー８２０に不図示のユーザー情報の管理画面を応答する。端末４００の管理者は、ユーザー情報の管理画面にてユーザーを追加する。Ｗｅｂブラウザー８２０を介してユーザーの追加要求を受けたアプリケーションモジュール８００は、認証モジュール８３０に対してユーザー情報を追加する。以降、図９のＳ４．１３以降のシーケンスと同様の処理を実施することによって、認可モジュール６００にてＩＤマッピングマスターテーブルが更新される。
なお、端末４００の管理者がアプリケーションモジュール８００の操作画面を介して、ユーザー情報を追加するよう説明したが、その他の方法として、アプリケーションモジュール８００が、認証モジュール８３０のユーザー情報の更新を監視する構成も考えられる。また、アプリケーションモジュール８００が、認証モジュール８３０から通知を受けるよう構成することも考えられる。そして、そのような構成において、アプリケーションモジュール８００が、得られた情報を基にＳ４．１３以降の処理を実行するよう構成することもできる。

次に、既に第三の設定であるＯＰ登録されている複数の端末４００があり、一方の端末４００にて認証モジュール８３０に登録されているが、他方の端末４００では登録されていないユーザーが、登録されていない端末４００を利用する場合の処理を説明する。
ユーザーは、認証モジュール８３０に対してログイン操作を実施する。ログイン操作を受けた認証モジュール８３０は、ログイン操作から得られたユーザーＩＤのユーザーがユーザーテーブルに登録されていない場合に、アプリケーションモジュール８００に対して、ユーザー情報の同期処理を要求する。以降は、図９のＳ４．５以降の処理を行うことによって、ユーザー情報が同期され、ユーザーテーブルに登録される。ユーザー情報の同期処理の完了後、再度、認証処理を実行する。ここで、他の端末４００にてユーザーが登録済みであれば、ユーザーは認証を受けることが可能となる。
次に、既に第三の設定であるＯＰ登録されている複数の端末４００があり、認可モジュール６００のＩＤマッピングマスターテーブルが更新されたことを検知可能に構成されているアプリケーションモジュール８００での処理を説明する。
アプリケーションモジュール８００は、定期的な確認か、もしくはＷｅｂＳｏｋｃｅｔと呼ばれる技術によって、認可モジュール６００におけるＩＤマッピングマスターテーブルの更新を検知する。ＩＤマッピングマスターテーブルの更新を検知したアプリケーションモジュール８００が、図９で説明したＳ４．５以降の処理を実行することで、ユーザー情報の定期的な同期が行われる。

以上の処理により、第三の設定であるＯＰ登録後のユーザー情報を追加した場合においても、ユーザーの処理負荷を増やすことなく、自動的にＩＤマッピング情報を生成することができる。更に、管理者においても端末４００のユーザー情報の管理をすることで自動的にＩＤマッピング情報が生成されるため、別途ＩＤマッピング情報のメンテナンスを実施する必要がない。

＜その他の実施形態＞
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

以上、上述した各実施形態によれば、複数の端末４００にて管理者がシングルサインオンの設定を行うことに伴って各ユーザーのＩＤマッピング情報が自動生成される。これにより、各ユーザーの作業負荷を増やすことなく、かつ、管理者によるＩＤマッピング情報の生成の負荷を軽減することができる

以上、本発明の好ましい形態について詳述したが、本実施形態は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

２００ 認可サーバー、４００Ａ、４００Ｂ 端末、５００ データベースサーバー、６００ 認可モジュール、６１０ ＨＴＴＰサーバーモジュール、８００ アプリケーションモジュール、８１０ 認証モジュール、８２０ Ｗｅｂブラウザー

Claims (16)

1. 端末装置とネットワークを介して通信可能なサーバー装置であって、
   前記端末装置のユーザーの固有ＩＤを含むユーザー情報を前記端末装置から受信する受信手段と、
   前記受信手段により受信されたユーザー情報のうち前記端末装置により指定された属性情報を含むユーザー情報に含まれる固有ＩＤと、前記サーバー装置において認証されるユーザー情報のうち前記属性情報を含むユーザー情報に含まれるユーザーの固有ＩＤとを紐付けて、前記端末装置と前記サーバー装置との認証連携に係るＩＤマッピング情報を生成する生成手段と、
   を有するサーバー装置。
2. 前記受信手段により受信されたユーザー情報と、前記端末装置により前記ユーザー情報に対して指定された属性情報とを紐付けて登録する登録手段を更に有し、
   前記生成手段は、前記登録されたユーザー情報に含まれるユーザーの固有ＩＤと、前記サーバー装置において認証されるユーザー情報のうち前記登録されたユーザー情報と紐付けて登録されている属性情報を含むユーザー情報に含まれるユーザーの固有ＩＤとを紐付けて、前記ＩＤマッピング情報を生成する請求項１に記載のサーバー装置。
3. 前記端末装置からユーザー情報が登録済みであるか否かの確認要求を受け付けて未登録であることが確認された場合に、前記端末装置に対してユーザー情報の取得を要求する要求手段を更に有し、
   前記受信手段は、前記要求手段による要求に対する応答として、前記端末装置のユーザーの固有ＩＤを含むユーザー情報を前記端末装置から受信する請求項１又は２に記載のサーバー装置。
4. 他の端末装置から新たにユーザー情報が受信された場合に、前記他の端末装置により指定されたマージ条件に従って、前記サーバー装置に登録されているユーザー情報と、前記他の端末装置から新たに受信されたユーザー情報とをマージするマージ手段と、
   前記マージ手段によりマージされたユーザー情報を前記他の端末装置に送信する送信手段と、を更に有する請求項１乃至３の何れか１項に記載のサーバー装置。
5. サーバー装置とネットワークを介して通信可能な端末装置であって、
   前記サーバー装置において認証されるユーザーの固有ＩＤを含むユーザー情報が登録済みであるか否かの確認を前記サーバー装置に要求する要求手段と、
   前記要求手段による要求の応答として未登録であることが確認された場合に、前記端末装置に登録されている前記端末装置のユーザーの固有ＩＤを含むユーザー情報を前記サーバー装置に送信する第１の送信手段と、
   前記要求手段による要求の応答として登録済みであることが確認された場合に、前記サーバー装置から登録済みのユーザー情報を取得して前記端末装置に登録されているユーザー情報と同期させる同期手段と、
   前記同期手段により同期されたユーザー情報を前記サーバー装置に送信する第２の送信手段と、
   を有する端末装置。
6. 前記同期手段は、前記端末装置に登録されているユーザー情報を削除し、前記サーバー装置から取得した登録済みのユーザー情報を前記端末装置に登録する請求項５に記載の端末装置。
7. 前記同期手段は、設定されたマージ条件に従って、前記端末装置に登録されているユーザー情報に前記サーバー装置から取得した登録済みのユーザー情報をマージする請求項５に記載の端末装置。
8. 前記同期手段によるユーザー情報の同期に係る同期モードの設定を受け付けるとともに、ユーザー情報をマージさせることにより同期させる同期モードについてはマージ条件の設定を受け付ける設定画面を表示する表示手段を更に有する請求項５乃至７の何れか１項に記載の端末装置。
9. 前記サーバー装置が前記端末装置から受信したユーザー情報に基づいて前記サーバー装置と前記端末装置との認証連携に係るＩＤマッピング情報を生成する際のマッピング条件の設定を受け付ける設定画面を表示する表示手段を更に有する請求項５乃至８の何れか１項に記載の端末装置。
10. 前記サーバー装置に登録されているユーザー情報の更新を検知する検知手段を更に有し、
    前記要求手段は、前記検知手段により前記更新が検知された場合に前記確認を前記サーバー装置に要求する請求項５乃至９の何れか１項に記載の端末装置。
11. ネットワークを介して通信可能な端末装置と、サーバー装置とを含むシステムであって、
    前記端末装置は、
    前記端末装置のユーザーの固有ＩＤを含むユーザー情報を前記サーバー装置に送信する送信手段を有し、
    前記サーバー装置は、
    前記送信手段により送信されたユーザー情報を前記端末装置から受信する受信手段と、
    前記受信手段により受信されたユーザー情報のうち前記端末装置により指定された属性情報を含むユーザー情報に含まれる固有ＩＤと、前記サーバー装置において認証されるユーザー情報のうち前記属性情報を含むユーザー情報に含まれるユーザーの固有ＩＤとを紐付けて、前記端末装置と前記サーバー装置との認証連携に係るＩＤマッピング情報を生成する生成手段と、
    を有するシステム。
12. 端末装置とネットワークを介して通信可能なサーバー装置が実行する情報処理方法であって、
    前記端末装置のユーザーの固有ＩＤを含むユーザー情報を前記端末装置から受信する受信ステップと、
    前記受信ステップにより受信されたユーザー情報のうち前記端末装置により指定された属性情報を含むユーザー情報に含まれる固有ＩＤと、前記サーバー装置において認証されるユーザー情報のうち前記属性情報を含むユーザー情報に含まれるユーザーの固有ＩＤとを紐付けて、前記端末装置と前記サーバー装置との認証連携に係るＩＤマッピング情報を生成する生成ステップと、
    を含む情報処理方法。
13. サーバー装置とネットワークを介して通信可能な端末装置が実行する情報処理方法であって、
    前記サーバー装置において認証されるユーザーの固有ＩＤを含むユーザー情報が登録済みであるか否かの確認を前記サーバー装置に要求する要求ステップと、
    前記要求ステップによる要求の応答として未登録であることが確認された場合に、前記端末装置に登録されている前記端末装置のユーザーの固有ＩＤを含むユーザー情報を前記サーバー装置に送信する第１の送信ステップと、
    前記要求ステップによる要求の応答として登録済みであることが確認された場合に、前記サーバー装置から登録済みのユーザー情報を取得して前記端末装置に登録されているユーザー情報と同期させる同期ステップと、
    前記同期ステップにより同期されたユーザー情報を前記サーバー装置に送信する第２の送信ステップと、
    を含む情報処理方法。
14. ネットワークを介して通信可能な端末装置と、サーバー装置とを含むシステムにおける情報処理方法であって、
    前記端末装置が、前記端末装置のユーザーの固有ＩＤを含むユーザー情報を前記サーバー装置に送信する送信ステップと、
    前記サーバー装置が、前記送信ステップにより送信されたユーザー情報を前記端末装置から受信する受信ステップと、
    前記サーバー装置が、前記受信ステップにより受信されたユーザー情報のうち前記端末装置により指定された属性情報を含むユーザー情報に含まれる固有ＩＤと、前記サーバー装置において認証されるユーザー情報のうち前記属性情報を含むユーザー情報に含まれるユーザーの固有ＩＤとを紐付けて、前記端末装置と前記サーバー装置との認証連携に係るＩＤマッピング情報を生成する生成ステップと、
    を含む情報処理方法。
15. 端末装置とネットワークを介して通信可能なコンピュータに、
    前記端末装置のユーザーの固有ＩＤを含むユーザー情報を前記端末装置から受信する受信ステップと、
    前記受信ステップにより受信されたユーザー情報のうち前記端末装置により指定された属性情報を含むユーザー情報に含まれる固有ＩＤと、前記コンピュータにおいて認証されるユーザー情報のうち前記属性情報を含むユーザー情報に含まれるユーザーの固有ＩＤとを紐付けて、前記端末装置と前記コンピュータとの認証連携に係るＩＤマッピング情報を生成する生成ステップと、
    を実行させるためのプログラム
16. サーバー装置とネットワークを介して通信可能なコンピュータに、
    前記サーバー装置において認証されるユーザーの固有ＩＤを含むユーザー情報が登録済みであるか否かの確認を前記サーバー装置に要求する要求ステップと、
    前記要求ステップによる要求の応答として未登録であることが確認された場合に、前記コンピュータに登録されている前記コンピュータのユーザーの固有ＩＤを含むユーザー情報を前記サーバー装置に送信する第１の送信ステップと、
    前記要求ステップによる要求の応答として登録済みであることが確認された場合に、前記サーバー装置から登録済みのユーザー情報を取得して前記コンピュータに登録されているユーザー情報と同期させる同期ステップと、
    前記同期ステップにより同期されたユーザー情報を前記サーバー装置に送信する第２の送信ステップと、
    を実行させるためのプログラム。