JP2013137588A - 認証連携システムおよびｉｄプロバイダ装置 - Google Patents

Abstract

【課題】
ＩＤプロバイダのＳＳＯ装置を改造することなく、かつ、ユーザがＳＳＯを要求したときの状況に応じて、ＳＳＯの過程でアカウント登録および連携を実行する際に、人手を介さないでサービス利用可否を決定することができるようになる。
【解決手段】
実施形態のＩＤプロバイダ装置は、サービスデータの送信が許可される対象となるユーザを示すポリシ情報を記憶するポリシ情報記憶部と、認証連携要求を受信した場合に、ユーザ端末のログイン状態に応じたタイミングでポリシ評価処理とアカウント連携処理とを行なう認証連携要求事前処理部とサービスプロバイダ装置から認証連携要求を受信した場合に、当該認証連携要求を認証連携要求事前処理部に転送する認証連携要求転送部と、を備える。
【選択図】図１

Description

本発明の実施形態は、認証連携システムおよびＩＤプロバイダ装置に関する。

一度の認証手続きで複数のアプリケーションやサービスを利用できる認証連携を行うための技術として、シングルサインオン（Ｓｉｎｇｌｅ Ｓｉｇｎ Ｏｎ、以下ＳＳＯという）がある。ＳＳＯは、一つの企業のイントラネットのようなシングルドメインにおいて、複数のアプリケーションが備える認証を統合させる場合が多い。

しかし、最近では、異なるドメイン間（異なるＷＷＷサーバ間の意味であり、以下、クロスドメインという）でのＳＳＯが求められている。その理由として、企業統合や合併、海外展開などの活発化、および台頭してきたクラウドコンピューティングのＳａａＳ（Ｓｏｆｔｗａｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ）等によるアウトソーシングが挙げられる。

しかしながら、クロスドメインのＳＳＯを実現するためには、認証結果を共有するために大きな手間が発生するという問題がある。主な問題点としては以下の２点が挙げられる。

第１の問題点は、ＨＴＴＰ Ｃｏｏｋｉｅの利用がシングルドメインに限定されているため、ドメイン間でＨＴＴＰ Ｃｏｏｋｉｅを利用して認証結果を共有できないことである。第２の問題点は、ドメインごとに採用しているアクセス管理製品のＳＳＯ方式がベンダ間で異なるため、単純に導入することはできず、別途施策を用意する必要があることである。

これらの問題点を解消するため、ＳＳＯの標準化の要望がある。この要望に応じる代表的な標準技術の一つとして、非営利団体ＯＡＳＩＳ（Ｏｒｇａｎｉｚａｔｉｏｎ ｆｏｒ ｔｈｅ Ａｄｖａｎｃｅｍｅｎｔ ｏｆ Ｓｔｒｕｃｔｕｒｅｄ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｔａｎｄａｒｄｓ）が策定したＳＡＭＬ（Ｓｅｃｕｒｉｔｙ Ａｓｓｅｒｔｉｏｎ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）がある。

ＳＡＭＬは認証・認可・属性に関する情報の表現形式、および送受信手順が定義された仕様であり、目的に応じて様々な実装形態を可能にするように体系的に規定されている。主体の構成は、アイデンティティ提供者（Ｉｄｅｎｔｉｔｙ Ｐｒｏｖｉｄｅｒ、以下、ＩＤＰ、もしくはＩＤプロバイダという）、サービス提供者（Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ、以下、ＳＰもしくはサービスプロバイダという）、ユーザの３者であり、ＩＤプロバイダが発行する認証結果をサービスプロバイダが信頼することでＳＳＯを実現している。

ユーザがＳＡＭＬに基づくＳＳＯを開始する場合、一般的に次の２点について事前に準備する必要がある。１点目は、サービスプロバイダとＩＤプロバイダとの間でビジネスや技術面での情報交換や合意形成を通じて、信頼関係を構築しておくことである。２点目は、一人のユーザがサービスプロバイダごとに個別のアカウントを持ち、これらの個別のＳＰアカウントとＩＤプロバイダのアカウントを事前に連携させておくこと（以下、アカウント連携という）である。これら信頼関係の構築および事前のアカウント連携といった事前準備を終えた状態でないとユーザがＳＳＯを開始することはできない。

このような事前準備の後、ＳＳＯは以下のような手順（１）〜（６）に沿って実現される。ここでは、ユーザ端末を介した、サービスプロバイダ開始モデルのＳＳＯの手順を説明する。

（１）ユーザがサービスプロバイダに対してサービス提供を要求する。

（２）サービスプロバイダは、まだユーザの認証をしていないため、ユーザ側の端末を介して、認証リクエストをＩＤプロバイダに送る。

（３）ＩＤプロバイダは何らかの手段でユーザを認証し、認証アサーションを作成する。なお、ＳＡＭＬは、認証手段を規定せず、認証アサーションをサービスプロバイダに伝える仕組みを規定している。認証アサーションとは、サービスプロバイダが認証結果を信用できるかを判断するため、認証手段の種類やクレデンシャルがどのように作成されたかなどの情報が含まれる。

（４）ＩＤプロバイダは、作成した認証アサーションを含む認証結果を、ユーザ端末を介してサービスプロバイダに返信する。

（５）サービスプロバイダは、ＩＤプロバイダの認証結果に基づき、サービス提供の可否を決定する。

（６）ユーザは、サービスプロバイダからサービス提供を受ける。

なお、ユーザがＳＳＯ要求をしたときの起点として、ＳＡＭＬではサービスプロバイダ開始モデル（以下、ＳＰ開始モデルという）とＩＤプロバイダ開始モデル（以下、ＩＤＰ開始モデル）の２つが定義されている。ＳＰ開始モデルは、前述したＳＳＯ手順の通りであり、ユーザがＳＰにアクセスし、ＳＰがＳＡＭＬに基づいた認証リクエストを送信するところから、ＳＳＯ要求が始まるモデルである。

ＩＤＰ開始モデルは、前述のＳＳＯ手順（１）において、ユーザ端末からＩＤプロバイダに対して、サービスプロバイダのサービス提供を要求するところから始まるモデルである。したがって、ＳＳＯ手順（２）は行われず、手順（１）に続いて（３）〜（６）の処理を行う。

このように、ＳＡＭＬに基づくＳＳＯでは、ユーザが一度の認証手続きをＩＤプロバイダに行うだけで更なる認証手続きを実行せずに、複数のサービスを使用可能となる。

但し、ＳＡＭＬに基づくＳＳＯは、アイデンティティのライフサイクル全体のうち、アイデンティティの「利用」という一部分でしかない。前述したように、ＳＳＯを開始する場合、アカウント連携を行う必要があり、アカウント連携を行うには、サービスプロバイダとＩＤプロバイダ間にアイデンティティの登録、変更、削除、再発行、一時停止などの管理を包括的に連携する技術が求められる。

アイデンティティの登録、変更、削除、再発行、一時停止などを自動化する技術としてアカウントプロビジョニングがあり、その標準技術としてＳＰＭＬ（Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｓｉｏｎｉｎｇ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）がある。

ところで、前述したアカウント連携の事前準備を終えていない状態から、アカウント連携をＳＳＯの一部として動的に実行するデータ処理システムが知られている。通常、サービスプロバイダ側にユーザのアカウントが登録されてない状態、すなわち、アカウント連携が行われてない状態でＳＳＯを開始しようとした場合、エラーが発生することになっていた。

しかしながら、このデータ処理システムによれば、前述した状態でもアカウント連携をＳＳＯの一部として動的に実行できる。具体的には、サービスプロバイダがユーザからのサービス要求を受けた後、サービスプロバイダがユーザのアカウントを登録するための十分な情報を保持していないことを確認する。確認後、サービスプロバイダはＩＤプロバイダにユーザ属性を要求し、ＩＤプロバイダはサービスプロバイダに所望のユーザ属性を提供する。これにより、データ処理システムは、ＳＳＯの過程でアカウント登録および連携を実行する。

しかしながら、例えば企業において所定のユーザがＳａａＳを利用する場合、管理部門がサービスプロバイダに対して、事前のアカウント登録やアカウント連携を一括して行う必要がある。もしくは各ユーザによる任意のタイミングで、一連の承認フローを通したサービスプロバイダ利用申請手続きを経た後、管理部門がサービスプロバイダに対して、申請したユーザに関する事前のアカウント登録や連携を行うことになる。このような事前処理を経た後にユーザは、サービスプロバイダが提供するサービスを利用可能となる。

ここで、前者の事前処理を行う場合は、ＳＳＯの過程でアカウント登録および連携を実行する必要がないので、前述したデータ処理システムとは無関係である。一方、後者の承認フローを通す場合は、ユーザだけでなく、ユーザ所属先の上長や管理部門など多くの人手を介すことになり、手間暇を要する。更に、管理部門が行うアカウント登録や連携を一括して行なわない場合、人手による作業が発生し、負担も大きい。そのため、効率が悪く、利便性も悪い。

ＳａａＳなどにおいては、使いたいときに素早く使える点がメリットの１つである。しかし、後者の承認フローを通す場合には、人手による作業が発生し、負担も大きいため、このメリットを生かすことができない。そのため、ＳＳＯの過程でアカウント登録および連携を実行するシステムでは、人手を介さずにサービス利用可否を決定するシームレスな仕組みを備えていることが望ましい。

しかしながら、この仕組みを実現するためには上記のＳＡＭＬ機能を実装したＩＤプロバイダの改造が必要であり、その導入コストは大きい。

特表２００８−５３８２４７号公報

"Ａｓｓｅｒｔｉｏｎｓ ａｎｄ Ｐｒｏｔｏｃｏｌｓ ｆｏｒ ｔｈｅ ＯＡＳＩＳ Ｓｅｃｕｒｉｔｙ Ａｓｓｅｒｔｉｏｎ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ（ＳＡＭＬ） Ｖ２．０"，ＯＡＳＩＳ Ｓｔａｎｄａｒｄ，１５ Ｍａｒｃｈ ２００５， ｈｔｔｐ：／／ｄｏｃｓ．ｏａｓｉｓ−ｏｐｅｎ．ｏｒｇ／ｓｅｃｕｒｉｔｙ／ｓａｍｌ／ｖ２．０／ｓａｍｌ−ｃｏｒｅ−２．０−ｏｓ．ｐｄｆ "ＯＡＳＩＳ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｓｉｏｎｉｎｇ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ （ＳＰＭＬ） Ｖｅｒｓｉｏｎ２"， ＯＡＳＩＳ Ｓｔａｎｄａｒｄ，１ Ａｐｒｉｌ ２００６， ｈｔｔｐ：／／ｗｗｗ．ｏａｓｉｓ−ｏｐｅｎ．ｏｒｇ／ｃｏｍｍｉｔｔｅｅｓ／ｐｒｏｖｉｓｉｏｎ／ｄｏｃｓ／ｐｓｔｃ−ｓｐｍｌ２−ｏｓ．ｐｄｆ

本発明が解決しようとする課題は、ＩＤプロバイダ装置を改造する必要がないため導入が容易であり、かつ、ＳＳＯの過程でアカウント登録および連携を実行する際に人手を介さないでサービス利用可否の決定を行うことができる認証連携システムおよびＩＤプロバイダ装置を提供することである。

実施形態のＩＤプロバイダ装置は、サービスデータの送信が許可される対象となるユーザを示すポリシ情報を記憶するポリシ情報記憶部と、認証連携要求を受信した場合に、ユーザ端末のログイン状態に応じたタイミングでポリシ評価処理とアカウント連携処理とを行なう認証連携要求事前処理部と、サービスプロバイダ装置から認証連携要求を受信した場合に、当該認証連携要求を認証連携要求事前処理部に転送する認証連携要求転送部と、を備える。

