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

Abstract

【課題】
ＳＳＯの過程でアカウント登録および連携を実行する際に、人手を介さず、かつユーザに負荷をかけずにサービス利用可否を決定することができるようになる。
【解決手段】
実施形態のＩＤプロバイダ装置のポリシ記憶部は、サービスプロバイダＩＤ毎に、サービスデータの送信が許可されるユーザを示すポリシ情報と、サービスデータの送信許可が削除される対象となるユーザを示すポリシ情報を記憶する。ＩＤプロバイダ装置は、所定の周期が到来した場合、もしくはサービスプロバイダ装置の利用状況が変化した場合に、サービスプロバイダ装置から送信される当該サービスプロバイダ装置の利用状況情報を取得し、取得した利用状況情報に基づいてサービス利用状況記憶部を更新する。ＩＤプロバイダ装置は、サービス利用状況記憶部が更新された場合、サービスプロバイダＩＤ毎の削除対象アカウントの決定を行なう。
【選択図】図１

Description

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

社会、経済、生活のオンラインサービスへの依存度が増す情勢を背景に、近年、個人や組織に関する情報を管理するアイデンティティ管理の重要性が高まっている。アイデンティティ管理とは、様々なサービスやシステムにおいて、個人や組織に関する情報の安全性と利便性を図り、登録から変更、削除までのアイデンティティのライフサイクル全体を管理する技術である。

ここで、アイデンティティとは、ある状況で個人やグループ、組織・企業を特定する情報の総体であり、識別子やクレデンシャル、属性が含まれる。識別子とは、アイデンティティを識別するための情報であり、アカウント（ユーザＩＤ）や社員番号などに相当する。クレデンシャルとは、ある情報内容の正当性を示すための情報であり、パスワードなどがある。属性とは、アイデンティティを特徴付ける情報であり、氏名や住所、生年月日などを指す。

アイデンティティ管理技術を利用した技術の代表例として、シングルサインオン（Ｓｉｎｇｌｅ Ｓｉｇｎ−Ｏｎ 以降ＳＳＯという）がある。ＳＳＯは、一度の認証手続きだけで、複数のアプリケーションやサービスを利用できる技術である。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

このように、ＳＡＭＬに基づくＳＳＯでは、ユーザが一度の認証手続きをＩＤプロバイダに行うだけで更なる認証手続きを実行せずに、複数のサービスを使用可能となる。現在、多くのベンダが、ＳＡＭＬのＩＤＰおよびＳＰの機能を実装したアクセス管理製品や、ＳＡＭＬのＳＰ機能を実装したＳａａＳサービスの提供を行っている。

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

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

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

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

以上で説明したデータ処理システムは、個々のユーザのアカウント登録に必要なユーザ属性の要求および提供という軽量な処理で実現でき、多数のユーザに対する大量の事前処理を必要としないことから、通常、問題ない。

しかしながら、本発明者の検討によれば、以下に述べるように、改良の余地がある。

通常、企業において、サービスプロバイダが提供するサービスを利用する場合、企業内での情報システムを統括するＩＳ（Ｉｎｆｏｒｍａｔｉｏｎ Ｓｙｓｔｅｍ）部門がサービスプロバイダに対して、アカウント登録および連携を行う。

ＩＳ部門は、企業に所属する多数のユーザに応じた大量の事前処理を一括して行うか、又はユーザによる任意のタイミングで一連の承認フローを通した手続きを経た後に当該ユーザに対するアカウント登録および連携を行う。

ここで、前者の事前処理を行う場合は、ＳＳＯの過程でアカウント登録および連携を実行する必要がないので、前述したデータ処理システムとは無関係である。

一方、後者の承認フローを通す場合は、ユーザだけでなく、ユーザが所属する組織階層ごとの上長や調達部門、ＩＳ部門など多くの人手を介すことになり、大量の手間暇を要する。更に、ＩＳ部門が事前処理を一括して行わないことから、人手による作業が発生し、負担が大きい上、効率や利便性も悪い。例えば、ＳａａＳ等における素早く使えるメリットを生かすことができない。

従って、ＳＳＯの過程でアカウント登録および連携を実行するシステムでは、人手を介さずにサービス利用可否を決定するシームレスな仕組みを備えていることが望ましい。

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

本発明が解決しようとする課題は、ＳＳＯの過程でアカウント登録および連携を実行する際に、ユーザの負荷が少なく、かつ人手を介さずにサービス利用可否を決定することができる認証連携システム、ＩＤプロバイダ装置およびプログラムを提供することである。

実施形態のＩＤプロバイダ装置のポリシ記憶部は、サービスプロバイダＩＤ毎に、サービスデータの送信が許可されるユーザを示すポリシ情報と、サービスデータの送信許可が削除される対象となるユーザを示すポリシ情報を記憶する。ＩＤプロバイダ装置は、所定の周期が到来した場合、もしくはサービスプロバイダ装置の利用状況が変化した場合に、サービスプロバイダ装置から送信される当該サービスプロバイダ装置の利用状況を取得し、取得した利用状況に基づいてサービス利用状況記憶部を更新する。ＩＤプロバイダ装置は、サービス利用状況記憶部が更新された場合、サービスプロバイダＩＤ毎の削除対象アカウントの決定を行なう。

実施形態に係る認証連携システムのハードウェア構成の一例を示すブロック図。 実施形態に係るＩＤＰユーザリポジトリを説明するための模式図。 実施形態に係るＩＤＰサービス利用状況ストアを説明するための模式図。 実施形態に係る認証連携ポリシストアを説明するための模式図。 実施形態に係るＳＰユーザ設定ルールストアを説明するための模式図。 実施形態に係る削除対象決定ポリシストアを説明するための模式図。 実施形態に係る削除対象アカウントストアを説明するための模式図。 実施形態に係る認証アサーションを説明するための模式図。 実施形態に係るＳＰユーザリポジトリを説明するための模式図。 実施形態に係るサービスデータストアを説明するための模式図。 実施形態に係るＳＰサービス利用状況ストアを説明するための模式図。 実施形態に係る検証ポリシストアを説明するための模式図。 実施形態に係る全体動作の概要を示す模式図。 実施形態に係る利用状況取得の処理フローを示すシーケンス図。 実施形態に係る利用状況取得の処理に必要な構成要素の一例を示すブロック図。 実施形態に係るユーザ認証の処理フローを示すシーケンス図。 実施形態に係るユーザ認証の処理に必要な構成要素の一例を示すブロック図。 実施形態に係る認証連携ポリシ評価の処理フローを示すシーケンス図である。 実施形態に係る認証連携ポリシ評価の処理に必要な構成要素の一例を示すブロック図。 実施形態に係るアカウント連携の処理フローを示すシーケンス図。 実施形態に係るアカウント連携の処理に必要な構成要素の一例を示すブロック図。 実施形態に係る認証連携の処理フローを示すシーケンス図。 実施形態に係る認証連携の処理に必要な構成要素の一例を示すブロック図。

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

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

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

ＩＤプロバイダ装置２００は、ユーザのアイデンティティを管理するものであり、ＩＤＰユーザリポジトリ２０１、ＩＤＰサービス利用状況ストア２０２、認証連携ポリシストア２０３、ＳＰユーザ設定ルールストア２０４、鍵記憶部２０５、削除対象決定ポリシストア２０６、削除対象アカウントストア２０７、ＩＤＰ認証連携部２０８、認証連携ハンドリング部２０９、認証連携ポリシ評価部２１０、ＩＤＰアカウントプロビジョニング部２１１、サービス利用状況管理部２１２、およびトリガ２１３を備える。

ＩＤＰユーザリポジトリ２０１は、ＩＤプロバイダ装置２００が配置される組織のユーザに関するアイデンティティ情報（以下、「ユーザ属性情報」という）を記憶する。具体的には、ＩＤＰユーザリポジトリ（ユーザ属性情報記憶部）２０１は、図２に示すように、ユーザを特定するためのユーザ属性の項目名とユーザ属性の項目値とを関連付けたユーザ属性情報２０１ａであって、ユーザを識別するユーザＩＤと、ユーザのログイン処理時に参照するパスワードと、ユーザの氏名と、ユーザの所属と、ユーザの役職と、ユーザ端末のアドレス情報と、認証連携ＩＤなどを項目名に含む複数のユーザ属性情報２０１ａを記憶する。認証連携ＩＤは、サービスプロバイダ装置３００と自装置２００との間で共有するＩＤであり、本実施形態では後述するアカウント連携処理において発行される。なお、サービスプロバイダとの認証連携が行われていない場合、認証連携ＩＤは空である。

ユーザ属性情報２０１ａは個人の情報を特徴付ける情報の集合体である。ユーザ属性情報２０１ａは上述したに限らず、例えば電話番号や勤務状態といった任意の項目名と項目値とを更に含んでもよい。また、ユーザのログイン処理時に、参照するパスワードは、例えばユーザの指紋等の生体認証情報であってもよい。

ＩＤＰサービス利用状況ストア（第１のサービス利用状況記憶部）２０２は、認証連携ポリシ評価部２１０から参照され、ユーザごとのサービス利用状況情報２０２ａを記憶する。なお、サービス利用状況情報２０２ａは、ユーザＩＤ毎の、各サービスプロバイダ装置３００が提供するサービスの利用状況である。

すなわち、ＩＤＰサービス利用状況ストア２０２は、ＩＤプロバイダ装置２００側においてユーザごとのサービス利用状況を記憶する。図３に示すように、ＩＤＰサービス利用状況ストア２０２は、サービス利用状況情報２０２ａとしてユーザ利用管理テーブル２０２ａＡと、利用数管理テーブル２０２ａＢとを記憶している。 ユーザ利用管理テーブル２０２ａＡは、「ユーザＩＤ」と、各サービスプロバイダ装置３００を識別する「サービスプロバイダＩＤ」（ＳＰ（１）〜ＳＰ（Ｎ））と、サービスプロバイダＩＤごとの「サービス利用状況」とを関連付けて記憶する。

サービス利用状況は、例えば、サービスデータの送信が許可された場合を示す「サービス利用中」、サービスデータの送信が許可されていない場合を示す「サービス未利用」、ユーザ端末１００から受けた一時停止要求に基づくサービスデータの送信の許可の一時停止を示す「サービス利用停止」、およびユーザ端末１００から受けた利用終了要求に基づく「サービス利用終了」である。なお、サービス利用終了は、現在の利用数が上限値を超えた場合に、ＩＤプロバイダ装置２００が遊休ユーザの利用を無効化した場合を含む。また、サービス利用状況は、ユーザがサービスを利用した最終の日時（最終のログイン日時）である最終利用日時およびディスク利用量も関連付けて記憶される。

例えば、図３のユーザＩＤが「ＵＳＥＲ＿Ａ」のサービス利用状況は、ＳＰ（１）はサービス未利用の状態、ＳＰ（２）はサービス利用中、ＳＰ（Ｎ）はサービス未利用の状態である。さらに、ＳＰ（２）では、最終利用日時が２０１１／０２／１０で、ディスク利用量が４Ｇバイトである。