第１の実施形態に係る認証連携システムのハードウェア構成の一例を示すブロック図。 第１の実施形態に係るＩＤプロバイダ装置の転送先ＵＲＬ管理テーブルの一例を示す図。 第１の実施形態に係るＩＤプロバイダ装置のＩＤＰ認証連携部の機能構成の一例を示すブロック図。 第１の実施形態に係るＩＤプロバイダ装置のＩＤＰユーザストアの一例を示す図。 第１の実施形態に係るＩＤプロバイダ装置の認証アサーションの一例を示す図。 第１の実施形態に係るＩＤプロバイダ装置の認証連携制御システムの機能構成の一例を示すブロック図。 第１の実施形態に係るＩＤプロバイダ装置の認証セッション一時記憶装置の一例を示すブロック図。 第１の実施形態に係るＩＤプロバイダ装置のポリシストアの一例を示す図。 第１の実施形態に係るサービスプロバイダ装置のＳＰユーザストアの一例を示すブロック図。 第１の実施形態に係るサービスプロバイダ装置のサービスデータストアの一例を示すブロック図。 第１の実施形態に係るサービスプロバイダ装置の検証ポリシストアの一例を示すブロック図。 第１の実施形態に係るサービスプロバイダ装置の一時記憶装置の一例を示す図。 第１の実施形態に係る認証連携システムの動作の一例を示すシーケンス図。 第１の実施形態に係る認証連携システムの動作の一例を示すシーケンス図。 第１の実施形態に係る認証連携システムの動作の一例を示すシーケンス図。 第２の実施形態に係る認証連携システムの機能構成の一例を示すブロック図。 第２の実施形態に係る認証連携システムの動作の一例を示すシーケンス図。 第２の実施形態に係る認証連携システムの動作の一例を示すシーケンス図。 第２の実施形態に係る認証連携システムの動作の一例を示すシーケンス図。 第３の実施形態に係る認証連携システムの機能構成の一例を示すブロック図。 第３の実施形態に係る認証連携システムの機能構成の一例を示すブロック図。 第３の実施形態に係る認証連携システムの動作の一例を示すシーケンス図。 第３の実施形態に係る認証連携システムの動作の一例を示すシーケンス図。 第３の実施形態に係る認証連携システムの動作の一例を示すシーケンス図。 第４の実施形態に係る認証連携システムの機能構成の一例を示すブロック図。 第４の実施形態に係る認証連携システムの動作の一例を示すシーケンス図。

以下、図面を参照して本発明の実施形態に係る認証連携システムについて説明する。

（第１の実施形態）
以下、図１乃至図１５を参照して本実施形態の認証連携システムについて説明する。

図１は、本実施形態の認証連携システムの基本構成を示すブロック図である。この認証連携システムは、ユーザが操作するユーザ端末１００に対してログイン処理を実行可能なＩＤプロバイダ装置２００と、ログイン処理が成功した場合にユーザ端末１００にサービスデータを送信可能なサービスプロバイダ装置３００とを備えている。なお、サービスプロバイダ装置３００は、複数台あってもよいが、ここでは１台のみを図示している。また、ユーザ端末１００と、ＩＤプロバイダ装置２００と、サービスプロバイダ装置３００とは、それぞれネットワークを介して接続されても良い。

ユーザ端末１００は、通常のコンピュータ機能を有し、ＩＤプロバイダ装置２００およびサービスプロバイダ装置３００と通信可能な装置であり、ユーザの操作に応じて、サービスプロバイダ装置３００の利用を要求するＳＰ利用要求をサービスプロバイダ装置３００に送信する機能と、ユーザ端末１００とＩＤプロバイダ装置２００との間でログイン処理を実行する機能と、サービスプロバイダ装置３００からサービスデータを受信する機能と、予めメモリに記憶したサービス利用アプリケーションプログラムをＣＰＵが実行することにより、当該受信したサービスデータを再生する機能と、ユーザインタフェース機能と、を備える。

ＩＤプロバイダ装置２００は、ログイン処理、すなわちサービスプロバイダ装置３００が提供するサービスを利用するユーザの認証を行う。また、ＩＤプロバイダ装置２００は、後述するポリシ情報に基づき、サービスプロバイダへのユーザのアカウント登録とアカウント連携とを行う。

ＩＤプロバイダ装置２００は、ポータルサーバ２１０、Ｗｅｂサーバ２２０、ＩＤＰ認証連携部２３０、認証連携制御システム２４０、ＩＤＰユーザストア２５０、ポリシストア２６０、認証セッション一時記憶装置（第１メモリ）２７０、および鍵記憶装置２８０を備えている。

ポータルサーバ２１０はユーザに、アクセス先のサービスプロバイダを表示する。

Ｗｅｂサーバ２２０は、リバースプロキシ装置（第１のメッセージ転送部）２２１と転送先ＵＲＬ記憶装置２２２を備え、ユーザ端末１００からのメッセージを受信する。

すなわち、Ｗｅｂサーバ２２０がメッセージを受信すると、リバースプロキシ装置２２１は、転送先ＵＲＬ記憶装置２２２を参照して受信したメッセージを転送する。

図２は転送先ＵＲＬ記憶装置２２２に記憶された転送先ＵＲＬ管理テーブル２２３の一例である。図２に示すように本実施形態の転送先ＵＲＬ管理テーブル２２３は、インターネット公開ＵＲＬと転送先ＵＲＬとが対応付けられて記憶され、各インターネット公開ＵＲＬと転送先ＵＲＬにはＩＤが付与されている。すなわち、リバースプロキシ装置２２１は、ユーザ端末１００からｗｅｂサーバ２２０が受信したメッセージに対応するインターネット公開ＵＲＬを検索し、検索結果に対応する転送先ＵＲＬに当該メッセージを転送する。

ＩＤＰ認証連携部２３０は、ＳＳＯのＩＤプロバイダ機能を有する。ここで、図３を参照して、ＩＤＰ認証連携部２３０の構成の一例について説明する。

図３に示すように、本実施形態のＩＤプロバイダ装置２００のＩＤＰ認証連携部２３０は、認証連携要求メッセージ受信部２３２、ログイン要求メッセージ送信部２３３、ログイン応答メッセージ受信部２３４、および認証連携応答メッセージ送信部２３５を備える。

認証連携要求メッセージ受信部２３２は、後述するサービスプロバイダ装置３００のＳＰ認証連携部３３０から認証連携要求メッセージを受信する。認証連携要求メッセージは例えば、ＨＴＴＰリクエストの形態であり、サービスプロバイダ装置３００がユーザ端末１００からサービス利用要求を受信した場合に、ＩＤプロバイダ装置２００に認証連携を要求するために発行するメッセージである。また、認証連携要求メッセージ受信部２３２は、ユーザ端末のログイン状態を確認し、ログイン完了状態であれば、後述する認証連携応答メッセージ送信部２３５にユーザを認証したことを示す認証連携応答メッセージの作成を依頼する。

ログイン要求メッセージ送信部２３３は、ログイン未完了のユーザ端末１００にログイン要求メッセージを送信する。

ログイン応答メッセージ受信部２３４は、ログイン要求メッセージへの応答情報として、ユーザ端末１００によって入力されたログイン応答メッセージを受信し、ユーザのログイン処理を行う。

具体的には、ログイン応答メッセージ受信部２３４は、当該ユーザ端末１００から、ログイン要求メッセージへの応答情報としてユーザＩＤおよびユーザ認証情報を含むログイン応答メッセージを受信した場合に、ＩＤプロバイダユーザストア２５０（以下、ＩＤＰユーザストア２５０という）内のユーザＩＤおよび参照情報に基づいて認証する処理である。ここで、図４を参照して、ＩＤＰユーザストア２５０について説明する。

ＩＤＰユーザストア２５０は、ＩＤプロバイダ装置２００に所属するユーザに関する属性情報（以下、ユーザ属性情報という）を記憶する。

図４に示すように、ＩＤＰユーザストア２５０は、ユーザを特定するためのユーザ属性の項目名とユーザ属性の項目値とを関連付けたユーザ属性情報２５１を記憶する。ユーザ属性情報２５１は、例えばユーザを識別するユーザＩＤと、ユーザの氏名と、ユーザの従業員番号と、ユーザの所属部と、ユーザの所属課と、ユーザの役職と、ユーザ端末のアドレス情報と、ユーザのログイン処理をした際に参照する参照情報と、ユーザの電話番号と、を項目名に含む。なお、ＩＤＰユーザストア２５０にユーザ属性情報２５１は複数記憶されているが、図４にはその一例を示している。

すなわち、ユーザ属性情報２５１は個人の情報を特徴付ける情報の集合体である。なお、ユーザ属性情報２５１はこれらには限らず、例えば勤務状態といった任意の項目名と項目値とを更に含んでもよい。また、ユーザのログイン処理をした際に参照する参照情報は、本実施形態ではパスワードを用いるが、これには限らず、例えばユーザの指紋等の生体認証情報であってもよい。

認証連携応答メッセージ送信部２３５は、認証連携要求メッセージ受信部２３２から認証連携応答メッセージ作成依頼を受信した場合に、ＩＤプロバイダ装置２００でユーザを認証したことを示す認証アサーションを含む認証連携応答メッセージを作成する。認証アサーションとは、サービスプロバイダ装置３００が認証結果を信用できるかを判断するため、認証手段の種類やクレデンシャルがどのように作成されたかなどの情報が含まれる。

ここで、図５に本実施形態のＩＤＰ認証連携部２３０が作成する認証アサーション２３１の一例を示す。

図５に示すように、認証アサーション２３１は、認証連携ＩＤと、ログイン処理の認証方式名を含むアサーション本文と、デジタル署名と含む。認証連携ＩＤとは、ＩＤプロバイダ装置２００とサービスプロバイダ装置３００の双方で、それぞれのユーザＩＤ（ユーザＩＤとＳＰ側ユーザＩＤ）を紐付けるためのＩＤであり、後述するアカウントプロビジョニング部２４７によって発行される。認証連携ＩＤは、例えば、新規に発行してもよいし、ＩＤプロバイダ装置２００のユーザＩＤを指定してもよいし、ＩＤプロバイダ装置２００とサービスプロバイダ装置３００間で共通のユーザ属性情報２５１であるメールアドレスを指定してもよい。なお、認証連携ＩＤは、後述の認証連携応答確認処理で、サービスプロバイダ装置３００が、利用要求してきたユーザを識別するために使用する。デジタル署名は、ＩＤＰ認証連携部２３０によって当該アサーション本文に対して鍵記憶装置２８０内の署名生成鍵に基づいて生成される。

なお、鍵記憶装置２８０は、ＩＤプロバイダ装置２００の署名生成鍵を記憶する。署名生成鍵としては、例えば、公開鍵暗号方式における公開鍵と秘密鍵との鍵ペアのうちの秘密鍵が使用可能となっている。

また、認証連携応答メッセージ送信部２３５は、作成した認証連携応答メッセージをＳＰ認証連携部３３０に対して送信する。

続いて、図６を参照して、認証連携制御システム２４０の構成の一例について説明する。

図６に示すように、認証連携制御システム２４０は、認証連携要求メッセージ事前処理部２４１と、ポリシ評価情報取得部２４５と、ポリシ評価部２４６と、アカウントプロビジョニング部２４７とを備える。

認証連携要求メッセージ事前処理部２４１は、ログイン状態判定部２４２と、ユーザＩＤ取得部２４３と、認証連携要求メッセージ転送部（第２のメッセージ転送部）２４４とを備え、ユーザ端末１００からＩＤプロバイダ装置２００が認証連携要求メッセージを受信した場合に事前処理を行う。事前処理については後述する。

ログイン状態判定部２４２はユーザ端末１００から、例えばＨＴＴＰリクエストの形態である認証連携要求メッセージを受信した場合に、ＨＴＴＰリクエストに含まれるＣｏｏｋｉｅに格納されたにＩＤＰ認証トークンを参照してログイン状態を判定する。ＩＤＰ認証トークンは、後述するログイン処理が行われるとＩＤプロバイダ装置２００が発行する。すなわち、ＨＴＴＰリクエスト中のＣｏｏｋｉｅにＩＤＰ認証トークンが含まれる場合、ＩＤプロバイダ装置２００においてユーザがログイン完了状態である。なお、このＣｏｏｋｉｅには当該ＩＤＰ認証トークンが発行されたユーザを示すユーザＩＤもが含まれる。

このＣｏｏｋｉｅは、例えばＩＤプロバイダ装置に備えられたＲＡＭのようなメモリに格納される。以下、Ｃｏｏｋｉｅが格納されたメモリを認証セッション一時記億装置２７０という。図７に認証セッション一時記憶装置２７０の一例を示す。

ユーザＩＤ取得部２４３は、ログイン状態判定部２４２がログイン完了状態であると判定した場合に、当該認証連携要求メッセージからＩＤＰ認証トークンに対応したユーザＩＤを取得する。

認証連携要求メッセージ転送部２４４は、ＩＤプロバイダ装置２００内には存在しないＵＲＬ（以下、ダミーＵＲＬという）に認証連携要求メッセージを転送する。転送先のダミーＵＲＬはあらかじめ設定されており、ここではダミー（１）ＵＲＬであるとする。

ポリシ評価情報取得部２４５は、ＩＤＰユーザストア２５０と、後述するサービス利用状況データストア３２０とからポリシ評価情報を取得する。ポリシ評価情報とはＩＤＰユーザストア２５０に記憶されたユーザ属性情報２５１と後述するＳＰサービスストア３２０に記憶されたユーザのサービス利用状況情報３２１〜３２４を含む情報である。

ポリシ評価部２４６は、ポリシ評価情報取得部２４５が取得したポリシ評価情報と、ポリシストア２６０で管理されるポリシ情報とに基づいて、サービスプロバイダ３００を利用しようとするユーザの利用可否を判断する。

本実施形態のポリシストア２６０は、通信が許可される対象となるユーザを示す複数のポリシ情報を記憶する。図８にポリシストア２６０の一例を示す。

図８に示すように、ポリシストア２６０は、サービスプロバイダＩＤ毎に、当該サービスプロバイダＩＤで識別されるサービスプロバイダ装置３００によるサービスデータの送信が許可されるユーザの所属および役職を示す複数の認証連携ポリシ（以下、ポリシ情報という）２６１（２６２、２６３、２６４、・・・・）を記憶する。

なお、ポリシストア２６０は、ユーザの所属および役職といった静的なポリシ（例えば、図８中のＡ〜Ｃの［１］〜［３］）に加え、更に、サービスの利用数、従量制課金の合計といった動的なポリシ（例えば、図８中のＣの［４］）を含んでもよい。

例えば、上述したポリシの各要素について、「サブジェクト」は氏名や役職、所属など、「リソース」はサービスプロバイダＩＤやＵＲＬなど、「アクション」は利用開始や利用再開など、「環境条件」は何らかの要求を行なうユーザのＩＰアドレスやアクセス可能な期間や時刻などが該当する。また、「責務条件」はポリシ（アクセス可否条件）評価の結果を受けて、認証連携の実行に際して課す作業になる。例えば、“「新規利用者を登録する」要求は許可するが、その代わりに「遊休者のＩＤを削除する」ことは確実に実行せよ”というような指示になるのである（例えば、図８中のＢの［４］の［責務条件］）。

アカウントプロビジョニング部２４７は、ポリシ評価部２４６の利用可否の判断結果に基づき、ＩＤＰユーザストア２５０からユーザ属性情報２５１を取得し、取得したユーザ属性情報２５１を用いて、ＳＰユーザストア３１０に対してアカウント登録を行う。すなわち、アカウントプロビジョニング部２４７は、認証連携ＩＤを発行する。また、アカウントプロビジョニング部２４７は、ＩＤＰユーザストア２５０とＳＰユーザストア３１０の両方に対して、アカウント連携を行う。

上述のような構成によって、認証連携制御システム２４０は、ユーザがＳＳＯを要求したときもしくはＳＳＯ処理の途中で行われるログインのタイミングで、ポリシ情報に基づき後述するアカウント登録処理とアカウント連携処理を行う。

ここでポリシ情報とは、誰（どのユーザ）が、どのサービスプロバイダ装置に、どのような操作（アクション）を行うことができるか否かが定義された、ユーザのサービスプロバイダ利用可否条件の集合体を指す。言い換えると、ポリシ情報とは、サービスプロバイダ装置３００にサービスデータの送信が許可される対象となるユーザを示す。また、ポリシ情報には、オプションとして環境条件や責務条件についても定義されるものもある。

一方、サービスプロバイダ装置３００は、ユーザが利用するサービスを提供するものである。サービスプロバイダ装置３００は、サービスプロバイダ（以下、ＳＰと記載する）ユーザストア３１０、サービス利用状況データストア３２０、ＳＰ認証連携部３３０、検証ポリシストア３４０、一時記憶装置（第２メモリ）３５０を備えている。

ＳＰユーザストア３１０は、ユーザ属性部分情報記憶手段として機能する。なお、ユーザ属性部分情報とは、ＩＤＰユーザストア２５０内のユーザ属性情報２５１内のユーザ属性の項目名および項目値のうちの一部の項目名と項目値とである。このユーザ属性部分情報とサービスプロバイダ装置３００におけるユーザＩＤ（以下、ＳＰ側ユーザＩＤという）と関連付けた情報をアカウント登録情報という３１１という。

すなわち、ＳＰユーザストア３１０は、サービスプロバイダ３００が送信するサービスデータを利用するユーザのアイデンティティ情報を記憶する。なお、ＳＰユーザストア３１０は、ユーザ属性部分情報ではなく、ユーザ属性情報２５１すべてをＳＰ側ユーザＩＤに関連付けて記憶しても良い。

具体的には、ＳＰユーザストア３１０は、図９に示すように、認証連携ＩＤと氏名とアドレス情報と電話番号などのユーザ属性情報の一部と、サービスプロバイダ装置３００内でユーザを識別するＳＰ側ユーザＩＤとを関連付けたアカウント登録情報３１１記憶している。

サービス利用状況データストア３２０は、図１０に示すように、サービスプロバイダ装置３００ごとの、ユーザ利用管理テーブル３２１と、利用数管理テーブル３２２と、ディスク使用量管理テーブル３２３と、課金料金管理テーブル３２４とを記憶し、ユーザのサービス利用状況を監視している。

ユーザ利用管理テーブル３２１は、ＳＰ側ユーザＩＤと、サービスデータの送信が許可された場合を示すサービス利用中、またはサービスデータの送信が許可されていない場合を示すサービス未利用のいずれかを示すサービス利用状況とを関連付けて書き込まれる。

利用数管理テーブル３２２は、ユーザ利用管理テーブル３２１内のサービス利用状況が示すサービス利用中の個数を示す利用数と、利用数の上限値とを関連付けて書き込まれる。

ディスク使用量管理テーブル３２３は、ユーザ利用管理テーブル３２１内のサービス利用状況が示すサービス利用中のサービスデータが使用しているディスク容量と、サービスプロバイダ装置３００におけるディスク容量の上限値とを関連付けて書き込まれる。課金料金管理テーブル３２４は、ユーザ利用管理テーブル３２１内のサービス利用状況が示すサービス利用中のサービスに課金された料金の合計と、サービスプロバイダ装置３００における課金料金の上限値とを関連付けて書き込まれる。サービスデータストア３２２には、これらの管理テーブル３２１〜３２４の他に、例えばライセンス数を管理するテーブルを記憶しても良い。

ＳＰ認証連携部３３０は、ＳＳＯのサービスプロバイダ機能を有する。ＳＰ認証連携部３３０は、具体的には、認証連携応答確認処理と、ＳＰ利用応答処理を行う。

認証連携応答確認処理は、後述する検証ポリシストア３４０内の認証アサーション検証ポリシ内の認証方式名と署名検証鍵とに基づいて、ＩＤプロバイダ装置２００のＩＤＰ認証連携部２３０が作成する認証アサーション２３１の認証方式名とデジタル署名とをそれぞれ検証し、検証した結果がいずれも正当のとき、ＳＰ認証トークンを発行し、このＳＰ認証トークンを認証連携ＩＤおよびＳＰ側ユーザＩＤに関連付けて一時記憶装置３５０に書き込む処理である。

ＳＰ利用応答処理は、この認証連携応答確認処理においてＳＰ認証トークンが発行された場合に、ユーザ端末１００にサービスプロバイダ装置３００が利用可能であると応答する処理である。

図１１に示すように検証ポリシストア３４０は、ログイン処理が成功した場合にサービスデータの送信を許可するログイン処理の認証方式名と、ＩＤプロバイダ装置２００の署名生成鍵に対応する署名検証鍵とを含む認証アサーション検証ポリシ３４１を記憶する。署名検証鍵としては、例えば、公開鍵暗号方式における公開鍵と秘密鍵との鍵ペアのうちの公開鍵が使用可能となっている。

一時記憶装置３５０は、ＲＡＭ等のような一時的なメモリであり、図１２に示すように、例えば、登録されたアカウント登録情報３１１内の認証連携ＩＤと、ＳＰ側のユーザＩＤと、発行されたＳＰ認証トークンとを関連付けて記憶する。

ここで、本実施形態の認証連携システムの認証連携処理について図１３乃至図１５を参照して説明する。

なお、本実施形態では、ＩＤプロバイダ装置２００とサービスプロバイダ装置３００との間でＳＳＯ処理が可能な状態であり、かつ当該ＩＤプロバイダ側の組織に所属するユーザが当該サービスプロバイダ装置３００にアカウントが登録されてない状態から開始される。また、ユーザのログイン状態と、ユーザからのＳＳＯ要求起点にはさまざまな組み合わせがあるが、本実施形態ではユーザのログイン状態は完了状態であり、かつユーザからのＳＳＯ要求起点がサービスプロバイダ装置３００から開始とする。

また、本実施形態の認証連携システムにおいては、ＳＳＯは上述した（１）〜（６）の手順で行なわれるとする。

この状態において、ユーザがサービスプロバイダ装置３００にサービス利用要求をしたときに、ＳＳＯ処理を実行し、サービスプロバイダ装置３００のサービスを利用可能とする本実施形態の認証連携システムの動作について説明する。

図１３乃至図１５は本実施形態の認証連携システムの動作の一例を示すシーケンス図である。なお、シーケンス図にはステップ番号を付与しており、小さい番号から順に処理が行われるとする。

図１３に示すように、ステップＳ１では、ユーザが、アカウントが未登録のサービスプロバイダ装置３００のサービスを利用するために、ユーザ端末１００を操作し所望のサービスプロバイダ装置３００にサービス要求を行なう。サービスプロバイダ装置３００へのサービス要求は、例えば、ユーザ端末１００の表示部（図示しない）に表示されたサービス公開ＵＲＬのリンクのうち、ユーザの所望のリンクを、入力部（図示しない）を用いてクリックする。

ステップＳ２ではユーザ端末１００は、ユーザの操作により、サービスプロバイダ装置３００にサービス要求（以下、ＳＰ利用要求メッセージという）を送信する。サービスプロバイダ装置３００は、アクセス管理を担うＳＰ認証連携部３３０がＳＰ利用要求メッセージを受信する。

ステップＳ３では、ＳＰ利用要求メッセージを受信したＳＰ認証連携部３３０が、ユーザの認証連携状態を確認する。認証連携状態の確認は、例えば、ユーザからのＳＰ利用要求メッセージがＨＴＴＰリクエストの形態の場合、そのＨＴＴＰリクエストに含まれるＣｏｏｋｉｅの中に、ＳＰ認証連携部３３０が発行したＳＰ認証トークンが存在するかしないかで判断する。

当該ＳＰ認証トークンが存在すれば、ＳＰ認証連携部３３０は、ユーザ端末１００の認証連携が完了した状態とみなす。一方、当該ＳＰ認証トークンが存在しない場合は、ＳＰ認証連携部３３０は、ユーザ端末１００の認証連携が未完了の状態とみなし、ユーザ端末のアドレス情報を含む認証連携要求メッセージを作成する。本実施形態では、認証連携が未完了状態とする。