利用数管理テーブル２０２ａＢは、図３に示すように、ユーザ利用管理テーブル２０２ａＡ内のサービス利用状況が示すサービス利用中の個数を示す利用数と、あらかじめ設定された利用数の上限値とをサービスプロバイダＩＤごとに関連付けて書き込まれる。

認証連携ポリシストア（認証連携ポリシ記憶部）２０３は、認証連携ポリシ評価部２１０から参照され、認証連携ポリシを記憶する。具体的には、認証連携ポリシストア２０３は、図４に示すように、サービスプロバイダＩＤ毎に、当該サービスプロバイダＩＤで識別されるサービスプロバイダ装置３００によるサービスデータの送信が許可されるユーザの所属および役職を示す複数の認証連携ポリシ（認証連携ポリシ情報）２０３ａ（２０３ａＡ，２０３ａＢ，２０３ａＣ，…）を記憶する。

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

ここでポリシとは、一般的に誰（サブジェクト）が、どのシステム資源（リソース）に対して、どのような操作（アクション）を行うことができるか否か（つまり、許可または拒否）が定義されたアクセス可否条件の集合体を指す。またオプションで、環境条件や責務条件についても定義されるものである。

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

ＳＰユーザ設定ルールストア（一部項目名記憶部）２０４は、図５に示すように、ユーザ設定ルール２０４ａを記憶する。ユーザ設定ルール２０４ａは、サービスプロバイダＩＤと、ＩＤＰユーザリポジトリ２０１に記憶されたユーザ属性情報２０１ａ内のユーザ属性の項目名のうち、一部の項目名とを関連付けて書き込まれている
鍵記憶部２０５は、自装置２００の署名生成鍵を記憶する。署名生成鍵としては、例えば、公開鍵暗号方式における公開鍵と秘密鍵との鍵ペアのうちの秘密鍵が使用可能となっている。

削除対象決定ポリシストア（削除対象ポリシ記憶部）２０６は、図６に示すように、サービス利用状況管理部２１２から参照され、削除対象決定ポリシを記憶する。具体的には、削除対象決定ポリシストア（削除対象決定ポリシ記憶部）２０６は、図６に示すように、サービスプロバイダＩＤ毎に、当該サービスプロバイダＩＤで識別されるサービスプロバイダ装置３００において、サービスデータの送信許可を削除されるユーザの条件（削除対象条件）を示す削除対象決定ポリシ（削除対象決定ポリシ情報）２０６ａ（２０６ａＡ、２０６ａＢ、２０６ａＣ…）を記憶する。

例えば、削除対象決定ポリシ２０６ａは、サービスプロバイダＳＰ（１）に登録されたユーザの最終利用日時が半年以上前であること、ディスク利用量が５ＧＢ異常であること、ユーザの所属する部がＸであることを削除対象条件として記述する。サービスプロバイダＳＰ（２）とサービスプロバイダＳＰ（３）の削除対象決定ポリシも同様に記述する。サービスデータの送信許可の削除は、例えば後述するＳＰユーザリポジトリから削除対象アカウントを削除してもよいし、サービスデータ送信許可上体を一時停止状態に変更してもよい。

削除対象アカウントストア（削除対象アカウント記憶部）２０７は、図７に示すように、後述するサービス利用状況管理部２１２が、削除対象決定ポリシ２０６ａと、サービス利用状況２０２ａと、ユーザ属性情報２０１ａとに基づいて決定した削除対象アカウント（削除対象アカウント情報）２０７ａを記憶する。削除対象アカウント情報２０７ａは各サービスプロバイダ装置２００における削除対象のユーザＩＤである。

ＩＤＰ認証連携部２０８は、シングルサインオンのＩＤプロバイダ機能を有する。ＩＤＰ認証連携部２０８は、具体的には例えば、以下の機能（ｆ２０８−１）〜（ｆ２０８−３）をもっている。

（ｆ２０８−１） 後述する認証連携ハンドリング部２０９から送出されたユーザ認証要求内のユーザ端末１００のアドレス情報に基づいて、当該ユーザ端末１００にログイン要求を送信し、当該ユーザ端末１００から受けたユーザＩＤおよびユーザ認証情報をＩＤＰユーザリポジトリ２０１内のユーザＩＤおよびパスワードに基づいて認証するログイン処理を実行する機能。

（ｆ２０８−２） 後述するＩＤＰアカウントプロビジョニング部２１１が発行した認証連携ＩＤと、ログイン処理の認証方式名とを含むアサーション本文に対して鍵記憶部２０５内の署名生成鍵に基づくデジタル署名を生成し、図８に示すように、当該アサーション本文と当該デジタル署名とを含む認証アサーション２０８ａを作成する機能。

（ｆ２０８−３） 作成した認証アサーション２０８ａを含む認証連携応答を認証連携要求の送信元のサービスプロバイダ装置３００に送信する機能。

認証連携ハンドリング部２０９は、サービスプロバイダ装置３００からの認証連携要求を受信した後、後述するポリシ評価処理とアカウント連携処理とＩＤＰ認証連携処理で構成される一連の処理をハンドリングする。認証連携ハンドリング部２０９は、具体的には、以下の機能（ｆ２０９−１）〜（ｆ２０９−４）をもっている。

（ｆ２０９−１） サービスプロバイダ装置３００から送信されて当該サービスプロバイダ装置３００のサービスプロバイダＩＤとユーザ端末１００のアドレス情報とを含む認証連携要求を受けると、当該認証連携要求内のユーザ端末１００のアドレス情報を含むユーザ認証要求をＩＤＰ認証連携部２０８に送出する機能。

（ｆ２０９−２） ＩＤＰ認証連携部２０８によるログイン処理が成功したとき、当該ログイン処理に用いたユーザＩＤと認証連携要求内のサービスプロバイダＩＤとを含むポリシ評価要求を認証連携ポリシ評価部２１０に送出する機能。

（ｆ２０９−３） 認証連携ポリシ評価部２１０から受けたポリシ評価応答内の判定結果が許可を示す場合、ポリシ評価要求内のユーザＩＤとサービスプロバイダＩＤとを含むアカウント連携要求をＩＤＰアカウントプロビジョニング部２１１に送出する機能。

（ｆ２０９−４） ＩＤＰアカウントプロビジョニング部２１１から送出されたアカウント連携応答内の操作完了に含まれるサービスプロバイダＩＤおよびユーザＩＤを含むＩＤＰ認証連携実行要求をＩＤＰ認証連携部２０８に送出する機能。

認証連携ポリシ評価部２１０は、認証連携ハンドリング部２０９からのポリシ評価要求を受けて、事前に定義された認証連携ポリシ２０３ａとユーザ利用管理テーブル２０２ａＡとに基づいてポリシ評価を行う。認証連携ポリシ評価部２１０は、具体的には、以下の機能（ｆ２１０−１）〜（ｆ２１０−５）をもっている。

（ｆ２１０−１） 認証連携ハンドリング部２０９から送出されたポリシ評価要求内のユーザＩＤに基づいてＩＤＰユーザリポジトリ２０１からユーザ属性情報２０１ａを読み出す機能。

（ｆ２１０−２） 認証連携ハンドリング部２０９から送出されたポリシ評価要求内のサービスプロバイダＩＤに基づいて認証連携ポリシストア２０３から認証連携ポリシ情報２０３ａを読み出す機能。

（ｆ２１０−３） 認証連携ハンドリング部２０９から送出されたポリシ評価要求内のユーザＩＤに基づいてＩＤＰサービス利用状況ストア２０２からサービス利用状況情報２０２ａを読み出す機能。

（ｆ２１０−４） 読み出した認証連携ポリシ２０３ａに示される所属および役職に対し、当該読み出したユーザ属性情報２０１ａ内の所属や役職、および当該読み出したサービス利用状況情報２０２ａが適合するか否かに応じて、サービスデータの送信を許可するか否かを判定する送信許可判定機能。

（ｆ２１０−５） この判定結果を含むポリシ評価応答をポリシ評価要求の送信元の認証連携ハンドリング部２０９に送出する機能。

ＩＤＰアカウントプロビジョニング部２１１は、認証連携ハンドリング部２０９からのアカウント連携要求を受けて、サービスプロバイダ装置３００に対してアカウントプロビジョニングを実行する。ＩＤＰアカウントプロビジョニング部２１１は、具体的には例えば、以下の機能（ｆ２１２−１）〜（ｆ２１２−８）をもっている。

（ｆ２１１−１） 送出されたアカウント連携要求内のサービスプロバイダＩＤに基づいて、ＳＰユーザ設定ルールストア２０４からユーザ属性の一部の項目名を読み出す機能。

（ｆ２１１−２） 送出されたアカウント連携要求内のサービスプロバイダＩＤに基づいて、削除対象アカウントストア２０７から削除対象アカウント情報２０７ａを読み出す機能。

（ｆ２１１−３） 当該読み出した一部の項目名とアカウント連携要求メッセージ内のユーザＩＤとに基づいて、ＩＤＰユーザリポジトリ２０１内で当該ユーザＩＤに一致するユーザＩＤを含むユーザ属性情報２０１ａのうち、当該一部の項目名に一致する項目名およびこの項目名に関連付けられた項目値からなるユーザ属性部分情報を取得する機能。

（ｆ２１１−４） 当該アカウント連携要求内のサービスプロバイダＩＤで識別されるサービスプロバイダ装置３００と自装置２００との間で共有する認証連携ＩＤを発行する機能。

（ｆ２１１−５） 取得したユーザ属性部分情報に操作指示として「アカウント登録」を付加し、取得した削除対象アカウント情報２０７ａに操作指示として「アカウント削除」を付加すると共に、発行された認証連携ＩＤを付加し、アカウントプロビジョニング要求（アカウント連携要求メッセージ）を作成する機能。

（ｆ２１１−６） アカウント連携要求メッセージを認証連携要求の送信元のサービスプロバイダ装置３００に送信する機能。

（ｆ２１１−７） アカウント連携要求メッセージの送信先のサービスプロバイダ装置３００から当該サービスプロバイダ装置のサービスプロバイダＩＤとユーザ属性部分情報内のユーザＩＤとを含むＳＰユーザリポジトリ３０２の操作完了が通知されると、当該操作完了に含まれるサービスプロバイダＩＤおよびユーザＩＤに基づいて、ＩＤＰユーザリポジトリ２０１内のユーザ属性情報２０１ａに認証連携ＩＤを登録する機能。

（ｆ２１１−８）当該登録完了とユーザリポジトリの操作完了を示すアカウント連携応答を認証連携ハンドリング部２０９に送出する機能。

サービス利用状況管理部２１２は、サービス利用状況取得部２１４と削除対象アカウント決定部２１５とを備える。

サービス利用状況取得部２１４は、サービスプロバイダ装置３００に利用状況取得要求を送信する。また、サービス利用状況取得部２１４は、当該利用状況取得要求に基づいてサービスプロバイダ装置３００から送信される当該サービスプロバイダ装置３００の利用状況を取得し、取得した利用状況に基づいてＳＰＩＤＰサービス利用状況ストア２０２を更新する。

削除対象アカウント決定部２１５は、取得した利用状況と、ユーザ属性情報２０１ａと、削除対象決定ポリシ２０６ａＡとに基づいて削除対象アカウントの決定を行なう。

トリガ２１３は、あらかじめ定められた時刻が到来した場合に、サービス利用状況管理部２１１のサービス利用状況取得部２１２にサービスプロバイダ装置３００の利用状況取得を行なうよう要求する。すなわち、トリガ２１３は、サービス利用状況取得部２１２に利用状況取得実行要求を送信する。

サービス利用状況取得部２１４は、この利用状況取得実行要求を受信すると、サービスプロバイダ装置３００からサービス利用状況を取得する。トリガ２１３は、例えば、周期によって設定してもよい。すなわち、トリガ２１３は、ＩＤプロバイダ装置２００とサービスプロバイダ装置３００との認証セッションの張り直しのアクションのように一定時間ごとに動作するアクションとしてもよい。

一方、サービスプロバイダ装置３００は、ユーザが利用するサービスを提供するものであり、サービスデータ通信部３０１、ＳＰユーザリポジトリ３０２、サービスデータストア３０３、ＳＰサービス利用状況ストア３０４、検証ポリシストア３０５、ＳＰ認証連携部３０６、サービス利用状況提供部３０７、およびＳＰアカウントプロビジョニング部３０８を備えている。

サービスデータ通信部３０１は、後述するＳＰ認証連携部３０６から送出されたサービス実行要求に基づいて、当該サービス実行要求内の認証トークンと後述するサービスデータストア３０３内のサービスデータ３０３ａとをユーザ端末１００に送信する機能をもっている。

ＳＰユーザリポジトリ３０２は、サービスデータ通信部３０１が送信するサービスデータを利用するユーザのアイデンティティ情報を記憶する。具体的には、ＳＰユーザリポジトリ（ユーザ属性部分情報記憶部）３０２は、図９に示すように、ＩＤＰユーザリポジトリ２０１内のユーザ属性情報２０１ａ内のユーザ属性の項目名および項目値のうち、ＳＰユーザ設定ルール２０４ａに基づく一部の項目名と項目値とを関連付けたユーザ属性部分情報３０２ａと、自装置３００内でユーザを識別するＳＰ側ユーザＩＤとを関連付けて記憶している。

サービスデータストア３０３は、図１０に示すように、サービスデータ３０３ａを記憶している。サービスデータ３０３ａは、サービスプロバイダ装置３００によるサービス提供（サービスデータ送信）の対象として、ユーザ端末１００に送信される任意のデータである。

ＳＰサービス利用状況ストア（第２のサービス利用状況記憶部）３０４は、ユーザごとの当該サービスプロバイダ装置３００が提供するサービスの利用状況であるサービス利用状況情報３０４ａを記憶する。

すなわち、ＳＰサービス利用状況ストア３０４は、サービスプロバイダ装置３００側においてユーザごとのサービス利用状況を記憶するユーザ利用管理テーブル２０２ａＡと、利用数管理テーブル２０２ａＢとを記憶している。

図１１に示すように、ＳＰサービス利用状況ストア３０４は、ユーザ利用管理テーブル３０４ａＡと、利用数管理テーブル３０４ａＢとを記憶している。ユーザ利用管理テーブル３０４ａＡは、サービスデータ３０３ａの送信が許可された場合を示す「サービス利用中」、サービスデータ３０３ａの送信が許可されていない場合を示す「サービス未利用」、ユーザ端末１００から受けた一時停止要求に基づくサービスデータの送信の許可の一時停止を示す「サービス利用停止」、もしくはユーザ端末１００から受けた利用終了要求に基づく「サービス利用終了」のいずれか示す、当該サービスプロバイダ装置３００の利用状況と、ユーザＩＤとを関連付けて書き込まれる。

また、サービスプロバイダ装置３００の利用状況は、ユーザの最終利用日時およびディスク利用量も関連付けて記憶される。なお、ユーザ利用管理テーブル３０４ａＡは、ＩＤプロバイダ装置２００が複数ある場合は、ユーザＩＤとＩＤプロバイダ装置のＩＤごとの利用状況が書き込まれる。

利用数管理テーブル２０２ａＢは、図１１に示すように、ユーザ利用管理テーブル３０４ａＡ内の利用状況が示すサービス利用中の個数を示す利用数と、あらかじめ設定された利用数の上限値とを関連付けて書き込まれる。

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

ＳＰ認証連携部３０６は、シングルサインオンのサービスプロバイダ機能を有する。ＳＰ認証連携部３０６は、具体的には例えば、以下の機能（ｆ３０６−１）〜（ｆ３０６−４）をもっている。

（ｆ３０６−１） ユーザ端末１００からサービス要求を受けると、当該サービス要求が認証トークンを含むか否かを判定し、認証トークンを含む場合には当該認証トークンとサービスデータストア３０３内のサービスデータ３０３ａとを当該ユーザ端末１００に送信し、否の場合には自装置３００のサービスプロバイダＩＤと当該ユーザ端末１００のアドレス情報とを含む認証連携要求をＩＤプロバイダ装置２００に送信する機能。

（ｆ３０６−２） ＩＤプロバイダ装置２００から認証連携応答を受けると、検証ポリシストア３０５内の認証アサーション検証ポリシ内の認証方式名と署名検証鍵とに基づいて、当該認証アサーション２０８ａ内の認証方式名とデジタル署名とをそれぞれ検証する検証機能。

（ｆ３０６−３） 検証した結果がいずれも正当のとき、認証トークンを発行する機能。

（ｆ３０６−４） 発行された認証トークンと、ＩＤプロバイダ装置２００から受けた認証連携応答に含まれるユーザのアドレス情報とを含むサービス実行要求をサービスデータ通信部３０１に送出する機能。

サービス利用状況提供部３０７は、ＩＤプロバイダ装置２００のサービス利用状況取得部２１４から利用状況取得要求を受けると、この利用状況送信要求に含まれるユーザＩＤに基づいてＳＰサービス利用状況ストア３０４を検索し、当該検索により得られたサービスプロバイダ装置３００の利用状況を送信する機能をもっている。

ＳＰアカウントプロビジョニング部３０８は、ＩＤプロバイダ装置２００のＩＤＰアカウントプロビジョニング部２１１から受けたアカウント連携要求メッセージに基づき、ＳＰユーザリポジトリ３０２に対してアカウントプロビジョニングを行う。また、ＳＰアカウントプロビジョニング部３０８は、当該アカウント連携要求メッセージに基づき、ＳＰサービス利用状況ストア３０４を更新する。

ＳＰアカウントプロビジョニング部３０８は、具体的には例えば、以下の機能（ｆ３０８−１）〜（ｆ３０８−５）をもっている。

（ｆ３０８−１） ＩＤプロバイダ装置２００のＩＤＰアカウントプロビジョニング部２１１からアカウント連携要求メッセージを受信すると、アカウント連携要求メッセージに含まれる操作情報を確認し、操作情報が「アカウント登録」である場合に新規のＳＰ側ユーザＩＤを発行し、当該発行したＳＰ側ユーザＩＤと、当該アカウント連携要求メッセージ内のユーザ属性部分情報３０２ａとを関連付けてＳＰユーザリポジトリ３０２に登録する機能。

（ｆ３０８−２） アカウント連携要求メッセージに含まれる操作情報が「削除」である場合に、当該アカウント連携要求メッセージに含まれるユーザＩＤ（削除対象アカウント）に基づいてＳＰユーザリポジトリ３０２を検索し、検索結果のユーザ属性部分情報３０２ａを削除する機能。

（ｆ３０８−３） アカウント連携要求メッセージに含まれる操作情報が「更新」である場合に、当該アカウント連携要求メッセージに含まれるユーザＩＤに基づいてＳＰユーザリポジトリ３０２を検索し、検索結果のユーザ属性部分情報３０２ａを更新する機能。なお、操作情報「更新」は例えばアカウントの無効であり、このとき、ＳＰアカウントプロビジョニング部３０８は、当該アカウント連携要求メッセージに含まれるユーザＩＤに基づいてＳＰユーザリポジトリ３０２を検索し、検索結果のユーザ属性部分情報３０２ａに含まれる有効フラグ（図示しない）を「ｆａｌｓｅ」に変更する。

なお、アカウントの無効を操作情報「削除」に含めても良い。

（ｆ３０８−４） ユーザリポジトリの操作の後、アカウント連携要求メッセージに含まれるユーザＩＤと、操作情報とに基づいてＳＰサービス利用状況ストア３０４を更新する機能。

例えば、操作情報が「アカウント登録」の場合、ユーザ利用管理テーブル３０４ａＡに新規の利用状況として当該ユーザＩＤと、利用状況「サービス利用中」とを書き込む。このときユーザ利用管理テーブル３０４ａＡに当該ユーザＩＤが存在する場合は、利用状況の更新を行なう。

また、操作情報が「削除」の場合、ユーザ利用管理テーブル３０４ａＡに書き込まれた当該ユーザＩＤの利用状況を「サービス未利用」に変更する。

（ｆ３０８−５） ＳＰユーザリポジトリ３０２の操作およびＳＰサービス利用状況ストア３０４の更新（ＳＰアカウント操作）後、操作したユーザ属性部分情報３０２ａ内のユーザＩＤと自装置３００のサービスプロバイダＩＤとを含む操作完了と、ストア更新完了とをアカウント連携要求メッセージの送信元のＩＤプロバイダ装置２００に通知する機能。

次に、以上のように構成された認証連携システムの動作について図１３乃至図２３を参照して説明する。以下の説明は、ＩＤプロバイダ装置２００とサービスプロバイダ装置３００間でＳＳＯが可能なシステム環境にあり、且つＩＤプロバイダ側の組織に所属するユーザが当該サービスプロバイダ装置３００にアカウントが登録されてない、かつ認証未連携である状態から開始される。

この状態において、ユーザがサービス要求をした時に、ＩＤプロバイダ装置２００が認証連携ポリシ２０３ａを満たすか否かを判定し、満たす場合にサービスプロバイダ装置３００側へのユーザのアカウント登録を行うことにより、ＩＤプロバイダ装置２００とサービスプロバイダ装置３００間のＳＳＯが実行され、サービスプロバイダ装置３００からサービスデータ３０３ａが送信される典型的な処理を例に挙げて述べる。

以降、図１３に示す如き、ステップＳ１０のサービス利用状況取得（Ｓ１１〜Ｓ１９）、ステップＳ２０のユーザ認証（Ｓ２１〜Ｓ２７）、ステップＳ３０の認証連携ポリシ評価（Ｓ３１〜Ｓ３６）、ステップＳ４０のアカウント連携（Ｓ４１〜Ｓ４９）およびステップＳ５０の認証連携（Ｓ５１〜Ｓ５８）に分けて説明する。
まず、図１４のシーケンス図および図１５の模式図を参照して、図１３のステップＳ１０のサービス利用状況取得について説明する。