ステップＳ４では、ＳＰ認証連携部３３０が、ステップＳ３での認証連携状態の確認結果、認証連携が未完了状態であるため、「ＩＤＰ認証連携部２３０の認証連携要求メッセージ受信部２３２」を宛先とした認証連携要求メッセージを発行し、ユーザ端末１００に送信する。

ステップＳ５では、ユーザ端末１００が、認証連携要求メッセージを受信すると、指定された宛先（ここでは、ＩＤＰ認証連携部２３０の認証連携要求メッセージ受信部２３２）にリダイレクトする。

ステップＳ６では、ステップＳ５においてユーザ端末１００によってリダイレクトされた認証連携要求メッセージを、一旦Ｗｅｂサーバ２２０が受信する。Ｗｅｂサーバ２２０が認証連携要求メッセージを受信すると、リバースプロキシ装置２２１が、転送先ＵＲＬ記憶装置２２２に記憶された転送先ＵＲＬ管理テーブル２２３に基づいて、メッセージ転送の要否判定を行う。判定方法は、転送先ＵＲＬ管理テーブル２２３のインターネット公開ＵＲＬフィールドの中に、受信した認証連携要求メッセージの宛先と適合するＵＲＬを検索する。ここでは、Ｎｏ．１のＩＤ「１−Ａ」が適合するため、転送先はＩＤ「１−Ｂ」の「認証連携制御システム２４０の認証連携要求メッセージ事前処理部２４１」となる。

ステップＳ７では、Ｗｅｂサーバ２２０が、リバースプロキシ装置２２１を通じて、前ステップの判定において転送先と判定されたＩＤ「１−Ｂ」の「認証連携制御システム２４０の認証連携要求メッセージ事前処理部２４１」を宛先として、認証連携要求メッセージを転送する。続いて、図１４の処理に進む。

図１４のステップＳ８では、転送された認証連携要求メッセージを受信した認証連携要求メッセージ事前処理部２４１のログイン状態判定部２４２が、ユーザのログイン状態を判定する。ログイン状態の確認は、認証セッション一時記憶装置２７０におけるＩＤＰ認証トークンの有無によって確認する。本実施形態によると、ログイン完了状態であるため、認証セッション一時記憶装置２７０にＩＤＰ認証トークンが存在する。したがって、ログイン状態判定部２４２はログイン完了状態と判定し、判定結果をユーザＩＤ取得部２４３に送信する。

続いて、ステップＳ９では、ユーザＩＤ取得部２４３が、認証セッション一時記憶装置２７０から、ステップＳ８において確認されたＩＤＰ認証トークンと対応付けられたユーザＩＤを取得する。

ステップＳ１０では、認証連携要求メッセージ事前処理部２４１が、ポリシ評価情報取得部２４５に対し、ポリシ評価情報の取得を依頼する。このとき、ステップＳ９で取得したユーザＩＤもポリシ評価情報取得部２４５に送信する。

ステップＳ１１では、ポリシ評価情報取得部２４５が、サービスプロバイダ装置３００のサービス利用状況データストア３２０にアクセスし、サービス利用状況情報３２１〜３２４を取得する（以下、サービス利用状況情報取得処理という）。

ステップＳ１２では、ポリシ評価情報取得部２４５が、認証連携要求メッセージ事前処理部２４１から受信したユーザＩＤを検索キーとして、図４に示したＩＤＰユーザストア２５０から、ユーザ属性情報２５１を取得する（以下、ユーザ属性情報取得処理という）。

ステップＳ１３では、認証連携要求メッセージ事前処理部２４１は、ポリシ評価部２４６に対し、ポリシ評価の実行を依頼する。このとき、ステップＳ１１の実行によって得られたサービス利用状況情報３２１〜３２４と、ステップＳ１２の実行によって得られたユーザ属性情報２５１を、ポリシ評価情報としてまとめ、それをポリシ評価部２４６に引き渡す。

ステップＳ１４では、ポリシ評価部２４６は、図８のポリシストア２６０から、ユーザが指定したサービスプロバイダ装置３００に関するポリシ情報２６１を取得する。

ステップＳ１５では、ポリシ評価部２４６が、ステップＳ１３で取得されたポリシ評価情報と、ステップＳ１４で取得したポリシ情報を使って、ポリシ評価を行う。以下、ステップＳ１３〜ステップＳ１５の処理をポリシ評価処理という。

ポリシ評価処理の結果、当該ユーザのサービス利用可否が決定する。本実施形態では、サービス利用が許可されたとする。

ステップＳ１６では、サービス利用が許可の場合、認証連携要求メッセージ事前処理部２４１のアカウントプロビジョニング部２４７が、当該ユーザに関するアカウントプロビジョニングを実施する。このとき、ステップＳ１２で取得されたユーザＩＤも送信する。

ステップＳ１７では、アカウントプロビジョニング部２４７が、ステップＳ１６で受信したユーザＩＤを検索キーとして、ＩＤＰユーザストア２５０から当該ユーザのユーザ属性情報２５１の一部の属性情報であるユーザ属性部分情報を取得する。

ステップＳ１８では、アカウントプロビジョニング部２４７が、当該ユーザのＳＰ側ユーザＩＤを作成し、取得したユーザ属性部分情報と対応付けてＳＰユーザストア３１０に登録するとともに、ＩＤプロバイダ装置２００とサービスプロバイダ装置３００の両アカウントを紐付ける認証連携ＩＤも登録する。本実施形態では、認証連携ＩＤとして、ＩＤプロバイダ装置２００のユーザＩＤを指定する。

以下、ステップＳ１６〜ステップＳ１８の処理をアカウントプロビジョニング処理（アカウント連携処理）という。続いて、図１５のステップＳ１９の処理に進む。

図１５のステップＳ１９では、認証連携要求メッセージ事前処理部２４１の認証連携要求メッセージ転送部２４４が、ＩＤプロバイダ装置２００内には存在しないダミーのＵＲＬを宛先として、ユーザ端末１００に向けて認証連携要求メッセージを転送する。ここでは、ダミーのＵＲＬはダミー（１）ＵＲＬであるとする。

ステップＳ２０では、認証連携要求メッセージを受信したユーザ端末１００が、指定のＵＲＬ、すなわち、ダミー（１）ＵＲＬに認証連携要求メッセージをリダイレクトする。

ステップＳ２１では、Ｗｅｂサーバ２２０が、ユーザ端末１００によってリダイレクトされた認証連携要求メッセージを一旦受信する。Ｗｅｂサーバ２２０のリバースプロキシ装置２２１は、転送先ＵＲＬ記憶装置２２２に保存された転送先ＵＲＬ管理テーブル２２３に基づいたメッセージ転送の要否判定を行う。なお、判定方法は、転送先ＵＲＬ管理テーブル２２３のインターネット公開ＵＲＬフィールドの中から、ステップＳ２０で受信した認証連携要求メッセージの宛先と適合するＵＲＬを検索する。ここでは、ＩＤ「１−Ｃ」が適合するため、転送先はＩＤ「１−Ｄ」、すなわちＩＤＰ認証連携部２３０の認証連携要求メッセージ受信部２３２となる。続いて、メッセージ転送処理が行われる。

ステップＳ２２では、Ｗｅｂサーバ２２０のリバースプロキシ装置２２１が、ステップＳ２１の判定結果に基づいて、ＩＤＰ認証連携部２３０の認証連携要求メッセージ受信部２３２を宛先として、認証連携要求メッセージを転送する。

ステップＳ２３では、ＩＤＰ認証連携部２３０の認証連携要求メッセージ受信部２３２が、認証連携要求メッセージを受信後、ユーザのログイン状態を確認する。ログイン状態の確認は、例えば認証セッション一時記憶装置２７０にユーザに発行されたＩＤＰ認証トークンが記憶されているか否かを確認することによって行なう。本実施形態ではログイン完了状態としているためＩＤＰ認証トークンが存在する。

ステップＳ２４では、ＩＤＰ認証連携部２３０の認証連携要求メッセージ受信部２３２が、ログイン状態の確認後、ログイン完了状態であるため、認証連携応答メッセージ送信部２３５に対し、認証連携応答メッセージの送信を要求する。認証連携応答メッセージとは、サービスプロバイダ３００に、ＩＤプロバイダ装置２００でユーザを認証したことを示す認証アサーションを含む。

ステップＳ２５では、認証連携応答メッセージ送信部２３５が、ＩＤプロバイダ装置２００側でユーザを認証したことを証明する認証アサーションを作成し、作成した認証アサーションを含める認証連携応答メッセージを作成する。作成した認証連携応答メッセージはＳＰ認証連携部３３０を宛先として、ユーザ端末１００に送信する。

ステップＳ２６では、ユーザ端末１００が、指定の宛先であるＳＰ認証連携部３３０に対し、受信した認証連携応答メッセージをリダイレクトする。

ステップＳ２７では、認証連携応答メッセージを受信したＳＰ認証連携部３３０が、認証連携応答確認処理を行い、確認結果に基づいて認証連携を行う。

認証連携応答確認処理では、具体的には、ＳＰ認証連携部３３０は、受信したメッセージに含まれる認証アサーションの検証を行う。なお、認証アサーションの検証は、図１１に示した検証ポリシストア３４０の認証アサーション検証ポリシに従って行う。

検証の結果、問題がなければ、ＳＰ認証連携部３３０は認証連携を完了し、ＳＰ認証トークンを発行する。ＳＰ認証連携部３３０が発行したＳＰ認証トークンは、例えば、ＨＴＴＰ Ｃｏｏｋｉｅやセッション情報に格納する。なお、ステップＳ２４〜Ｓ２７の処理を認証連携応答処理という。

ステップＳ２８では、認証連携を完了したＳＰ認証連携部３３０が、ユーザ端末１００に当該ＳＰ認証トークンとサービスデータとを含むＳＰ利用応答メッセージを送信し、ユーザに利用可能である旨を通知するＳＰ利用応答処理を行う。これによって、ＩＤプロバイダ装置２００所属のユーザとサービスプロバイダ装置３００との間でのＳＳＯ処理が終了する。

上述のように、本実施形態の認証連携システムによると、ＩＤプロバイダ装置２００の組織に所属するユーザが、サービスプロバイダ装置３００にアカウントが登録されてない状態であり、ユーザのログイン状態は完了状態であり、かつユーザからのＳＳＯ要求起点がサービスプロバイダ装置３００から開始する場合において、ＳＳＯの過程でアカウント登録および連携を実行する際の人手を介さないサービス利用可否の決定を行うことが可能となる。

具体的には、本実施形態の認証連携システムは、ＳＳＯ処理手順（２）と（３）の間に、ポリシストア２６０に事前に記憶されたサービス利用に関するポリシ情報２６１とサービス利用状況データストア３２０の利用状況３２１〜３２４に基づき、サービスプロバイダ装置３００が提供するサービスを、認証連携要求を行なったユーザが利用可能か否かを評価した後、サービスプロバイダ装置３００へのアカウント登録とアカウント連携を行う処理を割り込ませることで、ユーザ端末１００を介したサービスプロバイダ装置３００が提供するサービスの利用申請からＳＳＯに至る一連の処理を自動化させることができる。したがって、本実施形態の認証連携システムによって、ユーザ所属の上長やＩＳ部門など人手を介すことなく、ユーザがスムーズにサービス利用を開始できる。

また、本実施形態の認証連携システムによると、ＩＤプロバイダ装置２００の認証連携サーバ２３０が、ＳＳＯ手順（２）〜（４）の処理を連続して行う中で、ＳＳＯ手順（３）の直前に、ポリシ評価、およびアカウント登録・アカウント連携を行なうアカウントプロビジョニング処理の割り込みをＩＤプロバイダ装置の認証連携サーバ製品を直接改造することなく実現することが可能となる。このため、導入コストも低く、容易に、かつ人手を介さずにサービス利用可否を決定できる認証連携システムの提供が可能となる。

また、本実施形態の認証連携システムによると、ユーザがＳＳＯを要求したときの起点が、サービスプロバイダ装置３００の動作が開始したときであって、ユーザのログインが完了である場合に、適切なタイミングで、ポリシ評価とアカウントプロビジョニングを実施できる。

（第２の実施形態）
第２の実施形態の認証連携システムについて図１６乃至図１９を参照して説明する。

本実施形態は第１の実施形態と同様に、ＩＤプロバイダ装置２００とサービスプロバイダ装置３００との間でＳＳＯ処理が可能な状態であり、かつ当該ＩＤプロバイダ装置２００が設置された組織に所属するユーザが当該サービスプロバイダ装置３００にアカウントが登録されてない状態から開始される。また、本実施形態の認証連携システムは第１の実施形態と同様に、ＳＳＯは上述した（１）〜（６）の手順で行なわれるとする。

また、ユーザのログイン状態と、ユーザからのＳＳＯ要求起点にはさまざまな組み合わせがあるが、本実施形態ではユーザのログイン状態は未完了状態であり、かつユーザからのＳＳＯ要求起点がサービスプロバイダ装置３００から開始とする。

ここで、図１６を参照して、本実施形態の認証連携システムの機能構成について説明する。なお、第１の実施形態と同一の構成には同一の符号を付し、説明は省略する。

図１６は本実施形態の認証連携制御システム２４０の機能構成の一例を示す図である。図１６に示すように、本実施形態の認証連携制御システム２４０は、ポリシ評価情報取得部２４５と、ポリシ評価部２４６と、アカウントプロビジョニング部２４７と、ログイン応答メッセージ事前処理部２９０を備える。

ログイン応答メッセージ事前処理部２９０は、認証情報抽出部２９１と、認証識別部２９２と、ログイン応答メッセージ転送部２９３とを備える。

認証情報抽出部２９１は、ユーザ端末１００からログイン応答メッセージを受信した場合に、ログイン応答メッセージに含まれるユーザＩＤとパスワードとを認証情報として抽出する。なお、ログイン応答メッセージは、ユーザがログイン未完了の場合にＩＤプロバイダ装置２００から送信されるログイン要求メッセージに応答するために、ユーザ端末１００によって入力される。ログイン応答メッセージは、例えば、ユーザがログイン未完了の場合にユーザ端末１００に表示されるログイン画面を介して入力される。ログイン画面には、具体的には、ユーザＩＤとパスワードを入力する欄が表示される。

認証識別部２９２は、認証情報抽出部２９１によって抽出された認証情報と、図４に示したＩＤＰユーザストア２５０に含まれるユーザＩＤおよび参照情報に基づいてユーザの認証と識別を行う。

具体的に、認証識別部２９２は、認証情報抽出部２９１が抽出したユーザＩＤに基づいてＩＤＰユーザストア２５０を検索し、ユーザＩＤが一致するユーザ属性情報に含まれる参照情報と認証情報抽出部２９１が抽出したパスワードが一致するかを判定する。

ログイン応答メッセージ転送部２９３は、ダミーＵＲＬにログイン応答メッセージを転送する。

図１７乃至図１９を参照して、ユーザがサービスプロバイダ装置３００にサービス利用要求をしたときに、ＳＳＯ処理を実行し、サービスプロバイダ装置３００のサービスを利用可能とする、本実施形態の認証連携システムの認証連携処理について説明する。図１７乃至図１９は、本実施形態の認証連携処理の一例を示すシーケンス図である。

なお、本実施形態の認証連携処理は、図１３に示したステップＳ１〜ステップＳ７の処理に続いて、図１７乃至図１９に示したステップＳ３０〜ステップＳ５０の処理を行う。

ステップＳ１〜ステップＳ７の処理は第１の実施形態と同様であるため省略し、図１７のステップＳ３０から説明する。

ステップＳ３０では、本実施形態のログイン状態判定部２４２がログイン状態は未完了状態であると判定し、判定結果を認証連携要求メッセージ転送部２４４に送信する。

ステップＳ３１では、認証連携要求メッセージ転送部２４４が、認証連携要求メッセージをダミーＵＲＬ宛に転送する。ここでは、ダミーのＵＲＬはダミー（１）ＵＲＬであるとする。

ステップＳ３２では、認証連携要求メッセージを受信したユーザ端末１００が、指定のＵＲＬ、すなわち、ダミー（１）ＵＲＬに認証連携要求メッセージをリダイレクトする。

ステップＳ３３では、Ｗｅｂサーバ２２０が、ユーザ端末１００によってリダイレクトされた認証連携要求メッセージを一旦受信する。Ｗｅｂサーバ２２０のリバースプロキシ装置２２１は、転送先ＵＲＬ記憶装置２２２に保存された転送先ＵＲＬ管理テーブル２２３に基づいたメッセージ転送の要否判定を行う。ここでは、ＩＤ「１−Ｃ」が適合するため、転送先はＩＤ「１−Ｄ」、すなわちＩＤＰ認証連携部２３０の認証連携要求メッセージ受信部２３２となる。続いて、メッセージ転送処理が行われる。

ステップＳ３４では、Ｗｅｂサーバ２２０のリバースプロキシ装置２２１が、ステップＳ３３の判定結果に基づいて、ＩＤＰ認証連携部２３０の認証連携要求メッセージ受信部２３２を宛先として、認証連携要求メッセージを転送する。

ステップＳ３５では、ＩＤＰ認証連携部２３０の認証連携要求メッセージ受信部２３２が、認証連携要求メッセージを受信後、ユーザのログイン状態を確認する。ログイン状態の確認は図１４のステップＳ８と同様の処理であるため、説明は省略する。本実施形態では、ログイン未完了である。

ステップＳ３６では、ステップＳ３５の判定結果に基づいて、ログイン要求メッセージ送信部２３３が、ユーザ端末１００にログイン要求メッセージを送信する。

ステップＳ３７では、ログイン要求メッセージを受信したユーザ端末１００に、ログイン画面が表示され、ユーザが当該ログイン画面を介してユーザＩＤとパスワードとを入力する。

ステップＳ３８では、ユーザ端末１００が、ステップＳ３７で入力された当該ユーザＩＤとパスワードとを含むログイン応答メッセージをＩＤＰ認証連携部２３０のログイン応答メッセージ受信部２３４を宛先として送信する。

続いて図１８のステップＳ３９に進む。

図１８のステップＳ３９ではＷｅｂサーバ２２０が、ステップＳ３８でユーザ端末１００によって送信されたログイン応答メッセージを一旦受信する。また、Ｗｅｂサーバ２２０のリバースプロキシ装置２２１は、転送先ＵＲＬ記憶装置２２２に保存された転送先ＵＲＬ管理テーブル２２３に基づいて、当該ログイン応答メッセージの転送制御の要否判定を行う。なお、判定方法は、転送先ＵＲＬ管理テーブル２２３のインターネット公開ＵＲＬフィールドの中から、受信したログイン応答メッセージの宛先と適合するＵＲＬを検索する。ここでは、ＩＤ「３−Ａ」が適合するため、メッセージ転送要と判定される。なお、転送先ＵＲＬ管理テーブル２２３に一致するＵＲＬが存在しない場合は転送制御不要と判定される。

ここでは、転送先はＩＤ「３−Ｂ」、すなわち認証連携システム２４０のログイン応答メッセージ事前処理部２９０となる。続いて、メッセージ転送処理が行われる。

ステップＳ４０では、Ｗｅｂサーバ２２０のリバースプロキシ装置２２１が、ステップＳ３９の判定結果に基づいて、ログイン応答メッセージ事前処理部２９０を宛先として、ログイン応答メッセージを転送する。

ステップＳ４１では、ログイン応答メッセージ事前処理部２９１の認証情報抽出部２９１が、受信したログイン応答メッセージから、ユーザＩＤとパスワードを認証情報として抽出する。

ステップＳ４２では、ログイン応答メッセージ事前処理部２９１の認証識別部２９２が、ステップＳ４１で抽出されたユーザＩＤを検索キーとして、ＩｄＰユーザストア２５０のユーザ属性情報を検索し、パスワードを取得する。

ステップＳ４３では、ログイン応答メッセージ事前処理部２９１の認証識別部２９２が、取得したパスワードと、ログイン応答メッセージから抽出されたパスワードとを照合し、ユーザの認証を行うとともに、ユーザＩＤによるユーザの識別を行う。本実施形態では、ユーザを認証できたとする。

ステップＳ４４では、ログイン応答メッセージ事前処理部２９１が、ポリシ評価情報取得部２４５に、ポリシ評価情報の取得要求を送信する。このとき、ログイン応答メッセージから取得されたユーザＩＤもともに送信する。

ステップＳ４４の処理に引き続いて、図１４のステップＳ１１のサービスデータ取得処理、図１４のステップＳ１２のユーザ属性情報取得処理、ステップＳ１３〜Ｓ１５のポリシ評価処理、およびステップＳ１６〜Ｓ１８のアカウントプロビジョニング処理は行われる。これらの処理は第１の実施形態で説明済みであるため省略する。

続いて、図１９のステップＳ４５では、ログイン応答メッセージ事前処理部２９１のログイン応答メッセージ転送部２９３が、ＩＤプロバイダ装置２００内には存在しないダミーのＵＲＬを宛先として、ユーザ端末１００に向けてログイン応答メッセージを転送する。なお、本実施形態ではログイン応答メッセージ転送部２９３が転送するダミーのＵＲＬはあらかじめ設定されており、「ダミー（３）ＵＲＬ」であるとする。

ステップＳ４６では、ログイン応答メッセージを受信したユーザ端末１００が、宛先であるダミー（３）ＵＲＬにログイン応答メッセージをリダイレクトする。

ステップＳ４７では、Ｗｅｂサーバ２２０が、ユーザ端末１００によってリダイレクトされたログイン応答メッセージを一旦受信する。ここで、Ｗｅｂサーバ２２０のリバースプロキシ装置２２１が、転送先ＵＲＬ記憶装置２２２に記憶された転送先ＵＲＬ管理テーブル２２３に基づき、メッセージ転送の要否判定を行う。

判定方法は、転送先ＵＲＬ管理テーブル２２３のインターネット公開ＵＲＬフィールドの中の受信したログイン応答メッセージの宛先と一致するＵＲＬを検索し、一致するＵＲＬが存在する場合に「転送要」とする。ここでは、ＩＤ「３−Ｃ」が適合するため、転送先は対応する転送先ＵＲＬのＩＤ「３−Ｄ」である。すなわち、リバースプロキシ装置２２１は、ＩＤＰ認証連携部２３０のログイン応答メッセージ受信部２３４にログイン応答メッセージの転送が必要であると判定する。

ステップＳ４８では、Ｗｅｂサーバ２２０のリバースプロキシ装置２２１が、ステップＳ４７での判定結果に基づいて、ＩＤＰ認証連携部２３０のログイン応答メッセージ受信部２３４を宛先として、ログイン応答メッセージを転送する。

ステップＳ４９では、ＩＤＰ認証連携部２３０のログイン応答メッセージ受信部２３４が、受信したログイン応答メッセージに基づいてログイン処理を行う。ログイン処理は、具体的には、ログイン応答メッセージ受信部２３４が、受信したログイン応答メッセージログインからユーザＩＤとパスワードを取得する。取得したユーザＩＤを検索キーとして、ログイン応答メッセージ受信部２３４がＩＤＰユーザストア２５０からパスワードを取得し、ログイン応答メッセージから抽出したパスワードと照合してユーザの認証を行う。なお、本実施形態では、ユーザの認証が確認できたとする。

ステップＳ５０では、ログイン応答メッセージ受信部２３４が、ＩＤプロバイダ装置２００においてログインが完了したことを示すＩＤＰ認証トークンを発行し、ユーザＩＤとともに認証セッション一時記憶装置２７０に格納する。

ステップＳ５０に続いて、図１５のステップＳ２４〜ステップＳ２７における認証連携応答処理とステップＳ２８におけるＳＰ利用応答処理を行い、本実施形態の認証連携処理は終了する。