ステップＳ１１では、ＩＤプロバイダ装置２００のトリガ２１３が、あらかじめ設定された時刻が到来すると、サービス利用状況管理部２１２に対して、利用状況取得の実行を要求する。本実施形態では、トリガ２１３を２０１１年４月１日の１２時に設定する。

ステップＳ１２では、サービス利用状況管理部２１２のサービス利用状況取得部２１４は、トリガ２１３から利用状況取得実行要求を受信すると、サービスプロバイダ装置３００のサービス利用状況提供部３０７に、利用状況の取得を要求する。本実施形態では、ＳＰ（１）というサービスプロバイダＩＤのサービスプロバイダ装置３００のみに利用状況の取得要求を送るとする。

ステップＳ１３では、サービス利用状況提供部３０７は、各サービスプロバイダ装置３００のＳＰサービス利用状況ストア３０４からサービス利用状況情報３０４ａを取得し、ＩＤプロバイダ装置２００のサービス利用状況管理部２１２に送信する。

ステップＳ１４では、サービス利用状況管理部２１２のサービス利用状況取得部２１４は、受信したサービスプロバイダ装置３００ごとのサービス利用状況情報３０４ａに基づいてＩＤＰサービス利用状況ストア２０２を更新する。

ステップＳ１５では、サービス利用状況取得部２１４は、受信したサービス利用状況情報３０４ａに基づいてＳＰＩＤＰサービス利用状況ストア２０２を更新すると、削除対象アカウント決定部２１５に削除対象決定要求を送信する。

ステップＳ１６では、削除対象アカウント決定部２１５は、削除対象決定要求を受信すると、削除対象決定ポリシストア２０６から削除対象決定ポリシ２０６ａを取得する。

ステップＳ１７では、削除対象アカウント決定部２１５は、ＩＤＰユーザリポジトリ２０１からユーザ属性情報２０１ａを取得する。

ステップＳ１８では、削除対象アカウント決定部２１５は、ステップＳ１４で更新されたユーザ利用管理テーブル２０２ａＡと利用数管理テーブル２０２ａＢと、ステップＳ１６で取得した削除対象決定ポリシ２０６ａと、ステップＳ１７で取得したユーザ属性情報２０１ａとに基づいて、削除対象のアカウントを決定する。具体的には、削除対象アカウント決定部２１５は、所定のユーザに関するユーザ属性情報２０１ａとユーザ利用管理テーブル２０２ａＡと利用数管理テーブル２０２ａＢに記憶された当該ユーザのサービス利用状況とに基づいて、削除対象決定ポリシ２０６ａの示す削除条件を満たすユーザを判定する。

例えば、削除対象アカウント決定部２１５が、図６の削除対象決定ポリシ２０６ａＡと、図３のユーザ利用管理テーブル２０２ａＡと、利用数管理テーブル２０２ａＢとに基づいて削除対象決定ポリシ２０６ａの示す削除条件を満たすユーザを判定する場合について具体的に説明する。まず、削除対象決定ポリシ２０６ａＡのＳＰ（１）における削除条件［１］「最終利用日時が半年以上前であること」を満たすのは、ＵＳＥＲ＿ＢおよびＵＳＥＲ＿Ｎである。

続いて、削除対象決定ポリシ２０６ａＡのＳＰ（１）における削除条件［２］「ディスク利用量が、５ＧＢ以上であること」を満たすのは、ＵＳＥＲ＿ＢおよびＵＳＥＲ＿Ｎである。続いて、削除対象決定ポリシ２０６ａＡのＳＰ（１）における削除条件［３］「ユーザの所属する部がＸであること」を満たすのは、ＵＳＥＲ＿Ｂである。したがって、ＵＳＥＲ＿Ｂが削除対象決定ポリシ２０６ａの示す削除条件を全て満たすため、削除対象アカウントと決定される。なお、削除対象アカウントが複数存在する場合は、それら全てを削除対象アカウントと決定する。

ステップＳ１９では、削除対象アカウント決定部２１５は、決定した削除対象アカウントを削除対象アカウントストア２０７に記憶する。

ここで、図１６のシーケンス図および図１７の模式図を参照して、図１３のステップＳ２０のユーザ認証について説明する。ステップＳ２０のユーザ認証は、ユーザがサービスプロバイダ装置３００側のサービスを利用するためにユーザ端末を操作すると開始される。

ステップＳ２１では、ユーザが、サービスプロバイダ装置３００側のサービスを利用するために、ユーザ端末１００を操作すると、ユーザ端末１００はサービス要求をサービスプロバイダ装置３００に送信する。サービスプロバイダ装置３００は、アクセス管理を担うＳＰ認証連携部３０６がサービス要求をキャッチする。

ステップＳ２２では、ＳＰ認証連携部３０６は、ユーザからのサービス要求を受けると、そのサービス要求が認証トークンを含むか否かを判定する。例えば、ユーザからのサービス要求がＨＴＴＰリクエストの形態の場合、そのＨＴＴＰリクエストに含まれるＣｏｏｋｉｅの中に、サービスプロバイダ装置３００が発行した認証トークンが存在することを確認する。

なお、認証トークンの存在が確認できた場合、すなわち認証連携済みの場合、サービスプロバイダ装置３００は、サービス要求により要求されたサービスをユーザに対して提供する。すなわち、ＳＰ認証連携部３０６は、サービス要求が認証トークンを含む旨を判定すると、サービスデータ通信部３０１により、当該認証トークンとサービスデータストア３０３内のサービスデータ３０３ａとをサービス要求元のユーザ端末１００に送信する。具体的には、ＳＰ認証連携部３０６は、サービス要求内の認証トークンと、当該認証トークンに関連付けられたユーザＩＤとを含むサービス実行要求をサービスデータ通信部３０１に送出する。

一方、ステップＳ２２での判定の結果、サービス要求が認証トークンを含まない場合には、すなわち認証未連携の場合には、ステップＳ２３が実行される。

ステップＳ２３では、サービスプロバイダ装置３００は、ＩＤプロバイダ装置２００に認証連携要求を依頼する。このとき、認証連携要求は、サービスプロバイダ装置３００から直接ＩＤプロバイダ装置２００に向けて送信してもよいし、ユーザ端末１００を一旦経由して、リダイレクトする形で送信されてもよい。また、認証連携要求は、自装置３００のサービスプロバイダＩＤとユーザ端末１００のアドレス情報とを含んでいる。

ここでは、サービスプロバイダ装置３００が１つのＩＤプロバイダであるＩＤプロバイダ装置２００としか連携しないため、ＩＤプロバイダの選択が不要である。サービスプロバイダ装置３００が１つのＩＤプロバイダであるＩＤプロバイダ装置２００と連携しており、ＩＤプロバイダの選択が必要な場合には、ＳＰ認証連携部３０６は、ユーザが所属するＩＤプロバイダを当該ユーザに選択させるため、事前に信頼関係を確立したＩＤプロバイダを示すＩＤプロバイダＩＤを列挙したＩＤＰリスト（図示しない）をユーザ端末１００に送信してもよい。このとき、ユーザ端末１００は、サービスプロバイダ装置３００から受信したＩＤＰリストを表示し、ユーザに対して、自身が所属するＩＤプロバイダの選択を促す。しかる後、ユーザ端末１００は、ユーザの操作により、選択されたＩＤプロバイダＩＤをサービスプロバイダ装置３００に送信する。

ステップＳ２４では、ＩＤプロバイダ装置２００の認証連携ハンドリング部２０９が、ＩＤプロバイダ装置２００宛のメッセージを解析し、そのメッセージが認証連携要求であることを確認した場合、認証連携の処理を開始し、認証連携要求内のユーザ端末１００のアドレス情報を含むユーザ認証要求をＩＤＰ認証連携部２０８に送信する。なお、認証連携要求以外のメッセージであることを確認した場合は、認証連携ハンドリング部２０９が仲介する形で、サービスプロバイダ装置３００が所望する宛先へ再送信する。

ステップＳ２５では、ＩＤＰ認証連携部２０８は、ユーザ認証要求を受けると、このユーザ認証要求に基づいて、ユーザの識別と認証のためのログイン処理を実行する。このログイン処理においては、ＩＤＰ認証連携部２０８は、送出されたユーザ認証要求内のユーザ端末１００のアドレス情報に基づいて、当該ユーザ端末１００にログイン要求を送信し、当該ユーザ端末１００から受けたユーザＩＤおよびユーザ認証情報をＩＤＰユーザリポジトリ２０１内のユーザＩＤおよびパスワードに基づいて認証する。本実施形態では、当該ユーザ端末１００からから受けたユーザＩＤ「ＵＳＥＲ＿Ａ」、パスワード「ＰＡＳＳ＿Ａ」、に基づいて認証を行い、ユーザ認証は成功したとする。

ステップＳ２６では、ＩＤＰ認証連携部２０８は、ログインに成功したユーザのアカウント情報が、削除対象アカウントストア２０７に存在するかどうかを判定し、ログインに成功したアカウントの情報が存在する場合、当該アカウントを削除対象アカウントストア２０７から削除する。本実施形態では、削除対象アカウントストア２０７に、「ＵＳＥＲ＿Ａ」が登録されていないため、削除対象アカウントストア２０７は更新されない。

ステップＳ２７では、ＩＤＰ認証連携部２０８は、ステップＳ２５のログイン処理が成功したとき、ログイン処理に用いたユーザＩＤと認証成功の旨とを含むユーザ認証完了（ログイン完了）のメッセージを認証連携ハンドリング部２０９に通知する。

以上により、ステップＳ２０のユーザ認証（Ｓ２１〜Ｓ２７）が終了する。

続いて、ステップＳ３０の認証連携ポリシ評価においては、ユーザ認証終了後、ユーザ利用管理テーブル２０２ａＡ、利用数管理テーブル２０２ａＢ、ユーザ属性情報２０１ａ、認証連携ポリシ２０３ａを入力値として、認証連携ポリシ評価を行い、ユーザのサービス要求に対して許可を下す。以下、図１８のシーケンス図および図１９の模式図を参照してステップＳ３０の認証連携ポリシ評価について説明する。

ステップＳ３１では、認証連携ハンドリング部２０９は、ステップＳ２７にて送信されたユーザ認証完了のメッセージを解析し、ログイン処理が成功したことを確認する。ログイン処理が成功したとき、認証連携ハンドリング部２０９は、ユーザのサービス要求に対するポリシ評価要求を認証連携ポリシ評価部２１０に送出する。ポリシ評価要求は、ステップＳ２５のログイン処理過程で取得したユーザＩＤ、すなわちユーザのＩＤＰアカウントと、認証連携要求内のサービスプロバイダＩＤとを含んでいる。

以降、ステップＳ３２〜Ｓ３４を通じて、認証連携ポリシ評価部２０８は、認証連携ポリシ２０３ａの評価に必要な情報を収集する。

ステップＳ３２では、認証連携ポリシ評価部２１０は、ポリシ評価要求内のユーザＩＤとサービスプロバイダＩＤに基づいてＩＤＰサービス利用状況ストア２０２からサービス利用状況２０２ａを読み出す。但し、ステップＳ３２は、静的なポリシ評価を実行する場合には省略される。

以降、ステップＳ３２で読み出されるユーザＩＤはＵＳＥＲ＿Ａ、ユーザが要求するサービスプロバイダ装置３００はＳＰ（１）とする。

ステップＳ３３では、認証連携ポリシ評価部２１０は、ポリシ評価要求内のユーザＩＤに基づいてＩＤＰユーザリポジトリ２０１からユーザ属性情報２０１ａを読み出す。

ステップＳ３４では、認証連携ポリシ評価部２１０は、ポリシ評価要求内のサービスプロバイダＩＤに基づいて認証連携ポリシストア２０３から認証連携ポリシ２０３ａを読み出す。本実施形態では、図４の各認証連携ポリシ２０３ａのうち、図中Ａに関連付けられた第１の認証連携ポリシ（ＳＰ（１）利用時のポリシ）２０３ａＡが検索結果として読み出される。

ステップＳ３５では、認証連携ポリシ評価部２１０は、静的なポリシ評価を実行する場合、ステップＳ３４で読み出した認証連携ポリシ２０３ａＡに示される所属および役職に対し、ステップＳ３３で読み出したユーザ属性情報２０１ａ内の所属および役職が適合するか否かに応じて、サービスデータ３０３ａの送信を許可するか否かを判定するポリシ評価処理を行う。

但し、ステップＳ３２のユーザ利用管理テーブル２０２ａＡも用いる動的なポリシ評価を実行する場合には、ステップＳ３２，Ｓ３３，Ｓ３４を通じて取得したサービス利用状況２０２ａ、ユーザ属性情報２０１ａおよび認証連携ポリシ２０３ａＡに基づいて、ポリシ評価を実行する。

例えば、認証連携ポリシ２０３ａＡに示すＳＰ（１）の利用に関する、ステップＳ３５におけるポリシ評価を説明する。認証連携ポリシ２０３ａＡには、事前に［１］〜［４］のサービス利用条件が定義されており（静的なポリシ評価の場合には［４］は未定義）、収集したユーザ利用管理テーブル２０２ａＡ、ユーザ属性情報２０１ａが、これらのサービス利用条件を全て満たすことを以下のように確認する。その結果として、ユーザのサービス要求に対して、許可を下す。

認証連携ポリシ２０３ａＡの［１］：認証連携ポリシ２０３ａは、ユーザの所属する部がＸであることを示す。これに対し、図２に示すように、ユーザ属性情報２０１ａにおけるＵＳＥＲ＿Ａの所属部が「Ｘ部門」である。従って、ＵＳＥＲ＿Ａは認証連携ポリシ２０３ａにおける［１］の条件を満たす。

認証連携ポリシ２０３ａＡの［２］：認証連携ポリシ２０３ａは、ユーザの所属する課がＹであることを示す。これに対し、図２に示すように、ユーザ属性情報２０１ａにおけるＵＳＥＲ＿Ａの所属課が「Ｙ課」である。従って、ＵＳＥＲ＿Ａは認証連携ポリシ２０３ａにおける［２］の条件を満たす。

認証連携ポリシ２０３ａＡの［３］：認証連携ポリシ２０３ａは、ユーザの役職がＺ以上の役職であることを示す。これに対し、図２に示すように、ユーザ属性情報２０１ａにおけるＵＳＥＲ＿Ａの役職が「Ｚ職」である。従って、認証連携ポリシ２０３ａにおける［３］の条件を満たす。

認証連携ポリシ２０３ａＡの［４］：認証連携ポリシ２０３ａは、利用中のアカウント数が上限値を超えないことを示す。これに対し、図３に示すように、利用数管理テーブル２０２ａＢにおけるＳＰ（１）の現在の利用数が１０であり、上限値１００を超えていない。従って、認証連携ポリシ２０３ａにおける［４］の条件を満たす。

以上のように、事前に定義した認証連携ポリシ２０３ａに基づき、ユーザ利用管理テーブル２０２ａＡ，利用数管理テーブル２０２ａＢとユーザ属性情報２０１ａを使って、ユーザのサービス要求に対する認証連携ポリシ評価を行う。なお、上記の条件において、一つでも条件を満たさないことが確認できたら、認証連携ポリシ評価の結果は拒否となる。

すなわち、認証連携ポリシ評価部２１０は、読み出した認証連携ポリシ２０３ａに対して、読み出したユーザ属性情報２０１ａ、ユーザが利用したいサービスの種類、ユーザが行いたいサービスへの操作、サービスを実行するに際してのユーザの環境条件に適合するか否かに応じて、サービスデータの送信を許可するか否かを判定する。

ステップＳ３６では、認証連携ポリシ評価部２１０は、ステップＳ３５の判定結果からなるポリシ評価結果をポリシ評価応答として、認証連携ハンドリング部２０９に送出する。以上により、ステップＳ３０の認証連携ポリシ評価（Ｓ３１〜Ｓ３６）が終了する。

ステップＳ４０のアカウント連携では、ステップＳ３０の認証連携ポリシ評価により得られたポリシ評価応答（サービスデータ送信の許可を示す場合）に基づき、サービスプロバイダ装置３００のＳＰユーザリポジトリ３０２に対してユーザのアカウントを作成することで、ＳＳＯの事前準備として必要なＩＤプロバイダ装置２００とサービスプロバイダ装置３００間でのアカウント連携を実現する。以下、図２０のシーケンス図および図２１の模式図を用いて述べる。

ステップＳ４１では、認証連携ハンドリング部２０９は、ステップＳ３６で送出されたポリシ評価応答に含まれるポリシ評価結果を確認し、ポリシ評価応答がサービス要求を許可する場合は、ポリシ評価要求内のユーザＩＤとサービスプロバイダＩＤとを含むアカウント連携要求をＩＤＰアカウントプロビジョニング部２１１に依頼する。なお、ポリシ評価応答がサービス利用の拒否を示す場合、サービス利用拒否の旨をユーザ端末１００に通知する。ここでは、ポリシ評価応答が許可の場合を例に挙げ、以降のステップＳ４２〜４９を説明する。

ステップＳ４２では、ＩＤＰアカウントプロビジョニング部２１１は、受信したアカウント連携要求内のサービスプロバイダＩＤ（ここでは、ＳＰ（１））に基づいて、ＳＰユーザ設定ルールストア２０４からユーザ設定ルール２０４ａを読み出す。ユーザ設定ルール２０４ａは、例えば、ＩＤプロバイダ装置２００がサービスプロバイダ装置３００に対してアカウント登録を行う際、サービスプロバイダ装置３００ごとに求められる必要なユーザ属性の項目名（ユーザ属性の一部の項目名）などである。ここでは、ＩＤＰアカウントプロビジョニング部２１１は、ユーザ設定ルール２０４ａとして、ユーザ属性の一部の項目名を読み出したものとする。

ステップＳ４３では、ＩＤＰアカウントプロビジョニング部２１１は、削除対象アカウントストア２０７からＳＰ（１）に関する削除対象のアカウントを検索する。

なお、ステップＳ４３の検索は、ステップＳ３２で認証連携ポリシ評価部２１０がＩＤＰサービス利用状況ストア２０２から取得したサービス利用状況情報において、受信したアカウント連携内のサービスプロバイダＩＤ（ここでは、ＳＰ（１））の利用者数が上限に達しているかを判定し、ＳＰ（１）の利用者数が上限に達している場合に行なうようにしてもよい。このとき、ステップＳ３２において、静的なポリシ評価が実行され、サービス利用状況取得が省略された場合は、ステップＳ４３の前にＩＤＰプロビジョニング部２１０がＩＤＰサービス利用状況ストア２０２からサービス利用状況を取得する。

本実施形態では、図７に示すように、削除対象アカウントストア２０７にはＳＰ（１）に関する削除対象のアカウントとしてＵＳＥＲ＿Ｂが登録されているため、ここではＵＳＥＲ＿Ｂが検索結果である。なお、複数の削除対象アカウントが存在する場合は、１つのユーザＩＤのみを削除してもよいし、全て削除してもよい。

ステップＳ４４では、ＩＤＰアカウントプロビジョニング部２１１は、ステップＳ４２で読み出した一部の項目名とアカウント連携要求内のユーザＩＤとに基づいて、ＩＤＰユーザリポジトリ２０１内で当該ユーザＩＤに一致するユーザＩＤを含むユーザ属性情報２０１ａのうち、当該一部の項目名に一致する項目名およびこの項目名に関連付けられた項目値からなる必要なユーザ属性情報（以下、ユーザ属性部分情報という）を取得する。

ステップＳ４５では、ＩＤＰアカウントプロビジョニング部２１１は、ステップＳ４４で取得したユーザ属性部分情報に、操作指示として「アカウント登録」を付加し、ステップＳ４３で取得した削除対象アカウントに操作指示として「削除」指示を付加してＳＰアカウント連携要求メッセージを作成し、作成したアカウント連携要求メッセージをサービスプロバイダ装置３００のＳＰアカウントプロビジョニング部３０９に送信する。また、ＩＤＰアカウントプロビジョニング部２１１は、認証連携ＩＤを発行しアカウント連携要求メッセージに含める。

アカウント連携要求メッセージに含まれる操作指示は、例えば、ＳＰアカウントプロビジョニング部３０８が公開する操作インタフェースに基づくＳＰユーザリポジトリ３０２の操作の種類であり、削除、アカウント登録、アカウント更新などがある。本実施形態では、サービスプロバイダ装置３００側にユーザのアカウントが登録されてないため、ステップＳ４５では、操作指示として「アカウント登録」を指定する。

また、ＩＤＰアカウントプロビジョニング部２１１は、ＳＰアカウント連携要求メッセージを送信する先のサービスプロバイダ装置３００と自装置２００との間で共有する認証連携ＩＤを発行し、この認証連携ＩＤをＳＰアカウント連携要求メッセージに含める。

ステップＳ４６では、ＳＰアカウントプロビジョニング部３０８は、受信したアカウント連携要求メッセージに基づき、ＳＰユーザリポジトリ３０２の操作を行なう。具体的には、ＳＰアカウントプロビジョニング部３０８は、受信したアカウント連携要求メッセージに含まれる操作指示が「アカウント登録」である場合、ＳＰ側ユーザＩＤ（サービスプロバイダ装置３００側のユーザＩＤ）を新規発行し、当該ＳＰ側ユーザＩＤと、ＳＰアカウント連携要求メッセージ内のユーザ属性部分情報とを関連付けてＳＰユーザリポジトリ３０２に登録する。このとき、ＳＰアカウントプロビジョニング部３０８は、アカウント連携要求メッセージ内の認証連携ＩＤも登録する。

また、ステップＳ４６においてＳＰアカウントプロビジョニング部３０８は、操作指示が「削除」である場合、当該アカウント連携要求メッセージ内の削除対象アカウントに基づいて、ＳＰユーザリポジトリ３０２内のユーザ属性部分情報３０２ａ検索し、削除対象アカウントと一致するユーザＩＤを含むユーザ属性部分情報３０２ａを削除する。