上述のように、本実施形態の認証連携システムによると、ＩＤプロバイダ装置２００の組織に所属するユーザがサービスプロバイダ装置３００にアカウントが登録されてない状態であり、ユーザのログイン状態は未完了状態であり、かつユーザからのＳＳＯ要求起点がサービスプロバイダ装置３００から開始する場合において、ＳＳＯの過程でアカウント登録および連携を実行する際の人手を介さないサービス利用可否の決定を行うことが可能となる。

また、本実施形態の認証連携システムによると、ＩＤプロバイダ装置２００の組織に所属するユーザがサービスプロバイダ装置３００にアカウントが登録されてない状態であり、ユーザのログイン状態は未完了状態であり、かつユーザからのＳＳＯ要求起点がサービスプロバイダ装置３００から開始する場合において、適切なタイミングで、ポリシ評価とアカウントプロビジョニングを実施できる。

（第３の実施形態）
第３の実施形態の認証連携システムについて図２０乃至図２４を参照して説明する。

本実施形態は第１の実施形態と同様に、ＩＤプロバイダ装置２００とサービスプロバイダ装置３００との間でＳＳＯ処理が可能な状態であり、かつ当該ＩＤプロバイダ装置２００側の組織に所属するユーザが当該サービスプロバイダ装置３００にアカウントが登録されてない状態から開始される。

また、ユーザのログイン状態と、ユーザからのＳＳＯ要求起点にはさまざまな組み合わせがあるが、本実施形態ではユーザのログイン状態は完了状態であり、かつユーザからのＳＳＯ要求起点がＩＤプロバイダ装置２００から開始される（ＩＤＰ開始モデル）とする。

ＩＤＰ開始モデルは、前述のＳＳＯ手順（１）において、ユーザ端末からＩＤプロバイダに対して、サービスプロバイダのサービス提供を要求するところから始まるモデルである。したがって、本実施形態ではＳＳＯ手順（２）は行われず、手順（１）に続いて（３）〜（６）の処理を行う。

ここで、図２０および図２１を参照して、本実施形態の認証連携システムの機能構成について説明する。なお、第１の実施形態および第２の実施形態と同一の構成には同一の符号を付し、説明は省略する。

図２０は本実施形態のＩＤＰ認証連携部２３０の機能構成の一例を示す図である。

図２０に示すように、本実施形態のＩＤＰ認証連携部２３０は、ログイン要求メッセージ送信部２３３と、ログイン応答メッセージ受信部２３４と、認証連携応答メッセージ送信部２３５と、認証連携応答発行要求メッセージ受信部２３６とを備える。

認証連携応答発行要求メッセージ受信部２３６は、認証連携応答発行要求メッセージを受信する。なお、認証連携応答発行要求メッセージとは、ＩＤＰ開始モデルにおいて発行されるサービスプロバイダ装置３００への認証連携要求メッセージのことである。すなわち、ユーザ端末１００からサービス利用要求を受信したＩＤプロバイダ装置２００がサービスプロバイダ装置３００に認証連携を要求するために発行するメッセージである。

サービスプロバイダ装置３００が発行する認証連携要求メッセージをＳＰ認証連携要求メッセージといい、ＩＤプロバイダ装置２００が発行する認証連携要求メッセージ（認証連携応答発行要求メッセージ）をＩＤＰ認証連携要求メッセージとしてもよい。

図２１は本実施形態の認証連携制御システム２４０の機能構成の一例を示す図である。図２１に示すように、本実施形態の認証連携制御システム２４０は、認証連携応答発行要求メッセージ事前処理部２９４を備える。

認証連携応答発行要求メッセージ事前処理部２９４は、認証連携応答発行要求メッセージ転送部２９５を備え、受信した認証連携応答発行要求メッセージの転送処理を行う。

ここで、図２２乃至図２４を参照して、本実施形態における認証連携システムの認証連携処理について説明する。図２２乃至図２４は、本実施形態における認証連携処理の一例を示すシーケンス図である。

まず、ステップＳ６１では、ユーザが、サービスプロバイダ装置３００のサービスを利用するために、ポータルサーバ２１０によってユーザ端末１００に表示されたポータルメニュー画面を介して、サービスプロバイダ装置３００が提供するサービス公開ＵＲＬのリンクのうち所望のリンクをクリックすることにより、ユーザ端末１００にＳＰ利用要求が入力される。

ステップＳ６２では、ユーザ端末１００がポータルサーバ２１０にＳＰ利用要求メッセージを送信する。

ステップＳ６３では、Ｗｅｂサーバ２２０が、ユーザ端末１００から送信されたＳＰ利用要求メッセージを受信し、受信したＳＰ要求メッセージの転送要否判定処理を行う。

転送要否判定処理は、具体的には、Ｗｅｂサーバ２２０が備えるリバースプロキシ装置２２１が、転送先ＵＲＬ記憶装置２２２に記憶された転送先ＵＲＬ管理テーブル２２３に基づいて行う。例えば、図２の転送先ＵＲＬ管理テーブル２２３のインターネット公開ＵＲＬフィールドの中に、受信したＳＰ利用要求メッセージの宛先と適合するＵＲＬを検索する。ここでは宛先はポータルサーバ２２０であるが、図２のインターネット公開ＵＲＬフィールドの中に適合するものがないため、リバースプロキシ装置２２１は転送処理が不要であると判定する。

ステップＳ６４では、リバースプロキシ装置２２１が、ステップＳ６３での判定結果に基づいて、元々の宛先であるポータルサーバ２２０にＳＰ利用要求メッセージを転送する。

ステップＳ６５では、ＳＰ利用要求メッセージを受信したポータルサーバ２２０が、ＩＤＰ認証連携部２３０の認証連携応答発行要求メッセージ受信部２３６を宛先とした認証連携応答発行要求メッセージを作成し、ユーザ端末１００に送信する。すなわち、ポータルサーバ２２０は認証連携応答発行要求機能を備える。

ステップＳ６６では、認証連携応答発行要求メッセージを受信したユーザ端末１００が、指定された宛先である認証連携応答発行要求メッセージ受信部２９４にリダイレクトする。

ステップＳ６７では、Ｗｅｂサーバ２２０が、リダイレクトされた認証連携応答発行要求メッセージを受信し、受信したメッセージの転送要否判定処理を行う。

転送要否判定処理はステップＳ６３における処理と同様である。ここでは、宛先が、図２に示した転送先ＵＲＬ管理テーブル２２３のインターネット公開ＵＲＬのＩＤ「２−Ａ」と一致するため、リバースプロキシ装置２２１は転送要と判定する。また、転送先ＵＲＬは、ＩＤ「２−Ａ」に対応するＩＤ「２−Ｂ」の転送先ＵＲＬである。すなわち、転送先ＵＲＬは、認証連携制御システム２４０の認証連携応答発行要求メッセージ事前処理部２９４である。

ステップＳ６８では、リバースプロキシ装置２２１が、ステップＳ６７の判定結果に基づいて、認証連携制御システム２４０の認証連携応答発行要求メッセージ事前処理部２９４を宛先として、認証連携応答発行要求メッセージを転送する。

図２３のステップＳ６９では、認証連携応答発行要求メッセージを受信した認証連携応答発行要求メッセージ事前処理部２９４のログイン状態判定部２４２が、ユーザのログイン状態を判定する。ログイン状態の確認は、認証セッション一時記憶装置２７０にユーザに発行されたＩＤＰ認証トークンが記憶されているか否かによって確認する。本実施形態では、認証セッション一時記憶装置２７０にＩＤＰ認証トークンが記憶されており、ログイン完了状態と判定される。

ステップＳ７０では、ユーザＩＤ取得部２４３が、認証セッション一時記憶装置２７０から、ステップＳ６９におけるＩＤＰ認証トークンに対応づけられたユーザＩＤを取得する。

ステップＳ７１では、認証連携応答発行要求メッセージ事前処理部２９４が、ポリシ評価情報取得部２４５にポリシ評価情報の取得を要求する。このとき、ステップＳ７０で取得されたユーザＩＤもポリシ評価情報取得部２４５に引き渡される。

ステップＳ７１に引き続いて、図１４のステップＳ１１のサービスデータ取得処理、図１４のステップＳ１２のユーザ属性情報取得処理、ステップＳ１３〜Ｓ１５のポリシ評価処理、およびステップＳ１６〜Ｓ１８のアカウントプロビジョニング処理が行われる。これらの処理は第１の実施形態で説明済みであるため省略する。

続いて、図２４のステップ７２の処理を行う。ステップＳ７２では、ステップＳ１８のアカウントプロビジョニング終了後に、認証連携応答発行要求メッセージ受信部２９４が、宛先がダミーＵＲＬである認証連携応答発行要求メッセージをユーザ端末１００に送信する。なお、認証連携応答発行要求メッセージ受信部２９４が送信するダミーＵＲＬはあらかじめ設定されており、本実施形態では「ダミー（２）ＵＲＬ」である。

ステップＳ７３では、認証連携応答発行要求メッセージを受信したユーザ端末１００が、認証連携応答発行要求メッセージの宛先であるダミー（２）ＵＲＬに、認証連携応答発行要求メッセージをリダイレクトする。

ステップＳ７４では、リバースプロキシ装置２２１が、転送先ＵＲＬ記憶装置２２３に記憶された転送先ＵＲＬ管理テーブル２２３に基づいて、ユーザ端末１００によってリダイレクトされた認証連携応答発行要求メッセージの転送要否判定処理を行う。

ここでは、転送先ＵＲＬ管理テーブル２２３に含まれるインターネット公開ＵＲＬのＩＤ「２−Ｃ」が適合するため、メッセージ転送制御が必要であると判定する。

転送先は、ＩＤ「２−Ｃ」に対応した転送先ＵＲＬである。すなわち、ＩＤ「２−Ｄ」のＩＤＰ認証連携部２３０の認証連携応答発行要求メッセージ受信部２３６である。

ステップＳ７５では、リバースプロキシ装置２２１が、ステップＳ７４の判定結果に基づいて、ＩＤＰ認証連携部２３０の認証連携応答発行要求メッセージ受信部２３６を宛先として、認証連携応答発行要求メッセージを転送する。

ステップＳ７６では、ＩＤＰ認証連携部２３０の認証連携応答発行要求メッセージ受信部２３６が、認証連携応答発行要求メッセージを受信後、ユーザのログイン状態を判定する。ログイン状態判定結果は、例えば認証セッション一時記憶装置２７０にユーザに発行されたＩＤＰ認証トークンが記憶されているか否かを確認することによって行なう。本実施形態ではログイン完了状態としているためＩＤＰ認証トークンが存在する。

ステップＳ７７では、ＩＤＰ認証連携部２３０の認証連携応答発行要求メッセージ受信部２３６が、ログイン状態の判定結果がログイン完了状態であるため、認証連携応答メッセージ送信部２３５に対し、認証連携応答メッセージの送信を要求する。認証連携応答メッセージ送信部２３５は、ＩＤＰ側でユーザを認証したことを証明する認証アサーションを作成する。

ステップＳ７７の処理に引き続き、図１５のステップＳ２５〜ステップＳ２８の処理が行われ、本実施形態の認証連携処理は終了する。ステップＳ２５〜Ｓ２８の処理については第１の実施形態で説明しているため、省略する。

上述のように、本実施形態の認証連携システムによると、ＩＤプロバイダ装置２００の組織に所属するユーザがサービスプロバイダ装置３００にアカウントが登録されてない状態であり、ユーザのログイン状態は完了状態であり、かつユーザからのＳＳＯ要求起点がＩＤプロバイダ装置２００から開始する場合において、ＳＳＯの過程でアカウント登録および連携を実行する際の人手を介さないサービス利用可否の決定を行うことが可能となる。