ステップＳ４７では、ＳＰアカウントプロビジョニング部３０８は、受信したアカウント連携要求メッセージに基づき、ＳＰサービス利用状況ストア３０４を更新する。具体的には、ＳＰアカウントプロビジョニング部３０８は、受信したアカウント連携要求メッセージに含まれる操作指示が「アカウント登録」である場合、当該アカウント連携要求メッセージ内のユーザ属性部分情報に含まれるユーザＩＤとサービス利用状況「サービス利用中」と、最終利用日時と、ディスク利用量と関連づけてＳＰサービス利用状況ストア３０４のユーザ利用管理テーブル３０４ａＡに登録するとともに、「サービス利用中」のユーザＩＤ数をカウントして利用数管理テーブル３０４ａＢの現在の利用数を更新する。

また、ＳＰアカウントプロビジョニング部３０８は、受信したアカウント連携要求メッセージに含まれる操作指示が「削除」である場合、当該アカウント連携要求メッセージに含まれる削除対象アカウントに基づいてＳＰサービス利用状況ストア３０４を検索し、検索結果のユーザ利用情報３０４ａに含まれるサービス利用状況を「サービス利用停止」に変更する。

ステップＳ４６のユーザリポジトリ操作とステップＳ４７のサービス利用状況ストア２０２更新後、ＳＰアカウントプロビジョニング部３０８は、登録したユーザ属性部分情報３０２ａ内のユーザＩＤと自装置のサービスプロバイダＩＤとを含む操作完了をアカウント連携要求メッセージの送信元のＩＤプロバイダ装置２００に通知する。具体的には、操作完了は、ＩＤプロバイダ装置２００内のＩＤＰアカウントプロビジョニング部２１１に通知される。

ステップＳ４８では、ＩＤＰアカウントプロビジョニング部２１１は、ステップＳ４５で発行された認証連携ＩＤをＩＤＰユーザリポジトリ２０１ａのＵＳＥＲ＿Ａのレコードに登録する。

ステップＳ４９では、ＩＤＰアカウントプロビジョニング部２１１は、ステップＳ４７で通知された操作完了を示すアカウント連携応答を認証連携ハンドリング部２０９に送出する。

以上により、ステップＳ４０のアカウント連携（Ｓ４１〜Ｓ４９）が終了する。

ステップＳ５０の認証連携では、アカウント連携終了後、ＩＤプロバイダ装置２００とサービスプロバイダ装置３００との間で認証連携、すなわちＳＳＯを行う。以下、図２２のシーケンス図および図２３の模式図を用いてステップＳ５０の認証連携について説明する。

ステップＳ５１では、認証連携ハンドリング部２０９は、ステップＳ４９にて通知されたアカウント連携応答に含まれる認証結果を解析する。その結果に問題がなければ、認証連携ハンドリング部２０９は、アカウント連携応答内の操作完了に含まれるサービスプロバイダＩＤおよびユーザＩＤを含む認証連携実行要求をＩＤＰ認証連携部２０８に送出する。

ステップＳ５２では、ＩＤＰ認証連携部２０８は、認証連携実行要求を受けると、当該認証連携実行要求内のユーザＩＤに基づいてＩＤＰユーザリポジトリを検索し、認証連携ＩＤを取得する。

ステップＳ５３では、ＩＤＰ認証連携部２０８は、ステップＳ５２で取得された認証連携ＩＤと、ステップＳ２５で行ったログイン処理の認証方式名とを含むアサーション本文を作成する。また、ＩＤＰ認証連携部２０８は、アサーション本文に対して鍵記憶部２０５内の署名生成鍵に基づくデジタル署名を生成する。さらに、ＩＤＰ認証連携部２０８は、当該アサーション本文と当該デジタル署名とを含む認証アサーション２０８ａを作成する。

ステップＳ５４では、ＩＤＰ認証連携部２０８は、作成した認証アサーション２０８ａと、受信した認証連携実行要求内のユーザＩＤを含む認証連携応答を、認証連携要求の送信元のサービスプロバイダ装置３００に送信する。この認証連携応答は、当該サービスプロバイダ装置３００のＳＰ認証連携部３０６に受信される。

ステップＳ５５では、ＳＰ認証連携部３０６は、認証アサーション検証ポリシ３０６内の認証方式名と署名検証鍵とに基づいて、認証アサーション２０８ａ内の認証方式名とデジタル署名とをそれぞれ検証する。これにより、ＳＰ認証連携部３０６は、ＩＤプロバイダ装置２００が発行した認証アサーション２０８ａから、ＩＤプロバイダ装置２００の認証結果を信頼できるかを判断し、ユーザへのサービスデータ送信（サービス提供）の可否を決定する。本実施形態では、検証した結果がいずれも正当であるとし、サービスデータ送信を許可として決定する。

ステップＳ５６では、ＳＰ認証連携部３０６は、ステップＳ５５で許可と決定されたとき、認証トークンを発行する。この認証トークンは認証連携ＩＤとユーザＩＤとに関連付けてサービスプロバイダ装置３００の一時記憶部（図示しない）に記憶されても良い。

ステップＳ５７では、ＳＰ認証連携部３０６は、ステップＳ５６で発行された認証トークンと、当該認証トークンに認証連携ＩＤを介して関連付けられたユーザＩＤとを含むサービス実行要求をサービスデータ通信部３０１に送出する。

ステップＳ５８では、サービスデータ通信部３０１は、送出されたサービス実行要求に基づいて、当該サービス実行要求内の認証トークンとサービスデータストア３０３内のサービスデータ３０３ａとをユーザ端末１００に送信する。

上述したように本実施形態の認証連携システムによれば、ユーザからのサービスプロバイダ装置３００へのサービス要求に対し、ＩＤプロバイダ装置２００内に配備された認証連携ハンドリング部２０８がサービスプロバイダ装置３００からの認証連携要求をインターセプトし、事前に定義された認証連携ポリシ２０３ａに基づき、サービスデータ３０３ａの送信可否を判定する。そして、判定結果が許可の場合、ＩＤプロバイダ装置２００内で管理される当該ユーザ属性情報２０１ａを使って、サービスプロバイダ装置３００内で管理されるＳＰユーザリポジトリ３０２に対して、当該ユーザのアカウントを作成する。その後、ＩＤプロバイダ装置２００とサービスプロバイダ装置３００の各々が、従来の認証連携処理を行い、当該ユーザに対してサービスプロバイダ装置３００から所望のサービスが提供される。

補足すると、従来の認証連携システムにおいては、サービスプロバイダがアカウントを登録するための十分な情報を保持していないことを確認し、不足したユーザ属性をＩＤプロバイダに要求する手間がかかり、このような確認や要求に人手を介していた。一方、本実施形態の認証連携システムは、前述した予め認証連携ポリシ２０３ａを記憶した構成により、従来のような確認や要求に人手を介することがない。

また、本実施形態の認証連携システムは、一般的に時間がかかる、ＩＤプロバイダ装置２００がサービスプロバイダ装置３００の利用状況を取得する利用状況取得処理を、ＳＳＯのタイミングで行うのではなく事前に行なっているため、ユーザのログイン時の待ち時間が長くなることがなく、ユーザの負荷を軽減できる。また、削除対象アカウントの決定も事前に行なっているため、よりユーザの負荷を軽減できる。

従って、サービスプロバイダ装置３００側に当該ユーザのアカウントが登録されてない状態でも、当該ユーザのサービス要求、すなわちＳＳＯの実施タイミングで、ＩＤプロバイダ装置２００側に事前に定義した認証連携ポリシ２０３ａに基づき、サービスデータ３０３ａの送信可否を自動判定することで、人手を介すことなく、且つ時間を要することなく、当該ユーザに対してシームレスなサービス利用を提供することができる。

また、本実施形態の認証連携システムによれば、インターネットなどの分散環境下で提供されるサービス利用において、事前に定義したサービス利用のポリシとサービスの利用状況に基づいて、サービスの利用申請からシングルサインオンまでの一連の処理を自動化し、ユーザのスムーズなサービス利用の開始を実現することができる。

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

例えば、本実施形態ではＩＤプロバイダ装置２００側が利用状況取得処理を要求するトリガを備えるが、サービスプロバイダ装置３００側が備えても良い。サービスプロバイダ装置３００側がトリガを備える場合、図１３のステップＳ１０におけるステップＳ１０のサービスにおいて、トリガは、例えばＳＰサービス利用状況ストア３０４に登録されたサービス利用状況が変化したか否かを判定し、サービス利用状況が変化した場合に、サービス利用状況取得実行要求をサービス利用状況提供部３０７送信する（ステップＳ１１）。ステップＳ１２は省略され、ステップＳ１３において、利用状況取得実行要求を受信したサービス利用状況提供部３０７がＳＰサービス利用状況ストア３０４からサービス利用状況を取得する。その後、ステップＳ１４〜ステップＳ１９の処理が行われる。

この場合、ＳＰサービス利用状況ストア３０４とＩＤＰサービス利用状況ストア２０２との間に差異が生じないため、サービス利用状況に基づいた正確なポリシ評価を行なうことが可能となる。

また、本実施形態の認証連携システムは、トリガ２１３によって開始されるステップＳ１０のサービス利用状況取得において、ステップＳ１５で削除対象アカウントの決定を行ない、削除対象アカウントを削除するのは、ステップＳ４０のアカウント連携において行っている。これは、アカウントの削除という操作を極力遅らせるためである。

しかし、ＳＳＯ時のレスポンスタイムの改善を優先するために、ステップＳ１０のサービス利用状況取得に削除対象アカウントの削除を行なっても良い。すなわち、ステップＳ１５の削除対象アカウント決定後にサービスプロバイダ装置３００にアカウント削除のメッセージを送ってもよい。この場合、ステップＳ４０のアカウント連携では、アカウントの登録のみを行うことになる。

また、ステップＳ４７のＳＰサービス利用状況ストア３０４の更新は、例えば一定周期毎にＳＰユーザリポジトリ３０２に記憶されたユーザ属性部分情報３０２ａを参照して行なうなど、ＳＳＯ処理中に行なわないようにしても良い。これにより、ユーザのログイン待ち時間が軽減できる。このときＳＰサービス利用状況ストア３０４の更新の一定周期は、サービス利用状況取得を開始するトリガに設定された一定周期より短くする。

なお、上記の実施形態に記載した手法は、コンピュータに実行させることのできるプログラムとして、磁気ディスク（フロッピー（登録商標）ディスク、ハードディスクなど）、光ディスク（ＣＤ−ＲＯＭ、ＤＶＤなど）、光磁気ディスク（ＭＯ）、半導体メモリなどの記憶媒体に格納して頒布することもできる。

ここで、この記憶媒体としては、プログラムを記憶でき、かつコンピュータが読み取り可能な記憶媒体であれば、その記憶形式は何れの形態であっても良い。