また、本実施形態の認証連携システムによると、ＩＤプロバイダ装置２００の認証連携サーバ２３０が、ＳＳＯ手順（２）〜（４）の処理を連続して行う中で、ＳＳＯ手順（３）の直前に、ポリシ評価、およびアカウント登録・アカウント連携を行なうアカウントプロビジョニング処理の割り込みをＩＤプロバイダ装置の認証連携サーバ製品を直接改造することなく実現することが可能となる。このため、導入コストも低く、かつ人手を介さずにサービス利用可否を決定できる認証連携システムの提供が可能となる。

また、本実施形態の認証連携システムによると、ＩＤプロバイダ装置２００の組織に所属するユーザがサービスプロバイダ装置３００にアカウントが登録されてない状態であり、ユーザのログイン状態は完了状態でありかつユーザからのＳＳＯ要求起点がＩＤプロバイダ装置２００から開始する場合において、適切なタイミングで、ポリシ評価とアカウントプロビジョニングを実施できる。

（第４の実施形態）
第４の実施形態の認証連携システムについて図２５乃至図２６を参照して説明する。

本実施形態は第１の実施形態と同様に、ＩＤプロバイダ装置２００とサービスプロバイダ装置３００との間でＳＳＯ処理が可能な状態であり、かつ当該ＩＤプロバイダ側の組織に所属するユーザが当該サービスプロバイダ装置３００にアカウントが登録されてない状態から開始される。また、本実施形態の認証連携システムは第１の実施形態と同様に、ＳＳＯは上述した（１）〜（６）の手順で行なわれるとする。

また、本実施形態ではユーザのログイン状態は未完了状態であり、かつユーザからのＳＳＯ要求起点がＩＤプロバイダ装置２００から開始とする。

ここで、図２５を参照して、本実施形態の認証連携システムの機能構成について説明する。なお、第１の実施形態乃至第３の実施形態と同一の構成には同一の符号を付し、説明は省略する。

図２５は、本実施形態の認証連携制御システム２４０の機能構成の一例を示す図である。図２５に示すように、本実施形態の認証連携制御システム２４０は、ポリシ評価情報取得部２４５と、ポリシ評価部２４６と、アカウントプロビジョニング部２４７と、ログイン応答メッセージ事前処理部２９０と、認証連携応答発行要求メッセージ事前処理部２９４とを備える。すなわち、本実施形態の認証連携制御システム２４０は、第２の実施形態の認証連携制御システム２４０の認証連携要求メッセージ事前処理部２４１を第３の実施形態の認証連携制御システム２４０の認証連携応答発行要求メッセージ事前処理部２９４に置き換えて構成されている。

ここで、図２２、図２４、および図２６を参照して、本実施形態の認証連携システムにおける認証連携処理の一例について説明する。図２６は、本実施形態の認証連携処理の一例を示すシーケンス図である。

まず、本実施形態の認証連携システムは、図２２のステップＳ６１のＳＰ利用要求からステップＳ６８の認証連携応答発行要求メッセージの転送までの処理を行なう。これらの処理は第３の実施形態で説明したため、省略する。

ステップＳ６８に続いて、ステップＳ８１では、携応答発行要求メッセージを受信した認証連携応答発行要求メッセージ事前処理部２９４のログイン状態判定部２４２が、ユーザのログイン状態を判定する。ログイン状態の確認は、認証セッション一時記憶装置２７０に、ユーザに発行されたＩＤＰ認証トークンが記憶されているか否かによって確認する。本実施形態では、認証セッション一時記憶装置２７０にＩＤＰ認証トークンが記憶されておらず、ログイン未完了状態と判定される。

ステップＳ８１でログイン未完了状態と判定されたため、続いて、図２４に示したステップＳ７２〜ステップＳ７５の処理を行う。これらの処理も第３の実施形態で説明したため、省略する。

ステップＳ７５に引き続いて、図１７のステップＳ３５〜図１９のステップＳ２８までの処理を行い、本実施形態の認証連携処理は終了する。図１７のステップＳ３５〜図１９のステップＳ２８までの処理は、第２の実施形態で説明したため省略する。

上述のように、本実施形態の認証連携システムによると、ＩＤプロバイダ装置２００の組織に所属するユーザがサービスプロバイダ装置３００にアカウントが登録されてない状態であり、ユーザのログイン状態は未完了状態であり、かつユーザからのＳＳＯ要求起点がＩＤプロバイダ装置２００から開始する場合において、ＳＳＯの過程でアカウント登録および連携を実行する際の人手を介さないサービス利用可否の決定を行うことが可能となる。

また、本実施形態の認証連携システムによると、ＩＤプロバイダ装置２００の組織に所属するユーザがサービスプロバイダ装置３００にアカウントが登録されてない状態であり、ユーザのログイン状態は未完了状態でありかつユーザからのＳＳＯ要求起点がＩＤプロバイダ装置２００から開始する場合において、適切なタイミングで、ポリシ評価とアカウントプロビジョニングを実施できる。

また、本実施形態の認証連携システムによると、ＩＤプロバイダ装置２００の認証連携サーバ２３０が、ＳＳＯ手順（２）〜（４）の処理を連続して行う中で、ＳＳＯ手順（３）の直前に、ポリシ評価、およびアカウント登録・アカウント連携を行なうアカウントプロビジョニング処理の割り込みをＩＤプロバイダ装置の認証連携サーバ製品を直接改造することなく実現することが可能となる。このため、導入コストも低く、かつ人手を介さずにサービス利用可否を決定できる認証連携システムの提供が可能となる。

以上、本発明のいくつかの実施形態を説明したが、これら実施形態は例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

１００…ユーザ端末、２００…ＩＤプロバイダ、２１０…ポータルサーバ、２２０…Ｗｅｂサーバ、２２１…リバースプロキシ装置、２２２…転送ＵＲＬ記憶装置、２３０…ＩＤＰ認証連携部、２４０…認証連携制御システム、２５０…ＩＤＰユーザストア、２６０…ポリシストア、２７０…認証セッション一時記憶装置、２８０…鍵記憶装置、２９０…ログイン応答メッセージ事前処理部、３００…サービスプロバイダ装置、３１０…ＳＰユーザストア、３２０…サービス利用状況データストア、３３０…一時記憶装置、３４０…検証ポリシストア、３５０…ＳＰ認証連携部

Claims (5)

1. ユーザが操作するユーザ端末のログイン処理を行うＩＤプロバイダ装置と、前記ログイン処理が完了した場合に前記ユーザ端末にサービスデータを送信するサービスプロバイダ装置とを備え、前記ユーザ端末は前記サービスプロバイダ装置にサービス利用要求を行なう認証連携システムであって、
   前記ＩＤプロバイダ装置は、
   前記ユーザを識別するユーザ識別子含む前記ユーザを特定するためのユーザ属性の項目名と前記ユーザ属性の項目値とを関連付けたＩＤＰユーザ属性情報を記憶するＩＤＰユーザ属性情報記憶部と、
   前記ユーザＩＤと前記ユーザのログイン状態がログイン完了状態であることを示す認証トークンとを対応付けて記憶するＩＤＰ認証セッション記憶部と、
   前記サービスデータの送信が許可される対象となるユーザを示すポリシ情報を記憶するポリシ情報記憶部と、
   前記ＩＤプロバイダ装置の署名生成鍵を記憶する鍵記憶部と、
   前記ユーザ端末のログイン処理が未完了状態である場合には、前記ユーザ端末にログイン要求を行い、前記ユーザ端末のログイン処理が完了状態である場合には、前記サービス利用要求を受信した前記サービスプロバイダ装置から発行されるＳＰ認証連携要求を受信し、前記ログイン処理の認証方式名を含むアサーション本文に対して前記署名生成鍵に基づくデジタル署名を生成し、当該アサーション本文と当該デジタル署名とを含む認証アサーションを作成し、前記認証アサーション含む認証連携応答を前記サービスプロバイダ装置に送信するＩＤＰ認証連携部と、
   前記ユーザ端末から前記ＳＰ認証連携要求を受信した場合に、前記認証セッション記憶部に当該ユーザに発行された認証トークンが記憶されているか否かを確認するログイン状態確認処理を行うログイン状態判定部と、前記ログイン状態確認処理の結果がログイン未完了の状態であれば、前記ＳＰ認証連携要求を前記ＩＤＰ認証連部に転送する認証連携要求転送部と、前記ユーザ端末から、前記ＩＤＰ認証連携部からの前記ログイン要求に基づいて送信された前記ユーザの認証情報を受信し、受信した前記認証情報に基づいて前記ログイン処理を行う認証識別部と、前記ログイン状態確認処理の結果がログイン完了状態である場合に、前記認証セッション記憶部に当該ユーザに発行された認証トークンに対応付けて記憶されたユーザＩＤに基づいて前記ＩＤＰユーザ属性情報記憶部から取得したＩＤＰユーザ属性情報と前記ポリシ情報とに基づいて前記ユーザ端末を操作するユーザがサービスデータの送信が許可される対象となるユーザであるか否かを評価し、前記ログイン状態確認処理の結果がログイン未完了の状態である場合に、前記認証情報に含まれるユーザＩＤに基づいて前記ＩＤＰユーザ属性情報記憶部から取得したＩＤＰユーザ属性情報と前記ポリシ情報とに基づいて前記ユーザ端末を操作するユーザがサービスデータの送信が許可されるユーザであるか否かを評価するポリシ評価部と、前記ポリシ評価部による評価結果が許可である場合に、前記取得されたＩＤＰユーザ属性情報を参照して前記サービスプロバイダ装置とのアカウント連携処理を行い、前記サービスプロバイダ装置における前記ユーザの識別子であるＳＰ側ユーザＩＤを作成するアカウント連携部と、前記アカウント連携処理後に前記ＳＰ認証連携要求を前記ＩＤＰ認証連携部に送信する認証連携要求転送部とを具備する認証連携制御部と、
   を備え、
   前記サービスプロバイダ装置は、
   前記認証連携応答を受信した場合に前記サービスデータの送信を許可するログイン処理の認証方式名と、前記署名生成鍵に対応する署名検証鍵とを含む検証ポリシを記憶する検証ポリシ記憶部と、
   前記アカウント連携処理において発行される前記ＳＰ側ユーザＩＤと、前記ユーザ属性情報に含まれるユーザ属性の項目名および項目値のうちの少なくとも一つの項目名と項目値とであるユーザ属性部分情報とを関連付けたアカウント登録を記憶するＳＰユーザ属性情報記憶部と、
   前記サービス利用要求を受信した場合、当該サービス利用要求が認証トークンを含むか否かを判定し、前記サービス利用要求が前記認証トークンを含む場合には当該認証トークンと前記サービスデータとを前記ユーザ端末に送信し、前記サービス利用要求が前記認証トークンを含まない場合には、前記ユーザ端末のアドレス情報を含む前記ＩＤプロバイダ装置に対する前記ＳＰ認証連携要求を発行し、
   前記認証連携応答を受信した場合、前記検証ポリシ内の認証方式名と署名検証鍵とに基づいて、前記認証方式名とデジタル署名とをそれぞれ検証し、前記検証した結果がいずれも正当のとき、認証トークンを発行し、前記認証トークンと前記サービスデータとを前記ユーザ端末に送信するＳＰ認証連携部と、
   前記ＳＰ側ユーザＩＤと、前記認証トークンとを関連付けて記憶するＳＰ認証セッション記憶部と、
   を備える認証連携システム。