また、記憶媒体からコンピュータにインストールされたプログラムの指示に基づきコンピュータ上で稼働しているＯＳ（オペレーティングシステム）や、データベース管理ソフト、ネットワークソフト等のＭＷ（ミドルウェア）等が本実施形態を実現するための各処理の一部を実行しても良い。

さらに、本実施形態における記憶媒体は、コンピュータと独立した媒体に限らず、ＬＡＮやインターネット等により伝送されたプログラムをダウンロードして記憶または一時記憶した記憶媒体も含まれる。

また、記憶媒体は１つに限らず、複数の媒体から本実施形態における処理が実行される場合も本実施形態における記憶媒体に含まれ、媒体構成は何れの構成であっても良い。

なお、本実施形態におけるコンピュータは、記憶媒体に記憶されたプログラムに基づき、本実施形態における各処理を実行するものであって、パソコン等の１つからなる装置、複数の装置がネットワーク接続されたシステム等の何れの構成であっても良い。

また、本実施形態の各記憶部は１つの記憶装置で実現しても良いし、複数の記憶装で実現しても良い。

そして、本実施形態におけるコンピュータとは、パソコンに限らず、情報処理機器に含まれる演算処理装置、マイコン等も含み、プログラムによって本実施形態の機能を実現することが可能な機器、装置を総称している。

１００…ユーザ端末、２００…ＩＤプロバイダ装置、２０１…ＩＤＰユーザリポジトリ、２０２…ＩＤＰサービス利用状況ストア、２０３…認証連携ポリシストア、２０４…ＳＰユーザ設定ルールストア、２０５…鍵記憶部、２０６…削除対象決定ポリシストア、２０７…削除対象アカウントストア、２０８…ＩＤＰ認証連携部、２０９…認証連携ハンドリング部、２１０…認証連携ポリシ評価部、２１１…ＩＤＰアカウントプロビジョニング部、２１２…サービス利用状況管理部、２１３…トリガ、２１４…サービス利用状況取得部、２１５…削除対象アカウント決定部、３００…サービスプロバイダ装置、３０１…サービスデータ通信部、３０２…ＳＰユーザリポジトリ、３０３…サービスデータストア、３０４…ＳＰサービス利用状況ストア、３０５…検証ポリシストア、３０６…ＳＰ認証連携部、３０７…サービス利用状況提供部、３０８…ＳＰアカウントプロビジョニング部

Claims (6)

1. ユーザが操作するユーザ端末に対してログイン処理を行うＩＤプロバイダ装置と、前記ログイン処理が完了した場合に前記ユーザ端末にサービスデータを送信するサービスプロバイダ装置とを備え、前記ユーザ端末はサービス利用要求を前記サービスプロバイダ装置に送信する認証連携システムであって、
   前記ＩＤプロバイダ装置は、
   前記ユーザを識別するユーザＩＤを含み、前記ユーザを特定するためのユーザ属性の項目名と前記ユーザ属性の項目値とを関連付けたユーザ属性情報を記憶するユーザ属性情報記憶部と、
   前記ユーザＩＤと、前記サービスプロバイダ装置を識別するサービスプロバイダＩＤと、当該サービスプロバイダ装置の利用状況とを関連付けたサービス利用状況情報を記憶する第１のサービス利用状況記憶部と、
   前記サービスプロバイダＩＤ毎に、当該サービスプロバイダＩＤで識別されるサービスプロバイダ装置によるサービスデータの送信が許可される対象となるユーザを示す認証連携ポリシ情報を記憶する認証連携ポリシ記憶部と、
   前記サービスプロバイダＩＤと、前記ユーザ属性情報内のユーザ属性の項目名のうち、一部の項目名とを関連付けて記憶する一部項目名記憶部と、
   前記サービスプロバイダＩＤ毎に、当該サービスプロバイダＩＤで識別されるサービスプロバイダ装置におけるサービスデータの送信許可が削除される対象となるユーザを示す削除対象決定ポリシ情報を記憶する削除対象決定ポリシ記憶部と、
   所定の周期が到来した場合、もしくは前記サービスプロバイダ装置の利用状況が変化した場合に、前記サービスプロバイダ装置から送信されるサービス利用状況情報を取得し、取得した当該サービス利用状況情報に基づいて前記第１のサービス利用状況記憶部を更新する手段と、
   前記ユーザ属性情報と、前記サービス利用状況情報と、前記削除対象決定ポリシ情報とに基づいて、前記サービス利用状況情報に含まれる前記サービスプロバイダＩＤ毎の削除対象アカウントの決定を行なう手段と、
   前記サービス利用要求を受信した前記サービスプロバイダ装置から、当該サービスプロバイダ装置のサービスプロバイダＩＤと前記ユーザ端末のアドレス情報とを含む認証連携要求を受信すると、当該認証連携要求内のユーザ端末のアドレス情報を含むユーザ認証要求を送信する手段と、
   前記送信されたユーザ認証要求内のユーザ端末のアドレス情報に基づいて、当該ユーザ端末にログイン要求を送信し、当該ユーザ端末から受けたユーザＩＤ及びユーザ認証情報を前記ユーザ属性情報記憶部内のユーザＩＤ及びパスワードに基づいて認証するログイン処理を実行する手段と、
   前記ログイン処理が成功したとき、当該ログイン処理に用いたユーザＩＤと前記認証連携要求内のサービスプロバイダＩＤとを含むポリシ評価要求を送信する手段と、
   前記送信されたポリシ評価要求内のユーザＩＤに基づいて前記ユーザ属性記憶部からユーザ属性情報を読み出す手段と、
   前記送信されたポリシ評価要求内のサービスプロバイダＩＤに基づいて前記認証連携ポリシ記憶部から認証連携ポリシ情報を読み出す手段と、
   前記読み出した認証連携ポリシ情報と、前記読み出したユーザ属性情報とに基づいて、前記サービスデータの送信を許可するか否かを判定する手段と、
   この判定結果を含むポリシ評価応答を前記ポリシ評価要求の送信元に送信する手段と、 前記ポリシ評価応答内の判定結果が許可を示す場合、前記ポリシ評価要求内のユーザＩＤとサービスプロバイダＩＤとを含むアカウント連携要求を送信する手段と、
   前記送信されたアカウント連携要求内のサービスプロバイダＩＤに基づいて、前記一部項目名記憶部からユーザ属性の一部の項目名を読み出す手段と、
   当該読み出した一部の項目名と前記アカウント連携要求内のユーザＩＤとに基づいて前記ユーザ属性記憶部内で当該ユーザＩＤに一致するユーザＩＤを含むユーザ属性情報のうち、当該一部の項目名に一致する項目名及びこの項目名に関連付けられた項目値からなるユーザ属性部分情報を取得する手段と、
   前記送信されたアカウント連携要求内のサービスプロバイダＩＤに基づいて、前記削除対象アカウント決定部が決定した前記削除対象アカウントから削除対象アカウントを取得する手段と、
   前記取得したユーザ属性部分情報に操作指示としてアカウント登録指示を付加し、前記取得した削除対象アカウントに操作指示としてアカウント削除指示もしくはアカウント無効指示を付加し、アカウント連携要求メッセージを作成する手段と、
   前記アカウント連携要求メッセージを前記認証連携要求の送信元のサービスプロバイダ装置に送信する手段と、
   前記アカウント連携要求メッセージの送信先のサービスプロバイダ装置から当該サービスプロバイダ装置のサービスプロバイダＩＤと前記ユーザ属性部分情報内の当該ユーザ端末のアドレス情報とを含む更新完了が通知されると、当該更新完了を示すアカウント連携応答を送信する手段と、
   前記送信されたアカウント連携応答内の更新完了に含まれるサービスプロバイダＩＤ及び前記ユーザＩＤを含む認証連携実行要求を送信する手段と、
   前記認証連携実行要求を受信すると、当該認証連携実行要求内のユーザＩＤを含む認証連携応答を前記認証連携要求の送信元のサービスプロバイダ装置に送信する手段と、
   を備え、
   前記サービスプロバイダ装置は、
   前記ユーザ属性情報記憶部内のユーザ属性情報内のユーザ属性の項目名及び項目値のうちの一部の項目名と項目値とを関連付けたユーザ属性部分情報と、当該サービスプロバイダ装置内でユーザを識別するＳＰ側ユーザＩＤとを関連付けて記憶するユーザ属性部分情報記憶部と、
   前記サービスデータを記憶するサービスデータ記憶部と、
   前記ユーザＩＤと、当該サービスプロバイダ装置の利用状況とを関連付けて記憶する第２のサービス利用状況記憶部と
   前記サービス利用状況記憶部から当該サービスプロバイダ装置の利用状況を取得し、取得した前記利用状況を前記ＩＤプロバイダ装置に送信する手段と、
   前記ユーザ端末から前記サービス要求を受信すると、当該サービス要求が認証トークンを含むか否かを判定し、前記認証トークンを含む場合には当該認証トークンと前記サービスデータ記憶部内のサービスデータとを当該ユーザ端末に送信し、否の場合には前記認証連携要求を前記ＩＤプロバイダ装置に送信する手段と、
   前記アカウント連携要求メッセージを受信すると、当該前記アカウント連携要求メッセージに含まれる前記操作指示が前記アカウント登録の場合に新規の前記ＳＰ側ユーザＩＤを発行し、当該発行したＳＰ側ユーザＩＤと、当該アカウント連携要求メッセージ内のユーザ属性部分情報とを関連付けて前記ユーザ属性部分情報記憶部に登録する手段と、当該前記アカウント連携要求メッセージに含まれる前記操作指示が前記アカウント削除の場合に、当該アカウント連携要求メッセージ内の削除対象アカウントに基づいて前記ユーザ属性部分情報記憶部を検索し、当該削除対象アカウントと一致するユーザＩＤを含む前記ユーザ属性部分情報を削除する手段と、
   前記登録もしくは削除の後、登録したユーザ属性部分情報内のユーザＩＤもしくは削除したユーザ属性部分情報内のユーザＩＤと、当該サービスプロバイダ装置のサービスプロバイダＩＤとを含む更新完了を前記アカウント連携要求メッセージの送信元のＩＤプロバイダ装置に通知する手段と、
   前記ＩＤプロバイダ装置から前記認証連携応答を受信すると、当該認証連携応答の検証を行い、検証結果が許可のとき、前記認証トークンを発行し、前記認証連携応答に含まれるユーザＩＤと、当該認証トークンとを含むサービス実行要求を送信する手段と、
   前記送信されたサービス実行要求に基づいて、当該サービス実行要求内の認証トークンと前記サービスデータ記憶部内のサービスデータとを前記ユーザ端末に送信する手段と
   を備える認証連携システム。