2. ユーザが操作するユーザ端末のログイン処理を行うＩＤプロバイダ装置と、前記ログイン処理が完了した場合に前記ユーザ端末にサービスデータを送信するサービスプロバイダ装置とを備え、前記ユーザ端末は前記ＩＤプロバイダ装置にサービス利用要求を行なう認証連携システムであって、
   前記ＩＤプロバイダ装置は、
   前記ユーザを識別するユーザ識別子含む前記ユーザを特定するためのユーザ属性の項目名と前記ユーザ属性の項目値とを関連付けたＩＤＰユーザ属性情報を記憶するＩＤＰユーザ属性情報記憶部と、
   前記ユーザＩＤと前記ユーザのログイン状態がログイン完了状態であることを示す認証トークンとを対応付けて記憶するＩＤＰ認証セッション記憶部と、
   前記サービスデータの送信が許可される対象となるユーザを示すポリシ情報を記憶するポリシ情報記憶部と、
   前記ＩＤプロバイダ装置の署名生成鍵を記憶する鍵記憶部と、
   前記ユーザ端末からサービス利用要求を受信した場合に、前記サービスプロバイダ装置に対するＩＤＰ認証連携要求を発行するＩＤＰ認証連携要求部と、
   前記ユーザ端末のログイン処理が未完了状態である場合には、前記ユーザ端末にログイン要求を行い、前記ユーザ端末のログイン処理が完了状態である場合には、前記ＩＤＰ認証連携要求を受信し、前記ログイン処理の認証方式名を含むアサーション本文に対して前記署名生成鍵に基づくデジタル署名を生成し、当該アサーション本文と当該デジタル署名とを含む認証アサーションを作成し、前記認証アサーション含む認証連携応答を前記サービスプロバイダ装置に送信するＩＤＰ認証連携部と、
   前記ＩＤＰ認証連携要求を受信した場合に、前記認証セッション記憶部に当該ユーザに発行された認証トークンが記憶されているか否かを確認するログイン状態確認処理を行うログイン状態判定部と、前記ログイン状態確認処理の結果がログイン未完了の状態であれば、前記ＩＤＰ認証連携要求を前記ＩＤＰ認証連部に転送する認証連携要求転送部と、前記ユーザ端末から、前記ＩＤＰ認証連携部からの前記ログイン要求に基づいて送信された前記ユーザの認証情報を受信し、受信した前記認証情報に基づいて前記ログイン処理を行う認証識別部と、前記ログイン状態確認処理の結果がログイン完了状態である場合に、前記認証セッション記憶部に当該ユーザに発行された認証トークンに対応付けて記憶されたユーザＩＤに基づいて前記ＩＤＰユーザ属性情報記憶部から取得したＩＤＰユーザ属性情報と前記ポリシ情報とに基づいて前記ユーザ端末を操作するユーザがサービスデータの送信が許可される対象となるユーザであるか否かを評価し、前記ログイン状態確認処理の結果がログイン未完了の状態である場合に、前記認証情報に含まれるユーザＩＤに基づいて前記ＩＤＰユーザ属性情報記憶部から取得したＩＤＰユーザ属性情報と前記ポリシ情報とに基づいて前記ユーザ端末を操作するユーザがサービスデータの送信が許可されるユーザであるか否かを評価するポリシ評価部と、前記ポリシ評価部による評価結果が許可である場合に、前記取得されたＩＤＰユーザ属性情報を参照して前記サービスプロバイダ装置とのアカウント連携処理を行い、前記サービスプロバイダ装置における前記ユーザの識別子であるＳＰ側ユーザＩＤを作成するアカウント連携部と、前記アカウント連携処理後に前記ＩＤＰ認証連携要求を前記ＩＤＰ認証連携部に送信する認証連携要求転送部とを具備する認証連携制御部と、
   を備え、
   前記サービスプロバイダ装置は、
   前記認証連携応答を受信した場合に前記サービスデータの送信を許可するログイン処理の認証方式名と、前記署名生成鍵に対応する署名検証鍵とを含む検証ポリシを記憶する検証ポリシ記憶部と、
   前記アカウント連携処理において発行される前記ＳＰ側ユーザＩＤと、前記ユーザ属性情報に含まれるユーザ属性の項目名および項目値のうちの少なくとも一つの項目名と項目値とであるユーザ属性部分情報とを関連付けたアカウント登録を記憶するＳＰユーザ属性情報記憶部と、
   前記ＩＤＰ認証連携部から前記認証連携応答を受信した場合、前記検証ポリシ内の認証方式名と署名検証鍵とに基づいて、前記認証方式名とデジタル署名とをそれぞれ検証し、前記検証した結果がいずれも正当のとき、認証トークンを発行し、前記認証トークンと前記サービスデータとを前記ユーザ端末に送信するＳＰ認証連携部と、
   前記ＳＰ側ユーザＩＤと、前記認証トークンとを関連付けて記憶するＳＰ認証セッション記憶部と、
   を備える認証連携システム。
3. ユーザが操作するユーザ端末にサービスデータを送信するサービスプロバイダ装置と接続され認証連携システムを構成する、前記サービスプロバイダ装置にサービス利用要求を行なう前記ユーザ端末のログイン処理を行うＩＤプロバイダ装置であって、
   前記ユーザを識別するユーザ識別子含む前記ユーザを特定するためのユーザ属性の項目名と前記ユーザ属性の項目値とを関連付けたＩＤＰユーザ属性情報を記憶するＩＤＰユーザ属性情報記憶部と、
   前記ユーザＩＤと前記ユーザのログイン状態がログイン完了状態であることを示す認証トークンとを対応付けて記憶するＩＤＰ認証セッション記憶部と、
   前記サービスデータの送信が許可される対象となるユーザを示すポリシ情報を記憶するポリシ情報記憶部と、
   前記ＩＤプロバイダ装置の署名生成鍵を記憶する鍵記憶部と、
   前記ユーザ端末のログイン処理が未完了状態である場合には、前記ユーザ端末にログイン要求を行い、前記ユーザ端末のログイン処理が完了状態である場合には、前記サービス利用要求を受信した前記サービスプロバイダ装置から発行されるＳＰ認証連携要求を受信し、前記ログイン処理の認証方式名を含むアサーション本文に対して前記署名生成鍵に基づくデジタル署名を生成し、当該アサーション本文と当該デジタル署名とを含む認証アサーションを作成し、前記認証アサーション含む認証連携応答を前記サービスプロバイダ装置に送信するＩＤＰ認証連携部と、
   前記ユーザ端末から前記ＳＰ認証連携要求を受信した場合に、前記認証セッション記憶部に当該ユーザに発行された認証トークンが記憶されているか否かを確認するログイン状態確認処理を行うログイン状態判定部と、前記ログイン状態確認処理の結果がログイン未完了の状態であれば、前記ＳＰ認証連携要求を前記ＩＤＰ認証連部に転送する認証連携要求転送部と、前記ユーザ端末から、前記ＩＤＰ認証連携部からの前記ログイン要求に基づいて送信された前記ユーザの認証情報を受信し、受信した前記認証情報に基づいて前記ログイン処理を行う認証識別部と、前記ログイン状態確認処理の結果がログイン完了状態である場合に、前記認証セッション記憶部に当該ユーザに発行された認証トークンに対応付けて記憶されたユーザＩＤに基づいて前記ＩＤＰユーザ属性情報記憶部から取得したＩＤＰユーザ属性情報と前記ポリシ情報とに基づいて前記ユーザ端末を操作するユーザがサービスデータの送信が許可されるユーザであるか否かを評価し、前記ログイン状態確認処理の結果がログイン未完了の状態である場合に、前記認証情報に含まれるユーザＩＤに基づいて前記ＩＤＰユーザ属性情報記憶部から取得したＩＤＰユーザ属性情報と前記ポリシ情報とに基づいて前記ユーザ端末を操作するユーザがサービスデータの送信が許可される対象となるユーザであるか否かを評価するポリシ評価部と、前記ポリシ評価部による評価結果が許可である場合に、前記取得されたＩＤＰユーザ属性情報を参照して前記サービスプロバイダ装置とのアカウント連携処理を行い、前記サービスプロバイダ装置における前記ユーザの識別子であるＳＰ側ユーザＩＤを作成するアカウント連携部と、前記アカウント連携処理後に前記ＳＰ認証連携要求を前記ＩＤＰ認証連携部に送信する認証連携要求転送部とを具備する認証連携制御部と、
   前記サービスプロバイダ装置から送信された前記認証連携要求を前記認証連携制御部に転送する転送装置と、
   を備えるＩＤプロバイダ装置。
4. ユーザが操作するユーザ端末にサービスデータを送信するサービスプロバイダ装置と接続され認証連携システムを構成し、ユーザ端末のログイン処理を行うＩＤプロバイダ装置であって、
   前記ユーザを識別するユーザ識別子含む前記ユーザを特定するためのユーザ属性の項目名と前記ユーザ属性の項目値とを関連付けたＩＤＰユーザ属性情報を記憶するＩＤＰユーザ属性情報記憶部と、
   前記ユーザＩＤと前記ユーザのログイン状態がログイン完了状態であることを示す認証トークンとを対応付けて記憶するＩＤＰ認証セッション記憶部と、
   前記サービスデータの送信が許可される対象となるユーザを示すポリシ情報を記憶するポリシ情報記憶部と、
   前記ＩＤプロバイダ装置の署名生成鍵を記憶する鍵記憶部と、
   前記ユーザ端末からサービス利用要求を受信した場合に、前記サービスプロバイダ装置に対するＩＤＰ認証連携要求を発行するＩＤＰ認証連携要求部と、
   前記ユーザ端末のログイン処理が未完了状態である場合には、前記ユーザ端末にログイン要求を行い、前記ユーザ端末のログイン処理が完了状態である場合には、前記ＩＤＰ認証連携要求を受信し、前記ログイン処理の認証方式名を含むアサーション本文に対して前記署名生成鍵に基づくデジタル署名を生成し、当該アサーション本文と当該デジタル署名とを含む認証アサーションを作成し、前記認証アサーション含む認証連携応答を前記サービスプロバイダ装置に送信するＩＤＰ認証連携部と、
   前記ＩＤＰ認証連携要求を受信した場合に、前記認証セッション記憶部に当該ユーザに発行された認証トークンが記憶されているか否かを確認するログイン状態確認処理を行うログイン状態判定部と、前記ログイン状態確認処理の結果がログイン未完了の状態であれば、前記ＩＤＰ認証連携要求を前記ＩＤＰ認証連部に転送する認証連携要求転送部と、前記ユーザ端末から、前記ＩＤＰ認証連携部からの前記ログイン要求に基づいて送信された前記ユーザの含む認証情報を受信し、受信した前記認証情報に基づいて前記ログイン処理を行う認証識別部と、前記ログイン状態確認処理の結果がログイン完了状態である場合に、前記認証セッション記憶部に当該ユーザに発行された認証トークンに対応付けて記憶されたユーザＩＤに基づいて前記ＩＤＰユーザ属性情報記憶部から取得したＩＤＰユーザ属性情報と前記ポリシ情報とに基づいて前記ユーザ端末を操作するユーザがサービスデータの送信が許可される対象となるユーザであるか否かを評価し、前記ログイン状態確認処理の結果がログイン未完了の状態である場合に、前記認証情報に含まれるユーザＩＤに基づいて前記ＩＤＰユーザ属性情報記憶部から取得したＩＤＰユーザ属性情報と前記ポリシ情報とに基づいて前記ユーザ端末を操作するユーザがサービスデータの送信が許可されるユーザであるか否かを評価するポリシ評価部と、前記ポリシ評価部による評価結果が許可である場合に、前記取得されたＩＤＰユーザ属性情報を参照して前記サービスプロバイダ装置とのアカウント連携処理を行い、前記サービスプロバイダ装置における前記ユーザの識別子であるＳＰ側ユーザＩＤを作成するアカウント連携部と、前記アカウント連携処理後に前記ＩＤＰ認証連携要求を前記ＩＤＰ認証連携部に送信する認証連携要求転送部とを具備する認証連携制御部と、
   を備えるＩＤプロバイダ装置。
5. 前記ユーザＩＤと、前記各サービスプロバイダ装置のサービス利用状況とを関連付けたサービス利用状況情報を記憶するサービス利用状況記憶部を備え、
   前記認証連携要求事前処理部は、前記サービス利用状況記憶部に記憶された前記サービス利用状況情報と前記ポリシ情報記憶部に記憶された前記ポリシ情報とを参照して前記ユーザ端末を操作するユーザがサービスデータの送信が許可されるユーザであるか否かを評価する請求項３に記載のＩＤプロバイダ装置。

Images