2. 前記サービス利用状況情報に基づいて、前記サービスデータの送信を許可するか否かを判定する手段を備える請求項１に記載の認証連携システム。
3. 前記削除対象アカウントと前記ユーザ属性部分情報に含まれるユーザＩＤとが一致する場合、当該ユーザ属性部分情報を無効とする手段を備える請求項１及び請求項２のいずれか１項に記載の認証連携システム。
4. 前記第２のサービス利用状況記憶部に記憶される前記サービスプロバイダ装置の利用状況が変化した場合に、当該利用状況を前記ＩＤプロバイダ装置に送信する手段を備える請求項１乃至請求項３のいずれか１項に記載の認証連携システム。
5. ユーザが操作するユーザ端末にサービスデータを送信するサービスプロバイダ装置と接続され認証連携システムを構成する、前記サービスプロバイダ装置にサービス利用要求をするとともに前記ユーザ端末に対してログイン処理を行うＩＤプロバイダ装置であって、
   前記ユーザを識別するユーザＩＤを含み、前記ユーザを特定するためのユーザ属性の項目名と前記ユーザ属性の項目値とを関連付けたユーザ属性情報を記憶するユーザ属性情報記憶部と、
   前記ユーザＩＤと、前記サービスプロバイダ装置を識別するサービスプロバイダＩＤと、当該サービスプロバイダ装置の利用状況とを関連付けたサービス利用状況情報を記憶する第１のサービス利用状況記憶部と、
   前記サービスプロバイダＩＤ毎に、当該サービスプロバイダＩＤで識別されるサービスプロバイダ装置によるサービスデータの送信が許可される対象となるユーザを示す認証連携ポリシ情報を記憶する認証連携ポリシ記憶部と、
   前記サービスプロバイダＩＤと、前記ユーザ属性情報内のユーザ属性の項目名のうち、一部の項目名とを関連付けて記憶する一部項目名記憶部と、
   前記サービスプロバイダＩＤ毎に、当該サービスプロバイダＩＤで識別されるサービスプロバイダ装置におけるサービスデータの送信許可が削除される対象となるユーザを示す削除対象決定ポリシ情報を記憶する削除対象決定ポリシ記憶部と、
   前記サービスプロバイダ装置に利用状況取得要求を送信し、当該利用状況取得要求に基づいて前記サービスプロバイダ装置から送信されるサービス利用状況情報を取得し、取得した前記サービス利用状況情報に基づいて前記サービス利用状況記憶部を更新する手段と、
   前記ユーザ属性情報と、前記サービス利用状況情報と、前記削除対象決定ポリシ情報とに基づいて、前記サービス利用状況情報に含まれる前記サービスプロバイダＩＤ毎の削除対象アカウントの決定を行なう手段と、
   前記サービス利用要求を受信した前記サービスプロバイダ装置から、当該サービスプロバイダ装置のサービスプロバイダＩＤと前記ユーザ端末のアドレス情報とを含む認証連携要求を受信すると、当該認証連携要求内のユーザ端末のアドレス情報を含むユーザ認証要求を送信する手段と、
   前記送信されたユーザ認証要求内のユーザ端末のアドレス情報に基づいて、当該ユーザ端末にログイン要求を送信し、当該ユーザ端末から受けたユーザＩＤ及びユーザ認証情報を前記ユーザ属性情報記憶部内のユーザＩＤ及びパスワードに基づいて認証するログイン処理を実行する手段と、
   前記ログイン処理が成功したとき、当該ログイン処理に用いたユーザＩＤと前記認証連携要求内のサービスプロバイダＩＤとを含むポリシ評価要求を送信する手段と、
   前記送信されたポリシ評価要求内のユーザＩＤに基づいて前記ユーザ属性記憶部からユーザ属性情報を読み出す手段と、
   前記送信されたポリシ評価要求内のサービスプロバイダＩＤに基づいて前記認証連携ポリシ記憶部から認証連携ポリシ情報を読み出す手段と、
   前記読み出した認証連携ポリシ情報と、前記読み出したユーザ属性情報とに基づいて、前記サービスデータの送信を許可するか否かを判定する手段と、
   この判定結果を含むポリシ評価応答を前記ポリシ評価要求の送信元に送信する手段と、 前記ポリシ評価応答内の判定結果が許可を示す場合、前記ポリシ評価要求内のユーザＩＤとサービスプロバイダＩＤとを含むアカウント連携要求を送信する手段と、
   前記送信されたアカウント連携要求内のサービスプロバイダＩＤに基づいて、前記一部項目名記憶部からユーザ属性の一部の項目名を読み出す手段と、
   当該読み出した一部の項目名と前記アカウント連携要求内のユーザＩＤとに基づいて前記ユーザ属性記憶部内で当該ユーザＩＤに一致するユーザＩＤを含むユーザ属性情報のうち、当該一部の項目名に一致する項目名及びこの項目名に関連付けられた項目値からなるユーザ属性部分情報を取得する手段と、
   前記送信されたアカウント連携要求内のサービスプロバイダＩＤに基づいて、前記削除対象アカウント決定部が決定した前記削除対象アカウントから削除対象アカウントを取得する手段と、
   前記取得したユーザ属性部分情報に操作指示としてアカウント登録指示を付加し、前記取得した削除対象アカウントに操作指示としてアカウント削除指示もしくはアカウント無効指示を付加し、アカウント連携要求メッセージを作成する手段と、
   前記アカウント連携要求メッセージを前記認証連携要求の送信元のサービスプロバイダ装置に送信する手段と、
   前記アカウント連携要求メッセージの送信先のサービスプロバイダ装置から当該サービスプロバイダ装置のサービスプロバイダＩＤと前記ユーザ属性部分情報内の当該ユーザ端末のアドレス情報とを含む更新完了が通知されると、当該更新完了を示すアカウント連携応答を送信する手段と、
   前記送信されたアカウント連携応答内の更新完了に含まれるサービスプロバイダＩＤ及び前記ユーザＩＤを含む認証連携実行要求を送信する手段と、
   前記認証連携実行要求を受信すると、当該認証連携実行要求内のユーザＩＤを含む認証連携応答を前記認証連携要求の送信元のサービスプロバイダ装置に送信する手段と、
   を備えるＩＤプロバイダ装置。
6. ユーザが操作するユーザ端末にサービスデータを送信するサービスプロバイダ装置と接続され、認証連携システムを構成する、前記サービスプロバイダ装置にサービス利用要求をするとともに前記ユーザ端末に対してログイン処理を行うＩＤプロバイダ装置のプログラムであって、
   前記ＩＤプロバイダ装置を構成するコンピュータに、
   前記ユーザを識別するユーザＩＤを含み、前記ユーザを特定するためのユーザ属性の項目名と前記ユーザ属性の項目値とを関連付けたユーザ属性情報を記憶する機能と、
   前記サービスプロバイダＩＤ毎に、当該サービスプロバイダＩＤで識別されるサービスプロバイダ装置によるサービスデータの送信が許可される対象となるユーザを示す認証連携ポリシ情報を記憶する機能と、
   前記サービスプロバイダＩＤと、前記ユーザ属性情報内のユーザ属性の項目名のうち、一部の項目名とを関連付けて記憶する機能と、
   前記サービスプロバイダＩＤ毎に、当該サービスプロバイダＩＤで識別されるサービスプロバイダ装置におけるサービスデータの送信許可が削除される対象となるユーザを示す削除対象決定ポリシ情報を記憶する機能と、
   前記サービスプロバイダ装置に利用状況取得要求を送信し、当該利用状況取得要求に基づいて前記サービスプロバイダ装置から送信されるサービス利用状況を取得し、取得した前記サービス利用状況情報に基づいて、前記ユーザＩＤと、前記サービスプロバイダ装置を識別するサービスプロバイダＩＤと、サービスプロバイダ装置の利用状況とを関連付けたサービス利用状況情報を記憶する機能と、
   前記ユーザ属性情報と、前記サービス利用状況情報と、前記削除対象決定ポリシ情報とに基づいて、前記サービス利用状況情報に含まれる前記サービスプロバイダＩＤ毎の削除対象アカウントの決定を行なう機能と、
   前記サービス利用要求を受信した前記サービスプロバイダ装置から、当該サービスプロバイダ装置のサービスプロバイダＩＤと前記ユーザ端末のアドレス情報とを含む認証連携要求を受信すると、当該認証連携要求内のユーザ端末のアドレス情報を含むユーザ認証要求を送信する機能と、
   前記送信されたユーザ認証要求内のユーザ端末のアドレス情報に基づいて、当該ユーザ端末にログイン要求を送信し、当該ユーザ端末から受けたユーザＩＤ及びユーザ認証情報を前記ユーザ属性情報のユーザＩＤ及びパスワードに基づいて認証するログイン処理を実行する機能と、
   前記ログイン処理が成功したとき、当該ログイン処理に用いたユーザＩＤと前記認証連携要求内のサービスプロバイダＩＤとを含むポリシ評価要求を送信する機能と、
   前記送信されたポリシ評価要求内のユーザＩＤに基づいて前記ユーザ属性情報を読み出す機能と、
   前記送信されたポリシ評価要求内のサービスプロバイダＩＤに基づいて前記認証連携ポリシ情報を読み出す機能と、
   前記読み出した認証連携ポリシ情報と、前記読み出したユーザ属性情報とに基づいて、前記サービスデータの送信を許可するか否かを判定する機能と、
   この判定結果を含むポリシ評価応答を前記ポリシ評価要求の送信元に送信する機能と、 前記ポリシ評価応答内の判定結果が許可を示す場合、前記ポリシ評価要求内のユーザＩＤとサービスプロバイダＩＤとを含むアカウント連携要求を送信する機能と、
   前記送信されたアカウント連携要求内のサービスプロバイダＩＤに基づいて、前記ユーザ属性の一部の項目名を読み出す機能と、
   当該読み出した一部の項目名と前記アカウント連携要求内のユーザＩＤとに基づいて、当該ユーザＩＤに一致するユーザＩＤを含む前記ユーザ属性情報のうち、当該一部の項目名に一致する項目名及びこの項目名に関連付けられた項目値からなるユーザ属性部分情報を取得する機能と、
   前記送信されたアカウント連携要求内のサービスプロバイダＩＤに基づいて、前記決定された削除対象アカウントから削除対象アカウントを取得する機能と、
   前記取得したユーザ属性部分情報に操作指示としてアカウント登録指示を付加し、前記取得した削除対象アカウントに操作指示としてアカウント削除指示もしくはアカウント無効指示を付加し、アカウント連携要求メッセージを作成する機能と、
   前記アカウント連携要求メッセージを前記認証連携要求の送信元のサービスプロバイダ装置に送信する機能と、
   前記アカウント連携要求メッセージの送信先のサービスプロバイダ装置から当該サービスプロバイダ装置のサービスプロバイダＩＤと前記ユーザ属性部分情報内の当該ユーザ端末のアドレス情報とを含む更新完了が通知されると、当該更新完了を示すアカウント連携応答を送信する機能と、
   前記送信されたアカウント連携応答内の更新完了に含まれるサービスプロバイダＩＤ及び前記ユーザＩＤを含む認証連携実行要求を送信する機能と、
   前記認証連携実行要求を受信すると、当該認証連携実行要求内のユーザＩＤを含む認証連携応答を前記認証連携要求の送信元のサービスプロバイダ装置に送信する機能と、
   を実行させるプログラム。

Images