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

Abstract

【課題】 ＳＳＯの過程でアカウント登録及び連携を実行する際に、人手を介さずにサービス利用可否を決定する。
【解決手段】 前記ＩＤプロバイダ装置のポリシ記憶手段は、前記サービスプロバイダＩＤ毎に、サービスデータの送信が許可されるユーザの所属及び役職を示す複数のポリシ情報を記憶する。前記ＩＤプロバイダ装置は、前記ログイン処理が成功したとき、当該ログイン処理に用いたユーザＩＤと前記認証連携要求内のサービスプロバイダＩＤとを含むポリシ評価要求を送出する。前記ＩＤプロバイダ装置は、ポリシ評価要求に基づいて前記ポリシ記憶手段からポリシ情報を読み出す。前記ＩＤプロバイダ装置の送信許可判定手段は、ポリシ情報に示される所属及び役職に対しユーザ属性情報内の所属及び役職が適合するか否かに応じて、前記サービスデータの送信を許可するか否かを判定する。
【選択図】図１

Description

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

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

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

このようなアイデンティティ管理を利用した技術の代表例として、シングルサインオン（Single Sign-On、以降ＳＳＯと略す）がある。ＳＳＯは、一度の認証手続きで複数のアプリケーションやサービスを利用できる技術である。ＳＳＯは、一つの企業のイントラネットのようなシングルドメインにおいて、複数のアプリケーションが備える認証を統合させる場合が多かった。この場合、ＳＳＯは、一般的にＨＴＴＰ Ｃｏｏｋｉｅに認証結果を含め、アプリケーション間で認証結果を共有させる方式によって実現される。また、このようなＳＳＯ方式をＳＩ（System Integration）ベンダやミドルウェアベンダが個別にアクセス管理製品として製造していた。

近年、シングルドメインを超えた異なるドメイン間（以下、クロスドメインともいう）でのＳＳＯが求められてきた。理由としては、企業統合や合併、海外展開などの活発化、および台頭してきたクラウドコンピューティングのＳａａＳ（Software as a Service）等によるアウトソーシングが挙げられる。例えば、ＳａａＳ等は、使いたいときに素早く使える点がメリットの一つである。

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

このような原因を解消するため、ＳＳＯの標準化の要望が高まるようになった。このような要望に応じた代表的な標準技術の一つとして、非営利団体ＯＡＳＩＳ（Organization for the Advancement of Structured Information Standards）が策定したＳＡＭＬ（Security Assertion Markup Language）がある。

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

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

このような事前準備の後、ＳＳＯは以下のような手順（１）〜（６）に沿って実現される。ここでは、Ｗｅｂブラウザを介したＳＳＯの手順を説明する。

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

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

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

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

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

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

このように、ＳＡＭＬに基づくＳＳＯでは、ユーザが一度の認証手続きをＩＤプロバイダに行うだけで更なる認証手続きを実行せずに、複数のサービスが使用可能となる。現在では、個別のＳＳＯ方式を実装していたミドルウェアベンダは、クロスドメインの相互運用性を確保するために、ＳＡＭＬのＩＤプロバイダ・サービスプロバイダ機能を実装したアクセス管理製品の販売や、ＳＡＭＬのサービスプロバイダ機能を実装した商用のＷｅｂサービスへの導入を実行している。

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

アイデンティティの登録、変更、削除、再発行、一時停止などを自動化する技術としてアカウントプロビジョニングがあり、その標準技術としてＳＰＭＬ（Service Provisioning Markup Language）がある。

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

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

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

"Assertions and Protocols for the OASIS Security Assertion Markup Language（SAML） V2.0"，OASIS Standard，15 March 2005， http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf "OASIS Service Provisioning Markup Language (SPML) Version 2"， OASIS Standard，1 April 2006， http://www.oasis-open.org/committees/provision/docs/pstc-spml2-os.pdf

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

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

通常、企業において、サービスプロバイダが提供するサービスを利用する場合、ＩＳ（Information System）部門がサービスプロバイダに対して、アカウント登録及び連携を行う。

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

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

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

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

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

実施形態の認証連携システムは、ユーザが操作するユーザ端末にログイン処理を実行可能で第１メモリを有するＩＤプロバイダ装置と、前記ログイン処理が成功した場合に前記ユーザ端末にサービスデータを送信可能で第２メモリを有する複数のサービスプロバイダ装置とを備えている。

前記ＩＤプロバイダ装置のユーザ属性情報記憶手段は、前記ユーザを特定するためのユーザ属性の項目名と前記ユーザ属性の項目値とを関連付けたユーザ属性情報であって、少なくとも前記ユーザを識別するユーザＩＤを前記項目名に含む複数の前記ユーザ属性情報を記憶する。

前記ＩＤプロバイダ装置のサービス利用状況記憶手段は、前記ユーザＩＤと、前記各サービスプロバイダ装置を識別するサービスプロバイダＩＤと、前記サービスデータの送信が許可された場合を示すサービス利用中、又は前記サービスデータの送信が許可されていない場合を示すサービス未利用のいずれかを示すサービス利用状況とを関連付けて記憶する。

前記ＩＤプロバイダ装置のポリシ記憶手段は、前記サービスプロバイダＩＤ毎に、当該サービスプロバイダＩＤで識別されるサービスプロバイダ装置によるサービスデータの送信が許可される対象となるユーザを示す複数のポリシ情報を記憶する。

前記ＩＤプロバイダ装置の一部項目名記憶手段は、前記サービスプロバイダＩＤと、前記ユーザ属性情報内のユーザ属性の項目名のうち、一部の項目名とを関連付けて記憶する。

前記ＩＤプロバイダ装置の鍵記憶手段は、自装置の署名生成鍵を記憶する。

前記ＩＤプロバイダ装置は、いずれかの前記サービスプロバイダ装置から送信されて当該サービスプロバイダ装置のサービスプロバイダＩＤと前記ユーザ端末のアドレス情報とを含む認証連携要求を受けると、当該認証連携要求内のユーザ端末のアドレス情報を含むユーザ認証要求を送出する。

前記ＩＤプロバイダ装置は、前記送出されたユーザ認証要求内のユーザ端末のアドレス情報に基づいて、当該ユーザ端末にログイン要求を送信し、当該ユーザ端末から受けたユーザＩＤ及びユーザ認証情報を前記ユーザ属性情報記憶手段内のユーザＩＤ及び参照情報に基づいて認証するログイン処理を実行する。

前記ＩＤプロバイダ装置は、前記ログイン処理が成功したとき、当該ログイン処理に用いたユーザＩＤと前記認証連携要求内のサービスプロバイダＩＤとを含むポリシ評価要求を送出する。

前記ＩＤプロバイダ装置は、前記送出されたポリシ評価要求内のユーザＩＤに基づいて前記ユーザ属性記憶手段からユーザ属性情報を読み出す。

前記ＩＤプロバイダ装置は、前記送出されたポリシ評価要求内のサービスプロバイダＩＤに基づいて前記ポリシ記憶手段からポリシ情報を読み出す。

前記ＩＤプロバイダ装置の送信許可判定手段は、前記読み出したポリシ情報に対し、前記読み出したユーザ属性情報、ユーザが利用したいサービスの種類、ユーザが行いたいサービスへの操作、サービスを実行するに際してのユーザの環境条件に適合するか否かと、当該読み出したポリシ情報に示される利用料金の上限値に対して前記受信した利用料金応答内の利用料金が適合するか否かとに応じて、前記サービスデータの送信を許可するか否かを判定する。

前記ＩＤプロバイダ装置は、この判定結果を含むポリシ評価応答を前記ポリシ評価要求の送信元に送出する。

前記ＩＤプロバイダ装置は、前記ポリシ評価応答内の判定結果が許可を示す場合、前記ポリシ評価要求内のユーザＩＤとサービスプロバイダＩＤとを含むアカウント連携要求を送出する。

前記ＩＤプロバイダ装置は、前記送出されたアカウント連携要求内のサービスプロバイダＩＤに基づいて、前記一部項目名記憶手段からユーザ属性の一部の項目名を読み出す。

前記ＩＤプロバイダ装置は、当該読み出した一部の項目名と前記アカウント連携要求内のユーザＩＤとに基づいて、前記ユーザ属性記憶手段内で当該ユーザＩＤに一致するユーザＩＤを含むユーザ属性情報のうち、当該一部の項目名に一致する項目名及びこの項目名に関連付けられた項目値からなるユーザ属性部分情報を取得する。

前記ＩＤプロバイダ装置は、前記取得したユーザ属性部分情報にアカウント登録指示を付加してアカウント連携要求メッセージを作成する。

前記ＩＤプロバイダ装置は、前記アカウント連携要求メッセージを前記認証連携要求の送信元のサービスプロバイダ装置に送信する。

前記ＩＤプロバイダ装置は、前記アカウント連携要求メッセージの送信先のサービスプロバイダ装置から当該サービスプロバイダ装置のサービスプロバイダＩＤと前記ユーザ属性部分情報内のユーザＩＤとを含む登録完了が通知されると、当該登録完了を示すアカウント連携応答を送出する。

前記ＩＤプロバイダ装置は、前記送出されたアカウント連携応答内の登録完了に含まれるサービスプロバイダＩＤ及びユーザＩＤに基づいて、前記サービス利用状況記憶手段内のサービス利用状況をサービス未利用からサービス利用中に更新する。

前記ＩＤプロバイダ装置は、前記送出されたアカウント連携応答内の登録完了に含まれるサービスプロバイダＩＤ及びユーザＩＤを含む認証連携実行要求を送出する。

前記ＩＤプロバイダ装置は、前記認証連携実行要求を受けると、当該認証連携実行要求内のサービスプロバイダＩＤで識別されるサービスプロバイダ装置と自装置との間で共有する認証連携ＩＤを発行し、この認証連携ＩＤと当該認証連携実行要求内のユーザＩＤとを関連付けて前記第１メモリに書き込む。

前記ＩＤプロバイダ装置は、前記発行した認証連携ＩＤと、前記ログイン処理の認証方式名とを含むアサーション本文に対して前記署名生成鍵に基づくデジタル署名を生成し、当該アサーション本文と当該デジタル署名とを含む認証アサーションを作成する。

前記ＩＤプロバイダ装置は、前記作成した認証アサーションを含む認証連携応答を前記認証連携要求の送信元のサービスプロバイダ装置に送信する。

前記各サービスプロバイダ装置のユーザ属性部分情報記憶手段は、前記ユーザ属性情報記憶手段内のユーザ属性情報内のユーザ属性の項目名及び項目値のうちの一部の項目名と項目値とを関連付けたユーザ属性部分情報と、自装置内でユーザを識別するＳＰ側ユーザＩＤとを関連付けて記憶する。

前記各サービスプロバイダ装置の検証ポリシ記憶手段は、前記ログイン処理が成功した場合にサービスデータの送信を許可するログイン処理の認証方式名と、前記署名生成鍵に対応する署名検証鍵とを含む認証アサーション検証ポリシを記憶する。

前記各サービスプロバイダ装置のサービスデータ記憶手段は、前記サービスデータを記憶する。

前記各サービスプロバイダ装置は、前記ユーザ端末からサービス要求を受けると、当該サービス要求が認証トークンを含むか否かを判定し、前記認証トークンを含む場合には当該認証トークンと前記サービスデータ記憶手段内のサービスデータとを当該ユーザ端末に送信し、否の場合には自装置のサービスプロバイダＩＤと当該ユーザ端末のアドレス情報とを含む認証連携要求を前記ＩＤプロバイダ装置に送信する。

前記各サービスプロバイダ装置は、前記アカウント連携要求メッセージを受信すると、新規の前記ＳＰ側ユーザＩＤを発行し、当該発行したＳＰ側ユーザＩＤと、当該アカウント連携要求メッセージ内のユーザ属性部分情報とを関連付けて前記ユーザ属性部分情報記憶手段に登録する。

前記各サービスプロバイダ装置は、この登録の後、登録したユーザ属性部分情報内のユーザＩＤと自装置のサービスプロバイダＩＤとを含む登録完了を前記アカウント連携要求メッセージの送信元のＩＤプロバイダ装置に通知する。

前記各サービスプロバイダ装置は、前記ＩＤプロバイダ装置から認証連携応答を受けると、当該認証連携応答内の認証アサーションから認証連携ＩＤを抽出し、当該抽出した認証連携ＩＤと、前記登録されたユーザ属性部分情報内のユーザＩＤとを関連付けて前記第２メモリに書き込む。

前記各サービスプロバイダ装置は、前記認証アサーション検証ポリシ内の認証方式名と署名検証鍵とに基づいて、前記認証アサーション内の認証方式名とデジタル署名とをそれぞれ検証する。

前記各サービスプロバイダ装置は、前記検証した結果がいずれも正当のとき、認証トークンを発行し、この認証トークンを前記認証連携ＩＤに関連付けて前記第２メモリに書き込む。

前記各サービスプロバイダ装置は、前記書き込まれた認証トークンと、当該認証トークンに前記第２メモリ内で前記認証連携ＩＤを介して関連付けられたユーザＩＤとを含むサービス実行要求を送出する。

前記各サービスプロバイダ装置は、前記送出されたサービス実行要求に基づいて、当該サービス実行要求内の認証トークンと前記サービスデータ記憶手段内のサービスデータとを前記ユーザ端末に送信する。

第１の実施形態に係る認証連携システム及びその周辺構成を示す模式図である。 同実施形態におけるＩｄＰユーザリポジトリを説明するための模式図である。 同実施形態におけるサービス利用状況データストアを説明するための模式図である。 同実施形態における認証連携ポリシストアを説明するための模式図である。 同実施形態におけるＳＰユーザ設定ルールストアを説明するための模式図である。 同実施形態における一時記憶部を説明するための模式図である。 同実施形態における認証アサーションを説明するための模式図である。 同実施形態における信頼ＩｄＰストアを説明するための模式図である。 同実施形態におけるＳＰユーザリポジトリを説明するための模式図である。 同実施形態におけるサービスデータストアを説明するための模式図である。 同実施形態における利用状況ストアを説明するための模式図である。 同実施形態における一時記憶部を説明するための模式図である。 同実施形態における検証ポリシストアを説明するための模式図である。 同実施形態における全体動作の概要を示す模式図である。 同実施形態におけるユーザ認証の処理フローを示すシーケンス図である。 同実施形態におけるユーザ認証の処理に必要な構成要素の一例を示すブロック図である。 同実施形態における認証連携ポリシ評価の処理フローを示すシーケンス図である。 同実施形態における認証連携ポリシ評価の処理に必要な構成要素の一例を示すブロック図である。 同実施形態におけるアカウント連携の処理フローを示すシーケンス図である。 同実施形態におけるアカウント連携の処理に必要な構成要素の一例を示すブロック図である。 同実施形態における認証連携の処理フローを示すシーケンス図である。 同実施形態における認証連携の処理に必要な構成要素の一例を示すブロック図である。 第２の実施形態における利用状況ストアを説明するための模式図である。 同実施形態におけるサービス利用状況ストアを説明するための模式図である。 第３の実施形態における利用状況ストアを説明するための模式図である。 同実施形態におけるサービス利用状況ストアを説明するための模式図である。

以下、各実施形態について図面を用いて説明する。なお、各実施形態では、既にＩＤプロバイダとサービスプロバイダ間で信頼関係が確立された状態、ユーザはＩＤプロバイダ側の組織に所属する状態、認証連携ポリシは事前に定義済みであることを前提条件としている。また、各装置は、ハードウェア構成、又はハードウェア資源とソフトウェアとの組合せ構成のいずれでも実施可能となっている。組合せ構成のソフトウェアとしては、予めネットワーク又は記憶媒体から対応する装置のコンピュータにインストールされ、対応する装置の機能を実現させるためのプログラムが用いられる。

＜第１の実施形態＞
図１は第１の実施形態に係る認証連携システム及びその周辺構成を示す模式図であり、図２乃至図１３は同実施形態におけるリポジトリ、ストア又は記憶部等を説明するための模式図である。この認証連携システムは、ユーザが操作するユーザ端末１００に対してログイン処理を実行可能なＩＤプロバイダ装置２００と、ログイン処理が成功した場合にユーザ端末１００にサービスデータを送信可能なサービスプロバイダ装置３００とを備えている。なお、サービスプロバイダ装置３００は、複数台あるが、ここでは１台のみを図示している。

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

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

ここで、ＩｄＰユーザリポジトリ２０１は、ＩＤプロバイダ装置２００が配置される組織のユーザに関するアイデンティティ情報（以下、「ユーザ属性情報」という）を記憶する。具体的には、ＩｄＰユーザリポジトリ（ユーザ属性情報記憶手段）２０１は、図２に示すように、ユーザを特定するためのユーザ属性の項目名とユーザ属性の項目値とを関連付けたユーザ属性情報２０１ａであって、ユーザを識別するユーザＩＤと、ユーザの氏名と、ユーザの所属と、ユーザの役職と、ユーザ端末のアドレス情報と、ユーザのログイン処理時に参照する参照情報とを項目名に含む複数のユーザ属性情報２０１ａを記憶する。

なお、ユーザ属性情報２０１ａは個人の情報を特徴付ける情報の集合体であり、ユーザ属性情報２０１ａの例としては、ユーザの氏名、ユーザの所属、ユーザの役職、ユーザ端末のアドレス情報、ユーザのログイン処理時に参照する参照情報などが挙げられる。しかし、これらには限られず、例えば電話番号や勤務状態といった任意の項目名と項目地とを更に含んでもよい。また、ユーザのログイン処理時に参照する参照情報は、本実施形態ではパスワードを用いるが、これには限られず、例えばユーザの指紋等の生体認証情報であってもよい。

サービス利用状況ストア２０２は、認証連携ポリシ評価部２０９から参照され、サービスの利用状況を記憶する。具体的には、サービス利用状況ストア（サービス利用状況記憶手段）２０２は、図３に示すように、ユーザ利用管理テーブル２０２ａと、利用数管理テーブル２０２ｂとを記憶している。ユーザ利用管理テーブル２０２ａは、ユーザＩＤと、各サービスプロバイダ装置３００を識別するサービスプロバイダＩＤ（ＳＰ（１）〜ＳＰ（Ｎ））と、サービスデータの送信が許可された場合を示すサービス利用中、又はサービスデータの送信が許可されていない場合を示すサービス未利用のいずれかを示すサービス利用状況とを関連付けて書き込まれる。なお、サービス利用状況は、サービス利用中及びサービス未利用に限らず、例えばユーザ端末１００から受けた一時停止要求に基づくサービス一時停止中、及び／又はユーザ端末１００から受けた利用終了要求に基づくサービス利用終了を含んでもよい。また、サービス利用終了は、現在の利用数が上限値を超えた場合に、ＩＤプロバイダ装置２００が遊休ユーザの利用を無効化した場合を含んでもよい。さらに、利用数管理テーブル２０２ｂは、図３に示すように、ユーザ管理テーブル２０２ａ内のサービス利用状況が示すサービス利用中の個数を示す利用数と、利用数の上限値とを関連付けて書き込まれる。

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

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

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

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

ＳＰユーザ設定ルールストア（一部項目名記憶手段）２０４は、図５に示すように、ユーザ設定ルール２０４ａを記憶する。ユーザ設定ルール２０４ａは、サービスプロバイダＩＤと、ＩｄＰユーザリポジトリ２０１に記憶されたユーザ属性情報２０１ａ内のユーザ属性の項目名のうち、一部の項目名とを関連付けて書き込まれている。

一時記憶部（第１メモリ）２０５は、ＲＡＭ等のような一時的なメモリであり、図６に示すように、例えば、認証連携ＩＤとユーザＩＤとを関連付けて記憶する。

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

ＩｄＰ認証連携部２０７は、シングルサインオンのＩＤプロバイダ機能を有する。ＩｄＰ認証連携部２０７は、具体的には例えば、以下の機能(f207-1)〜(f207-4)をもっている。

(f207-1) 認証連携ハンドリング部２０８から送出されたユーザ認証要求内のユーザ端末１００のアドレス情報に基づいて、当該ユーザ端末１００にログイン要求を送信し、当該ユーザ端末１００から受けたユーザＩＤ及びユーザ認証情報をＩｄＰユーザリポジトリ２０１内のユーザＩＤ及び参照情報に基づいて認証するログイン処理を実行する機能。

(f207-2) 認証連携ハンドリング部２０８から認証連携実行要求を受けると、当該認証連携実行要求内のサービスプロバイダＩＤで識別されるサービスプロバイダ装置３００と自装置２００との間で共有する認証連携ＩＤを発行し、この認証連携ＩＤと当該認証連携実行要求内のユーザＩＤとを関連付けて一時記憶部２０５に書き込む機能。

(f207-4) 発行した認証連携ＩＤと、ログイン処理の認証方式名とを含むアサーション本文に対して鍵記憶部２０６内の署名生成鍵に基づくデジタル署名を生成し、図７に示すように、当該アサーション本文と当該デジタル署名とを含む認証アサーション２０７ａを作成する機能。

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

認証連携ハンドリング部２０８は、サービスプロバイダ装置３００からの認証連携要求を受信した後、ポリシ評価処理とアカウント連携処理とＩＤプロバイダ認証連携処理で構成される一連の処理をハンドリングする。認証連携ハンドリング部２０８は、具体的には例えば、以下の機能(f208-1)〜(f208-5)をもっている。

(f208-1) いずれかのサービスプロバイダ装置３００から送信されて当該サービスプロバイダ装置３００のサービスプロバイダＩＤとユーザ端末１００のアドレス情報とを含む認証連携要求を受けると、当該認証連携要求内のユーザ端末１００のアドレス情報を含むユーザ認証要求をＩｄＰ認証連携部２０７に送出する機能。

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

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

(f208-4) 送出されたアカウント連携応答内の登録完了に含まれるサービスプロバイダＩＤ及びユーザＩＤに基づいて、サービス利用状況ストア２０２内のサービス利用状況をサービス未利用からサービス利用中に更新する機能。

(f208-5) ＩｄＰアカウントプロビジョニング部２１０から送出されたアカウント連携応答内の登録完了に含まれるサービスプロバイダＩＤ及びユーザＩＤを含む認証連携実行要求をＩｄＰ認証連携部２０７に送出する機能。

認証連携ポリシ評価部２０９は、認証連携ハンドリング部２０８からのポリシ評価要求を受けて、事前に定義された認証連携ポリシ２０３ａとサービス利用状況に基づいてポリシ評価を行う。認証連携ポリシ評価部２０９は、具体的には例えば、以下の機能(f209-1)〜(f209-4)をもっている。

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

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

(f209-3) 読み出した認証連携ポリシ２０３ａに示される所属及び役職に対し、当該読み出したユーザ属性情報２０１ａ内の所属及び役職が適合するか否かに応じて、サービスデータの送信を許可するか否かを判定する送信許可判定機能。

(f209-4) この判定結果を含むポリシ評価応答をポリシ評価要求の送信元の認証連携ハンドリング部２０８に送出する機能。

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

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

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

(f210-3) 取得したユーザ属性部分情報にアカウント登録指示を付加してアカウント連携要求メッセージを作成する機能。

(f210-4) アカウント連携要求メッセージを認証連携要求の送信元のサービスプロバイダ装置３００に送信する機能。

(f210-5) アカウント連携要求メッセージの送信先のサービスプロバイダ装置３００から当該サービスプロバイダ装置のサービスプロバイダＩＤとユーザ属性部分情報内のユーザＩＤとを含む登録完了が通知されると、当該登録完了を示すアカウント連携応答を認証連携ハンドリング部２０８に送出する機能。

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

信頼ＩｄＰストア３０１は、図８に示すように、ＩＤプロバイダ装置２００を識別するＩＤプロバイダＩＤのリストからなるＩｄＰリスト（ＩＤプロバイダリスト）３０１ａを記憶する。

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

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

利用状況ストア３０４は、図１１に示すように、ユーザ利用管理テーブル３０４ａと、利用数管理テーブル３０４ｂとを記憶している。ユーザ利用管理テーブル３０４ａは、ユーザＩＤと、サービスデータ３０３ａの送信が許可された場合を示すサービス利用中、又はサービスデータ３０３ａの送信が許可されていない場合を示すサービス未利用のいずれかを示すサービス利用状況とを関連付けて書き込まれる。利用数管理テーブル３０４ｂは、ユーザ管理テーブル内のサービス利用状況が示すサービス利用中の個数を示す利用数と、利用数の上限値とを関連付けて書き込まれる。

一時記憶部３０５は、ＲＡＭ等のような一時的なメモリであり、図１２に示すように、例えば、認証アサーション２０７ａから抽出した認証連携ＩＤと、登録されたユーザ属性部分情報３０２ａ内のユーザＩＤと、発行された認証トークンとを関連付けて記憶する。

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

ＳＰ認証連携部３０７は、シングルサインオンのサービスプロバイダ機能を有する。ＳＰ認証連携部３０７は、具体的には例えば、以下の機能(f307-1)〜(f307-5)をもっている。

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

(f307-2) ＩＤプロバイダ装置２００から認証連携応答を受けると、当該認証連携応答内の認証アサーション２０７ａから認証連携ＩＤを抽出し、当該抽出した認証連携ＩＤと、登録されたユーザ属性部分情報３０２ａ内のユーザＩＤとを関連付けて一時記憶部３０５に書き込む機能。

(f307-3) 検証ポリシストア３０６内の認証アサーション検証ポリシ内の認証方式名と署名検証鍵とに基づいて、当該認証アサーション２０７ａ内の認証方式名とデジタル署名とをそれぞれ検証する検証機能。

(f307-4) 検証した結果がいずれも正当のとき、認証トークンを発行し、この認証トークンを認証連携ＩＤに関連付けて一時記憶部３０５に書き込む機能。

(f307-5) 書き込まれた認証トークンと、当該認証トークンに一時記憶部３０５内で認証連携ＩＤを介して関連付けられたユーザＩＤとを含むサービス実行要求をサービスデータ通信部３１０に送出する機能。

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

ＳＰアカウントプロビジョニング部３０９は、ＩＤプロバイダ装置２００のＩｄＰアカウントプロビジョニング部２１０から受けたアカウントプロビジョニング要求（アカウント連携要求メッセージ）に基づき、ＳＰユーザリポジトリ３０２に対してアカウントプロビジョニングを行う。ＳＰアカウントプロビジョニング部３０９は、具体的には例えば、以下の機能(f309-1)〜(f309-2)をもっている。

(f309-1) ＩＤプロバイダ装置２００のＩｄＰアカウントプロビジョニング部２１０からアカウント連携要求メッセージを受信すると、新規のＳＰ側ユーザＩＤを発行し、当該発行したＳＰ側ユーザＩＤと、当該アカウント連携要求メッセージ内のユーザ属性部分情報３０２ａとを関連付けてＳＰユーザリポジトリ３０２に登録する機能。

(f309-2) この登録の後、登録したユーザ属性部分情報３０２ａ内のユーザＩＤと自装置３００のサービスプロバイダＩＤとを含む登録完了をアカウント連携要求メッセージの送信元のＩＤプロバイダ装置２００に通知する機能。

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

次に、以上のように構成された認証連携システムの動作について図１４乃至図２２を参照して説明する。以下の説明は、ＩＤプロバイダ装置２００とサービスプロバイダ装置３００間でＳＳＯが可能なシステム環境にあり、且つＩＤプロバイダ側の組織に所属するユーザが当該サービスプロバイダ装置３００にアカウントが登録されてない状態から開始される。また、この状態において、ユーザがサービス要求をした時に、ＩＤプロバイダ装置２００が認証連携ポリシ２０３ａを満たすか否かを判定し、満たす場合にサービスプロバイダ装置３００側へのユーザのアカウント登録を行うことにより、ＩＤプロバイダ装置２００とサービスプロバイダ装置３００間のＳＳＯが実行され、サービスプロバイダ装置３００からサービスデータ３０３ａが送信される典型的な処理を例に挙げて述べる。

以降、図１４に示す如き、ステップＳＴ１０のユーザ認証（ＳＴ１１〜ＳＴ１８）、ステップＳＴ２０の認証連携ポリシ評価（ＳＴ２１〜ＳＴ２７）、ステップＳＴ３０のアカウント連携（ＳＴ３１〜ＳＴ３７）及びステップＳＴ４０の認証連携（ＳＴ４１〜ＳＴ４９）に分けて説明する。

ステップＳＴ１０のユーザ認証の処理においては、ＩＤプロバイダ側の組織に所属するユーザが、ユーザのアカウントがサービスプロバイダ装置３００に未登録の状態で、ユーザ端末１００からサービス要求をサービスプロバイダ装置３００に送信し、ＩＤプロバイダ装置２００がサービスプロバイダ装置３００に代わってユーザの認証を行う。以下、図１５のシーケンス図及び図１６の模式図を用いて述べる。

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

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

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

一方、判定の結果、サービス要求が認証トークンを含まない場合には、ステップＳＴ１３を実行する。なお、後述するようにステップＳＴ１３，ＳＴ１４が省略される場合にはステップＳＴ１５を実行する。

ステップＳＴ１３では、ＳＰ認証連携部３０７は、ユーザが所属するＩＤプロバイダを当該ユーザに選択させるため、事前に信頼関係を確立したＩＤプロバイダを示すＩＤプロバイダＩＤを列挙したＩｄＰリスト３０１ａを信頼ＩｄＰストア３０１から読み出してユーザ端末１００に送信する。なお、ＩｄＰリスト３０１ａはＩＤプロバイダリストと呼んでもよい。

ステップＳＴ１４では、ユーザ端末１００は、サービスプロバイダ装置３００から受信したＩｄＰリスト３０１ａを表示し、ユーザに対して、自身が所属するＩＤプロバイダの選択を促す。しかる後、ユーザ端末１００は、ユーザの操作により、選択されたＩＤプロバイダＩＤをサービスプロバイダ装置３００に送信する。なお、サービス要求がＩＤプロバイダの指定を含む場合や、サービスプロバイダ装置３００が一つのＩＤプロバイダのＩＤプロバイダ装置２００としか連携しない場合などのように、ＩＤプロバイダの選択が不要な場合には、ステップＳＴ１３〜ＳＴ１４が省略される。

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

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

ステップＳＴ１７では、ＩｄＰ認証連携部２０７は、ユーザ認証要求を受けると、このユーザ認証要求に基づいて、ユーザの識別と認証のためのログイン処理を実行する。このログイン処理においては、ＩｄＰ認証連携部２０７は、送出されたユーザ認証要求内のユーザ端末１００のアドレス情報に基づいて、当該ユーザ端末１００にログイン要求を送信し、当該ユーザ端末１００から受けたユーザＩＤ及びユーザ認証情報をＩｄＰユーザリポジトリ２０１内のユーザＩＤ及び参照情報に基づいて認証する。

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

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

ステップＳＴ２０の認証連携ポリシ評価においては、ユーザ認証終了後、サービス利用状況やユーザ属性情報２０１ａ、認証連携ポリシ２０３ａを入力値として、認証連携ポリシ評価を行い、ユーザのサービス要求に対して許可を下す。以下、図１７のシーケンス図及び図１８の模式図を用いて述べる。

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

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

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

ここで、サービス利用状況ストア２０２は、図３に示すような２つの情報群を管理している。例えば、図３の上段に示すように、ユーザ単位でＩＤプロバイダ装置２００が連携する単一もしくは複数のサービスプロバイダ装置３００に関する利用状況の情報が記憶されている。例えば、図１０のユーザＩＤがuser_0020のレコードについては、ＳＰ（１）はサービス未利用の状態、ＳＰ（２）はサービス利用中、ＳＰ（３）はサービス一時停止中、ＳＰ（Ｎ）はサービス利用終了の状態を表している。また、図３の下段に示すように、サービスプロバイダ装置３００単位で、それぞれのサービスプロバイダ装置３００を利用するユーザ数、およびそのサービスプロバイダ装置３００を利用できるユーザ数の上限値が記憶されている。

以降、本実施形態では、図３を使って、ユーザＩＤはuser_0001、ユーザが要求するサービスプロバイダ装置３００はＳＰ（１）と仮定する。

ステップＳＴ２３では、認証連携ポリシ評価部２０９は、ポリシ評価要求内のユーザＩＤに基づいて、利用状況提供部３０８から、サービスプロバイダ装置３００が管理するユーザの利用状況を取得する。

ただし、ステップＳＴ２３は、ユーザが希望するサービスプロバイダ装置３００以外に、本実施形態のような他の全サービスプロバイダ装置３００の利用状況がサービス未利用のケースでは実行されない。図３によると、ユーザＩＤがuser_0001のレコードがこれに該当する。

ステップＳＴ２３が実行されるケースは、図３のユーザＩＤが、user_0020とuser_1000である。このようなケースが起こる状況は、認証連携ポリシ２０３ａの評価指標として、ＩＤプロバイダ側でなく、他のサービスプロバイダ装置３００側で管理する情報も含めたいときである。他のサービスプロバイダ装置３００側で管理する情報の一例としては、ユーザがサービス利用時に課される費用、つまり従量制課金がある。このように、時間に応じてに変化する情報をも認証連携ポリシ２０３ａの評価指標として含めることで、ユーザのサービス利用に関してダイナミックなアクセス制御（＝動的なポリシ評価）が可能となる。なお、ダイナミックなアクセス制御を実行する場合には、前述した従量制課金に限らず、例えば、サービスの現在の利用数とその上限値とを管理してもよい。

ステップＳＴ２４では、認証連携ポリシ評価部２０９は、ポリシ評価要求内のユーザＩＤに基づいてＩｄＰユーザリポジトリ２０１からユーザ属性情報２０１ａを読み出す。本実施形態では、図２に示すようなユーザの属性情報となる。

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

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

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

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

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

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

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

認証連携ポリシ２０３ａＡの［４］：認証連携ポリシ２０３ａは、利用中のアカウント数が上限値を超えないことを示す。これに対し、図３に示すように、当該サービスの利用数が１０であり、上限値１００を超えていない。従って、認証連携ポリシ２０３ａにおける［４］の条件を満たす。

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

ステップＳＴ２７では、認証連携ポリシ評価部２０９は、ステップＳＴ２６の判定結果からなるポリシ評価結果をポリシ評価応答として、認証連携ハンドリング部２０８に送出する。

以上により、ステップＳＴ２０の認証連携ポリシ評価（ＳＴ２１〜ＳＴ２７）が終了する。

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

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

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

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

ステップＳＴ３４では、ＩｄＰアカウントプロビジョニング部２１０は、取得したユーザ属性部分情報にアカウント登録指示を付加してアカウント連携要求メッセージを作成する。例えば、ＩｄＰアカウントプロビジョニング部２１０は、ＳＰアカウントプロビジョニング部３０９が公開する操作インタフェースに基づき、ＳＰユーザリポジトリ３０２の操作の種類と、その操作が対象とするステップＳＴ３３で取得したユーザ属性部分情報を対応付けて、ＳＰアカウント連携要求メッセージを作成する。なお、本実施形態では、サービスプロバイダ装置３００側にユーザのアカウントが登録されてないため、操作の種類としてアカウント登録を指定する。

ステップＳＴ３５では、ＩｄＰアカウントプロビジョニング部２１０は、作成したＳＰアカウント連携要求メッセージを、認証連携要求の送信元のサービスプロバイダ装置３００に送信する。ＳＰアカウント連携要求メッセージは、サービスプロバイダ装置３００内のＳＰアカウントプロビジョニング部３０９に受信される。

ステップＳＴ３６では、ＳＰアカウントプロビジョニング部３０９は、受信したＳＰアカウント連携要求メッセージに基づき、ＳＰ側ユーザＩＤ（サービスプロバイダ装置３００側のユーザＩＤ）を新規発行し、当該ＳＰ側ユーザＩＤと、アカウント連携要求メッセージ内のユーザ属性部分情報３０２ａとを関連付けてＳＰユーザリポジトリ３０２に登録する。登録後、ＳＰアカウントプロビジョニング部３０９は、登録したユーザ属性部分情報３０２ａ内のユーザＩＤと自装置のサービスプロバイダＩＤとを含む登録完了をアカウント連携要求メッセージの送信元のＩＤプロバイダ装置２００に通知する。具体的には、登録完了は、ＩＤプロバイダ装置２００内のＩｄＰアカウントプロビジョニング部２１０に通知される。

ステップＳＴ３７では、ＩｄＰアカウントプロビジョニング部２１０は、登録完了が通知されると、当該登録完了を示すアカウント連携応答を認証連携ハンドリング部２０８に送出する。

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

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

ステップＳＴ４１では、認証連携ハンドリング部２０８は、ステップＳＴ３７にて通知されたアカウント連携応答に含まれる結果を解析する。その結果に問題がなければ、認証連携ハンドリング部２０８は、送出されたアカウント連携応答内の登録完了に含まれるサービスプロバイダＩＤ及びユーザＩＤに基づいて、サービス利用状況ストア２０２内のサービス利用状況をサービス未利用からサービス利用中に更新する。これにより、サービス利用状況ストア２０２において、当該ユーザが要求したサービスプロバイダ装置３００の利用状況がサービス未利用の状態からサービス利用中の状態に変更される。

ステップＳＴ４２では、認証連携ハンドリング部２０８は、アカウント連携応答内の登録完了に含まれるサービスプロバイダＩＤ及びユーザＩＤを含む認証連携実行要求をＩｄＰ認証連携部２０７に送出する。

ステップＳＴ４３では、ＩｄＰ認証連携部２０７は、認証連携実行要求を受けると、当該認証連携実行要求内のサービスプロバイダＩＤで識別されるサービスプロバイダ装置３００と自装置２００との間で共有する認証連携ＩＤを発行し、この認証連携ＩＤと当該認証連携実行要求内のユーザＩＤとを関連付けて一時記憶部２０５に書き込む。

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

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

ステップＳＴ４６では、ＳＰ認証連携部３０７は、認証連携応答を受けると、当該認証連携応答内の認証アサーション２０７ａから認証連携ＩＤを抽出し、当該抽出した認証連携ＩＤと、ステップＳＴ３６でＳＰユーザリポジトリ３０２に登録されたユーザ属性部分情報３０２ａ内のユーザＩＤとを関連付けて一時記憶部３０５に書き込む。

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

ステップＳＴ４８では、ＳＰ認証連携部３０７は、ステップＳＴ４７で許可と決定されたとき、認証トークンを発行し、この認証トークンを認証連携ＩＤに関連付けて一時記憶部３０５に書き込む。

ステップＳＴ４９では、ＳＰ認証連携部３０７は、書き込まれた認証トークンと、当該認証トークンに一時記憶部３０５内で認証連携ＩＤを介して関連付けられたユーザＩＤとを含むサービス実行要求をサービスデータ通信部３１０に送出する。サービスデータ通信部３１０は、送出されたサービス実行要求に基づいて、当該サービス実行要求内の認証トークンとサービスデータストア３０３内のサービスデータ３０３ａとをユーザ端末１００に送信する。

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

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

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

＜第２の実施形態＞
次に、第２の実施形態について前述した図面を参照しながら説明する。

第２の実施形態は、第１の実施形態のステップＳＴ２３を実行する場合の具体例である。ここでは、サービス要求を送信したユーザ端末１００のユーザが、既に他の様々なサービスプロバイダを利用している状況下にあって、別のサービスプロバイダを新規利用する場合を例に挙げて述べる。

この場合、第１の実施形態のステップＳＴ２３において、ユーザが利用中の各サービスプロバイダの利用料金を認証連携ポリシ評価の指標として利用し、認証連携ポリシ２０３ａに対して、利用料金の上限値を事前に定義することで（例、図４のＣの［４］）、別のサービスプロバイダの新規利用を拒否可能としている。

これに伴い、サービスプロバイダ装置３００の利用状況ストア３０４は、図２３に示すように、ユーザ利用管理テーブル３０４ａにおいて、ユーザＩＤと、サービス利用中の状態に対して累積した利用料金とを関連付けて記憶する。

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

一方、ＩＤプロバイダ装置２００においては、認証連携ポリシストア２０３内の各認証連携ポリシ２０３ａのうちのいずれかの認証連携ポリシ２０３ａは、サービスプロバイダＩＤに関連付けて、当該サービスプロバイダＩＤで識別されるサービスプロバイダ装置３００によるサービスデータ３０３ａの送信が許可されるユーザの所属及び役職と、当該ユーザの利用料金の上限値（例、図４のＣの［４］）とを示している。

また、認証連携ポリシ評価部２０９は、認証連携ハンドリング部２０８から送出されたポリシ評価要求内のユーザＩＤとサービスプロバイダＩＤとに基づいて、当該サービスプロバイダＩＤで識別されるサービスプロバイダ装置３００に対し、当該ユーザＩＤを含む利用料金送信要求を送信し、当該サービスプロバイダ装置３００から当該ユーザＩＤ及び利用料金を含む利用料金応答を受信する機能を更に備えている。なお、受信した利用料金は、図２４に示すように、ユーザＩＤとサービスプロバイダＩＤとに関連付けてサービス状況ストア２０２内のユーザ利用管理テーブル２０２ａに書き込んでもよいが、必ずしも書き込まなくてもよい。

また、認証連携ポリシ評価部２０９の前述した送信許可判定機能は、認証連携ポリシストア２０３から読み出した認証連携ポリシ２０３ａにユーザの所属及び役職と利用料金の上限値とが含まれる場合、読み出したポリシ情報に示される所属及び役職に対してＩｄＰユーザリポジトリ２０１から読み出したユーザ属性情報２０１ａ内の所属及び役職が適合するか否かと、当該読み出したポリシ情報に示される利用料金の上限値に対してサービスプロバイダ装置３００から受信した利用料金応答内の利用料金が適合するか否かとに応じて、サービスデータ３０３ａの送信を許可するか否かを判定する機能となっている。

ここで、本明細書においては、上述したような読み出したポリシ情報に示される所属及び役職には限られず、読み出したポリシ情報に対して、読み出したユーザ属性情報、ユーザが利用したいサービスの種類、ユーザが行いたいサービスへの操作、サービスを実行するに際してのユーザの環境条件に適合するか否かと、当該読み出したポリシ情報に示される利用料金の上限値に対して、受信した利用料金応答内の利用料金が適合するか否かとに応じて、サービスデータ３０３ａの送信を許可するか否かを判定しても良い。

次に、以上のように構成された認証連携システムの動作について前述した図１７を主に参照して説明する。

今、ステップＳＴ１０のユーザ認証（ＳＴ１１〜ＳＴ１８）は、前述した通りに実行される。

続いて、ステップＳＴ２０の認証連携ポリシ評価においては、ステップＳＴ２１（ポリシ評価要求）及びステップＳＴ２２（サービス利用状況の検索）が前述した通りに実行される。

ステップＳＴ２３では、認証連携ポリシ評価部２０９は、認証連携ハンドリング部２０８から送出されたポリシ評価要求内のユーザＩＤとサービスプロバイダＩＤとに基づいて、当該サービスプロバイダＩＤで識別されるサービスプロバイダ装置３００に対し、当該ユーザＩＤを含む利用料金送信要求を送信する。

サービスプロバイダ装置３００の利用状況提供部３０８は、この利用料金送信要求内のユーザＩＤに基づいて利用状況ストア３０４を検索し、当該検索により得られた利用料金及び当該ユーザＩＤを含む利用料金応答を当該ＩＤプロバイダ装置２００に送信する。

ＩＤプロバイダ装置２００の認証連携ポリシ評価部２０９は、この利用料金応答を受信する。

次に、ステップＳＴ２４（ユーザ属性情報２０１ａの検索）及びステップＳＴ２５（認証連携ポリシ２０３ａの検索）が前述同様に実行される。但し、認証連携ポリシ２０３ａは、利用料金の上限値を含んでいるものとする。

ステップＳＴ２６では、認証連携ポリシ評価部２０９は、認証連携ポリシストア２０３から読み出した認証連携ポリシ２０３ａにユーザの所属及び役職と利用料金の上限値とが含まれる場合、読み出したポリシ情報に示される所属及び役職に対してＩｄＰユーザリポジトリ２０１から読み出したユーザ属性情報２０１ａ内の所属及び役職が適合するか否かと、当該読み出したポリシ情報に示される利用料金の上限値に対してサービスプロバイダ装置３００から受信した利用料金応答内の利用料金が適合するか否かとに応じて、サービスデータ３０３ａの送信を許可するか否かを判定する。

以降のステップＳＴ２７（ポリシ評価応答）、ステップＳＴ３０のアカウント連携（ＳＴ３１〜ＳＴ３７）及びステップＳＴ４０の認証連携（ＳＴ４１〜ＳＴ４９）の処理は、前述した通りに実行される。

上述したように本実施形態によれば、第１の実施形態の効果に加え、ユーザの利用料金にも応じて、サービスデータ送信の可否を判定することができる。

従って、認証連携ポリシ２０３ａを導入し、ＩＤプロバイダ装置２００やサービスプロバイダ装置３００側で管理する動的に変化するサービス利用状況も、ユーザ単位でなく、ＩＤプロバイダ単位で取り扱うことで、厳密な認証連携およびサービス利用の制御が可能となる。

補足すると、第１の実施形態においてスムーズなサービス利用が可能になることで利便性が向上する反面、企業などの営利組織にとって無駄なサービス利用は好ましくない。従って、ユーザや組織レベルでのサービス利用状況に応じて、ダイナミック且つ柔軟に利用管理をコントロールする仕組みを備えていることが望ましい。本実施形態及び第３の実施形態はこのような仕組みを備えた認証連携システムを実現することができる。

＜第３の実施形態＞
次に、第３の実施形態について前述した図面を参照しながら説明する。

第３の実施形態は、第１の実施形態のステップＳＴ２３を実行する場合の他の具体例である。ここでは、サービスプロバイダ装置３００では、サービスを利用するユーザの数が上限値にある状況において、新たにサービス要求を受けた場合を例に挙げて述べる。

すなわち、サービスプロバイダの利用数を認証連携ポリシ評価の指標として利用し、認証連携ポリシ２０３ａに対して、利用数が上限値を超過した場合の追加条件を事前に定義しておく（図４のＢの［４］）。事前に定義する追加条件には、ＩＤプロバイダ装置２００内で管理する遊休状態のユーザが存在すれば、サービスプロバイダ装置３００内で管理する遊休状態ユーザのアカウントを削除もしくは無効化し、新規ユーザのアカウント登録の責務条件を定義する（図４のＢの［４］の［責務条件］）。このように、利用数が上限を超えた場合に、遊休ユーザのアカウントを無効化して空いた枠を申請ユーザのアカウントに割り当てる旨の責務条件を備えた認証連携ポリシ２０３ａにより、利用数が上限を超えた場合でも、ＩＤプロバイダ内の利用状況に合わせて、必要に応じた素早いサービス利用が開始可能となっている。

換言すると、認証連携ポリシストア２０３内の各認証連携ポリシ２０３ａのうちのいずれかの認証連携ポリシ２０３ａは、サービスプロバイダＩＤに関連付けて、当該サービスプロバイダＩＤで識別されるサービスプロバイダ装置３００によるサービスデータ３０３ａの送信が許可されるユーザの所属及び役職と、当該ユーザの人数が上限値を超えた場合には当該ユーザの中で最終利用日から現在までの期間が所定期間以上であるユーザが存在することと、当該存在するユーザのユーザ属性部分情報３０２ａを無効化すること（例、図４のＢの［４］）とを示している。なお、ここでいう「ユーザの人数」は、サービス利用状況ストア２０２内の「現在の利用数」に等しい値を意味している。

これに伴い、サービスプロバイダ装置３００の利用状況ストア３０４は、図２５に示すように、ユーザ利用管理テーブル３０４ａにおいて、前述した記憶内容に加え、ユーザＩＤと、サービスデータ３０３ａを送信した最終の日付を示す最終利用日とを含む最終利用日情報とを記憶する。

また、利用状況提供部３０８は、ＩＤプロバイダ装置２００から最終利用日送信要求を受けると、利用状況ストア３０４内の最終利用日情報を当該ＩＤプロバイダ装置２００に送信する機能をもっている。
一方、ＩＤプロバイダ装置２００の認証連携ポリシ評価部２０９は、前述した機能に加え、認証連携ハンドリング部２０８から送出されたポリシ評価要求内のサービスプロバイダＩＤに基づいてサービス利用状況ストア２０２から利用数及び上限値を読み出す機能と、当該送出されたポリシ評価要求内のサービスプロバイダＩＤに基づいて、当該サービスプロバイダＩＤで識別されるサービスプロバイダ装置３００に対し、最終利用日送信要求を送信し、当該サービスプロバイダ装置３００から最終利用日情報を受信する機能とをもっている。なお、受信した最終利用日情報は、図２６に示すように、ユーザＩＤとサービスプロバイダＩＤとに関連付けてサービス状況ストア２０２内のユーザ利用管理テーブル２０２ａに書き込んでもよいが、必ずしも書き込まなくてもよい。

また、認証連携ポリシ評価部２０９の前述した送信許可判定機能は、認証連携ポリシストア２０３から読み出した認証連携ポリシ２０３ａにユーザの所属及び役職と利用数の上限値を超えた場合に所定期間以上であるユーザが存在することと当該存在するユーザのユーザ属性部分情報３０２ａを無効化することとが含まれる場合、当該読み出した認証連携ポリシ２０３ａに示される所属及び役職に対してＩｄＰユーザリポジトリ２０１から読み出したユーザ属性情報２０１ａ内の所属及び役職が適合するか否かと、サービス利用状況ストア２０２から読み出した利用数が当該サービス利用状況ストア２０２から読み出した上限値を超えた場合に最終利用日送信要求をサービスプロバイダ装置２００に送信して当該サービスプロバイダ装置２００から受けた最終利用日情報内の最終利用日が読み出した認証連携ポリシ２０３ａ内の所定期間以上に適合するか否かとに応じてサービスデータ３０３ａの送信を許可するか否かを判定する機能とをもっている。

次に、以上のように構成された認証連携システムの動作について前述した図１７を主に参照して説明する。

今、ステップＳＴ１０のユーザ認証（ＳＴ１１〜ＳＴ１８）は、前述した通りに実行される。

続いて、ステップＳＴ２０の認証連携ポリシ評価においては、ステップＳＴ２１（ポリシ評価要求）及びステップＳＴ２２（サービス利用状況の検索）が前述同様に実行される。このステップＳＴ２２では、ポリシ評価要求内のサービスプロバイダＩＤに基づいてサービス利用状況ストア２０２から利用数及び上限値が読み出される。

ステップＳＴ２３では、認証連携ポリシ評価部２０９は、認証連携ハンドリング部２０８から送出されたポリシ評価要求内のユーザＩＤとサービスプロバイダＩＤとに基づいて、当該サービスプロバイダＩＤで識別されるサービスプロバイダ装置３００に対し、最終利用日送信要求を送信する。

サービスプロバイダ装置３００の利用状況提供部３０８は、この最終利用日送信要求を受けると、利用状況ストア３０４内の最終利用日情報をＩＤプロバイダ装置２００に送信する。

ＩＤプロバイダ装置２００の認証連携ポリシ評価部２０９は、この最終利用日情報を受信する。

次に、ステップＳＴ２４（ユーザ属性情報２０１ａの検索）及びステップＳＴ２５（認証連携ポリシ２０３ａの検索）が前述同様に実行される。但し、認証連携ポリシ２０３ａは、サービスプロバイダＩＤに関連付けて、当該サービスプロバイダＩＤで識別されるサービスプロバイダ装置３００によるサービスデータ３０３ａの送信が許可されるユーザの所属及び役職と、当該ユーザの人数が上限値を超えた場合には当該ユーザの中で最終利用日から現在までの期間が所定期間以上であるユーザが存在することと、当該存在するユーザのユーザ属性部分情報３０２ａを無効化すること（例、図４のＢの［４］）とを示しているものとする。

ステップＳＴ２６では、認証連携ポリシ評価部２０９が、図４の２０３ａＢで示す認証連携ポリシに基づいて、連携の可否を決定する。認証連携ポリシストア２０３から読み出した認証連携ポリシ２０３ａにユーザの所属及び役職と利用数の上限値を超えた場合に所定期間以上であるユーザが存在することと当該存在するユーザのユーザ属性部分情報３０２ａを無効化することとが含まれる場合、当該読み出した認証連携ポリシ２０３ａに示される所属及び役職に対してＩｄＰユーザリポジトリ２０１から読み出したユーザ属性情報２０１ａ内の所属及び役職が適合するか否かと、サービス利用状況ストア２０２から読み出した利用数が当該サービス利用状況ストア２０２から読み出した上限値を超えた場合に最終利用日送信要求をサービスプロバイダ装置２００に送信して当該サービスプロバイダ装置２００から受けた最終利用日情報内の最終利用日が読み出した認証連携ポリシ２０３ａ内の所定期間以上に適合するか否かとに応じてサービスデータ３０３ａの送信を許可するか否かを判定する。

ステップＳＴ２７（ポリシ評価応答）では、認証連携ポリシ評価部２０９が下した許可に加えて、図４の認証連携ポリシ２０３ａにおけるＢ［４］からの「半年以上に渡ってサービス未使用のユーザのＳＰアカウントを無効化する」との責務条件付きの評価結果を、認証連携ポリシ評価部２０９が認証連携ハンドリング部２０８に返す。このとき、無効化対象ユーザのユーザＩＤも当該評価結果には付与される。

以降のステップＳＴ３０のアカウント連携（ＳＴ３１〜ＳＴ３７）及びステップＳＴ４０の認証連携（ＳＴ４１〜ＳＴ４９）の処理は、前述した通りに実行される。なお、本実施形態では、認証連携ポリシの評価結果として条件が含まれるため、ステップＳＴ３３（ユーザ属性情報の検索）とステップＳＴ３４（ＳＰアカウント連携要求メッセージ送信）において、次のような処理が加わる。

まず、ステップＳＴ３３においては、ＩｄＰアカウントプロビジョニング部２１０が、当該ユーザの属性情報に加えて、無効化対象ユーザのアカウントを無効化するために必要な属性情報も検索する。また、ステップＳＴ３４においては、ＩｄＰアカウントプロビジョニング部２１０が、当該ユーザのユーザ属性部分情報とアカウント登録指示に加えて、更に無効化対象ユーザのアカウントを無効化するアカウント更新指示も付加して、アカウント連携要求メッセージを作成する。

上述したように本実施形態によれば、第１の実施形態の効果に加え、利用数が上限を超えた場合に、遊休ユーザのアカウントを無効化して空いた枠を申請ユーザのアカウントに割り当てる旨の責務条件を認証連携ポリシ２０３ａに加えた構成により、利用数が上限を超えた場合でも、ＩＤプロバイダ内の利用状況に合わせて、素早くサービス利用を開始することができる。

以上説明した少なくとも一つの実施形態によれば、サービスプロバイダＩＤ毎に、サービスデータ３０３ａの送信が許可されるユーザの所属及び役職を示す複数の認証連携ポリシ２０３ａを記憶する認証連携ポリシストア２０３と、読み出した認証連携ポリシ２０３ａに示される所属及び役職に対し、読み出したユーザ属性情報２０１ａ内の所属及び役職が適合するか否かに応じて、サービスデータ３０３ａの送信を許可するか否かを判定する認証連携ポリシ評価部２０９とを備えた構成により、ＳＳＯの過程でアカウント登録及び連携を実行する際に、人手を介さずにサービス利用可否を決定することができる。

補足すると、従来のデータ処理システムにおいては、サービスプロバイダがアカウントを登録するための十分な情報を保持していないことを確認し、不足したユーザ属性をＩＤプロバイダに要求する手間がかかり、このような確認や要求に人手を介していた。

一方、少なくとも一つの実施形態では、前述した予め認証連携ポリシ２０３ａを記憶した構成により、従来のような確認や要求に人手を介することがない。

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

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

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

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

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

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

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

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

１００…ユーザ端末、２００…ＩＤプロバイダ装置、２０１…ＩｄＰユーザリポジトリ、２０１ａ…ユーザ属性情報、２０２…サービス利用状況ストア、２０２ａ，３０４ａ…ユーザ利用管理テーブル、２０２ｂ，３０４ｂ…利用数管理テーブル、２０３…認証連携ポリシストア、２０３ａ…認証連携ポリシ、２０４…ＳＰユーザ設定ルールストア、２０４ａ…ユーザ設定ルール、２０５，３０５…一時記憶部、２０６…鍵記憶部、２０７…ＩｄＰ認証連携部、２０７ａ…認証アサーション、２０８…認証連携ハンドリング部、２０９…認証連携ポリシ評価部、２１０…ＩｄＰアカウントプロビジョニング部、３００…サービスプロバイダ装置、３０１…信頼ＩｄＰストア、３０１ａ…ＩｄＰリスト、３０２…ＳＰユーザリポジトリ、３０２ａ…ユーザ属性部分情報、３０３…サービスデータストア、３０３ａ…サービスデータ、３０４…利用状況ストア、３０６…検証ポリシストア、３０７…ＳＰ認証連携部、３０８…利用状況提供部、３０９…ＳＰアカウントプロビジョニング部、３１０…サービスデータ通信部。

Claims (4)

1. ユーザが操作するユーザ端末にログイン処理を実行可能で第１メモリを有するＩＤプロバイダ装置と、前記ログイン処理が成功した場合に前記ユーザ端末にサービスデータを送信可能で第２メモリを有する複数のサービスプロバイダ装置とを備えた認証連携システムであって、
   前記ＩＤプロバイダ装置は、
   前記ユーザを特定するためのユーザ属性の項目名と前記ユーザ属性の項目値とを関連付けたユーザ属性情報であって、少なくとも前記ユーザを識別するユーザＩＤを前記項目名に含む複数の前記ユーザ属性情報を記憶するユーザ属性情報記憶手段と、
   前記ユーザＩＤと、前記各サービスプロバイダ装置を識別するサービスプロバイダＩＤと、前記サービスデータの送信が許可された場合を示すサービス利用中、又は前記サービスデータの送信が許可されていない場合を示すサービス未利用のいずれかを示すサービス利用状況とを関連付けて記憶するサービス利用状況記憶手段と、
   前記サービスプロバイダＩＤ毎に、当該サービスプロバイダＩＤで識別されるサービスプロバイダ装置によるサービスデータの送信が許可される対象となるユーザを示す複数のポリシ情報を記憶するポリシ記憶手段と、
   前記サービスプロバイダＩＤと、前記ユーザ属性情報内のユーザ属性の項目名のうち、一部の項目名とを関連付けて記憶する一部項目名記憶手段と、
   自装置の署名生成鍵を記憶する鍵記憶手段と、
   いずれかの前記サービスプロバイダ装置から送信されて当該サービスプロバイダ装置のサービスプロバイダＩＤと前記ユーザ端末のアドレス情報とを含む認証連携要求を受けると、当該認証連携要求内のユーザ端末のアドレス情報を含むユーザ認証要求を送出する手段と、
   前記送出されたユーザ認証要求内のユーザ端末のアドレス情報に基づいて、当該ユーザ端末にログイン要求を送信し、当該ユーザ端末から受けたユーザＩＤ及びユーザ認証情報を前記ユーザ属性情報記憶手段内のユーザＩＤ及び参照情報に基づいて認証するログイン処理を実行する手段と、
   前記ログイン処理が成功したとき、当該ログイン処理に用いたユーザＩＤと前記認証連携要求内のサービスプロバイダＩＤとを含むポリシ評価要求を送出する手段と、
   前記送出されたポリシ評価要求内のユーザＩＤに基づいて前記ユーザ属性記憶手段からユーザ属性情報を読み出す手段と、
   前記送出されたポリシ評価要求内のサービスプロバイダＩＤに基づいて前記ポリシ記憶手段からポリシ情報を読み出す手段と、
   前記読み出したポリシ情報に対して、前記読み出したユーザ属性情報、ユーザが利用したいサービスの種類、ユーザが行いたいサービスへの操作、サービスを実行するに際してのユーザの環境条件に適合するか否かに応じて、前記サービスデータの送信を許可するか否かを判定する送信許可判定手段と、
   この判定結果を含むポリシ評価応答を前記ポリシ評価要求の送信元に送出する手段と、
   前記ポリシ評価応答内の判定結果が許可を示す場合、前記ポリシ評価要求内のユーザＩＤとサービスプロバイダＩＤとを含むアカウント連携要求を送出する手段と、
   前記送出されたアカウント連携要求内のサービスプロバイダＩＤに基づいて、前記一部項目名記憶手段からユーザ属性の一部の項目名を読み出す手段と、
   当該読み出した一部の項目名と前記アカウント連携要求内のユーザＩＤとに基づいて、前記ユーザ属性記憶手段内で当該ユーザＩＤに一致するユーザＩＤを含むユーザ属性情報のうち、当該一部の項目名に一致する項目名及びこの項目名に関連付けられた項目値からなるユーザ属性部分情報を取得する手段と、
   前記取得したユーザ属性部分情報にアカウント登録指示を付加してアカウント連携要求メッセージを作成する手段と、
   前記アカウント連携要求メッセージを前記認証連携要求の送信元のサービスプロバイダ装置に送信する手段と、
   前記アカウント連携要求メッセージの送信先のサービスプロバイダ装置から当該サービスプロバイダ装置のサービスプロバイダＩＤと前記ユーザ属性部分情報内のユーザＩＤとを含む登録完了が通知されると、当該登録完了を示すアカウント連携応答を送出する手段と、
   前記送出されたアカウント連携応答内の登録完了に含まれるサービスプロバイダＩＤ及びユーザＩＤに基づいて、前記サービス利用状況記憶手段内のサービス利用状況をサービス未利用からサービス利用中に更新する手段と、
   前記送出されたアカウント連携応答内の登録完了に含まれるサービスプロバイダＩＤ及びユーザＩＤを含む認証連携実行要求を送出する手段と、
   前記認証連携実行要求を受けると、当該認証連携実行要求内のサービスプロバイダＩＤで識別されるサービスプロバイダ装置と自装置との間で共有する認証連携ＩＤを発行し、この認証連携ＩＤと当該認証連携実行要求内のユーザＩＤとを関連付けて前記第１メモリに書き込む手段と、
   前記発行した認証連携ＩＤと、前記ログイン処理の認証方式名とを含むアサーション本文に対して前記署名生成鍵に基づくデジタル署名を生成し、当該アサーション本文と当該デジタル署名とを含む認証アサーションを作成する手段と、
   前記作成した認証アサーションを含む認証連携応答を前記認証連携要求の送信元のサービスプロバイダ装置に送信する手段と
   を備え、
   前記各サービスプロバイダ装置は、
   前記ユーザ属性情報記憶手段内のユーザ属性情報内のユーザ属性の項目名及び項目値のうちの一部の項目名と項目値とを関連付けたユーザ属性部分情報と、自装置内でユーザを識別するＳＰ側ユーザＩＤとを関連付けて記憶するユーザ属性部分情報記憶手段と、
   前記ログイン処理が成功した場合にサービスデータの送信を許可するログイン処理の認証方式名と、前記署名生成鍵に対応する署名検証鍵とを含む認証アサーション検証ポリシを記憶する検証ポリシ記憶手段と、
   前記サービスデータを記憶するサービスデータ記憶手段と、
   前記ユーザ端末からサービス要求を受けると、当該サービス要求が認証トークンを含むか否かを判定し、前記認証トークンを含む場合には当該認証トークンと前記サービスデータ記憶手段内のサービスデータとを当該ユーザ端末に送信し、否の場合には自装置のサービスプロバイダＩＤと当該ユーザ端末のアドレス情報とを含む認証連携要求を前記ＩＤプロバイダ装置に送信する手段と、
   前記アカウント連携要求メッセージを受信すると、新規の前記ＳＰ側ユーザＩＤを発行し、当該発行したＳＰ側ユーザＩＤと、当該アカウント連携要求メッセージ内のユーザ属性部分情報とを関連付けて前記ユーザ属性部分情報記憶手段に登録する手段と、
   この登録の後、登録したユーザ属性部分情報内のユーザＩＤと自装置のサービスプロバイダＩＤとを含む登録完了を前記アカウント連携要求メッセージの送信元のＩＤプロバイダ装置に通知する手段と、
   前記ＩＤプロバイダ装置から認証連携応答を受けると、当該認証連携応答内の認証アサーションから認証連携ＩＤを抽出し、当該抽出した認証連携ＩＤと、前記登録されたユーザ属性部分情報内のユーザＩＤとを関連付けて前記第２メモリに書き込む手段と、
   前記認証アサーション検証ポリシ内の認証方式名と署名検証鍵とに基づいて、前記認証アサーション内の認証方式名とデジタル署名とをそれぞれ検証する検証手段と、
   前記検証した結果がいずれも正当のとき、認証トークンを発行し、この認証トークンを前記認証連携ＩＤに関連付けて前記第２メモリに書き込む手段と、
   前記書き込まれた認証トークンと、当該認証トークンに前記第２メモリ内で前記認証連携ＩＤを介して関連付けられたユーザＩＤとを含むサービス実行要求を送出する手段と、
   前記送出されたサービス実行要求に基づいて、当該サービス実行要求内の認証トークンと前記サービスデータ記憶手段内のサービスデータとを前記ユーザ端末に送信する手段と
   を備えたことを特徴とする認証連携システム。
2. 請求項１に記載の認証連携システムにおいて、
   前記各サービスプロバイダ装置は、
   前記ユーザＩＤと、前記サービス利用中の状態に対して累積した利用料金とを関連付けて記憶する利用料金記憶手段と、
   前記ＩＤプロバイダ装置からユーザＩＤを含む利用料金送信要求を受けると、この利用料金送信要求内のユーザＩＤに基づいて前記利用料金記憶手段を検索し、当該検索により得られた利用料金及び当該ユーザＩＤを含む利用料金応答を当該ＩＤプロバイダ装置に送信する手段と
   を更に備え、
   前記ＩＤプロバイダ装置は、
   前記各ポリシ情報のうちのいずれかのポリシ情報は、前記サービスプロバイダＩＤに関連付けて、当該サービスプロバイダＩＤで識別されるサービスプロバイダ装置によるサービスデータの送信が許可される対象となるユーザの環境条件と、当該ユーザの利用料金の上限値とを示しており、
   前記送出されたポリシ評価要求内のユーザＩＤとサービスプロバイダＩＤとに基づいて、当該サービスプロバイダＩＤで識別されるサービスプロバイダ装置に対し、当該ユーザＩＤを含む利用料金送信要求を送信し、当該サービスプロバイダ装置から当該ユーザＩＤ及び利用料金を含む利用料金応答を受信する手段と
   を更に備え、
   前記送信許可判定手段は、前記読み出したポリシ情報に対して前記読み出したユーザ属性情報、ユーザが利用したいサービスの種類、ユーザが行いたいサービスへの操作、サービスを実行するに際してのユーザの環境条件に適合するか否かと、当該読み出したポリシ情報に示される利用料金の上限値に対して前記受信した利用料金応答内の利用料金が適合するか否かとに応じて、前記サービスデータの送信を許可するか否かを判定することを特徴とする認証連携システム。
3. 請求項１に記載の認証連携システムにおいて、
   前記各ポリシ情報のうちのいずれかのポリシ情報は、前記サービスプロバイダＩＤに関連付けて、当該サービスプロバイダＩＤで識別されるサービスプロバイダ装置によるサービスデータの送信が許可される対象となるユーザの環境条件と、当該ユーザの人数が上限値を超えた場合には当該ユーザの中で最終利用日から現在までの期間が所定期間以上であるユーザが存在することと、当該存在するユーザのユーザ属性部分情報を無効化することとを示しており、
   前記各サービスプロバイダ装置は、
   前記ユーザＩＤと、前記サービスデータを送信した最終の日付を示す最終利用日とを含む最終利用日情報を記憶する最終利用日記憶手段と、
   前記ＩＤプロバイダ装置から最終利用日送信要求を受けると、前記最終利用日記憶手段内の最終利用日情報を当該ＩＤプロバイダ装置に送信する手段と、
   を更に備え、
   前記ＩＤプロバイダ装置は、
   前記サービスプロバイダＩＤと、当該サービスプロバイダＩＤに関連付けられた前記サービス利用状況が示す前記サービス利用中の個数を示していて前記ユーザの人数に等しい利用数と、前記利用数の上限値とを関連付けて記憶するサービス利用数記憶手段と、
   前記送出されたポリシ評価要求内のサービスプロバイダＩＤに基づいて前記サービス利用数記憶手段から利用数及び上限値を読み出す手段と、
   前記送出されたポリシ評価要求内のサービスプロバイダＩＤに基づいて、当該サービスプロバイダＩＤで識別されるサービスプロバイダ装置に対し、前記最終利用日送信要求を送信し、当該サービスプロバイダ装置から前記最終利用日情報を受信する手段と
   を更に備え、
   前記送信許可判定手段は、
   前記読み出したポリシ情報にユーザの利用数の上限値を超えた場合に前記所定期間以上であるユーザが存在することと当該存在するユーザのユーザ属性部分情報を無効化することとが含まれる場合、前記読み出したポリシ情報に対して前記読み出したユーザ属性情報、ユーザが利用したいサービスの種類、ユーザが行いたいサービスへの操作、サービスを実行するに際してのユーザの環境条件に適合するか否かと、前記サービス利用数記憶手段から読み出した利用数が当該サービス利用数記憶手段から読み出した上限値を超えた場合に前記最終利用日送信要求をサービスプロバイダ装置に送信して当該サービスプロバイダ装置から受けた最終利用日情報内の最終利用日が前記読み出したポリシ情報内の所定期間以上に適合するか否かとに応じて、前記サービスデータの送信を許可するか否かを判定する手段と、
   この判定の結果が許可を示す場合、当該判定に用いた所定期間以上のユーザのユーザＩＤを含む無効化要求を前記サービスプロバイダ装置に送信する手段と
   を備えたことを特徴とする認証連携システム。
4. ユーザが操作するユーザ端末にログイン処理を実行可能で第１メモリを有するＩＤプロバイダ装置における前記ログイン処理が成功した場合に前記ユーザ端末にサービスデータを送信可能で第２メモリを有する複数のサービスプロバイダ装置に通信可能な前記ＩＤプロバイダ装置であって、
   前記ユーザを特定するためのユーザ属性の項目名と前記ユーザ属性の項目値とを関連付けたユーザ属性情報であって、少なくとも前記ユーザを識別するユーザＩＤを前記項目名に含む複数の前記ユーザ属性情報を記憶するユーザ属性情報記憶手段と、
   前記ユーザＩＤと、前記各サービスプロバイダ装置を識別するサービスプロバイダＩＤと、前記サービスデータの送信が許可された場合を示すサービス利用中、又は前記サービスデータの送信が許可されていない場合を示すサービス未利用のいずれかを示すサービス利用状況とを関連付けて記憶するサービス利用状況記憶手段と、
   前記サービスプロバイダＩＤ毎に、当該サービスプロバイダＩＤで識別されるサービスプロバイダ装置によるサービスデータの送信が許可される対象となるユーザの環境条件を示す複数のポリシ情報を記憶するポリシ記憶手段と、
   前記サービスプロバイダＩＤと、前記ユーザ属性情報内のユーザ属性の項目名のうち、一部の項目名とを関連付けて記憶する一部項目名記憶手段と、
   自装置の署名生成鍵を記憶する鍵記憶手段と、
   いずれかの前記サービスプロバイダ装置から送信されて当該サービスプロバイダ装置のサービスプロバイダＩＤと前記ユーザ端末のアドレス情報とを含む認証連携要求を受けると、当該認証連携要求内のユーザ端末のアドレス情報を含むユーザ認証要求を送出する手段と、
   前記送出されたユーザ認証要求内のユーザ端末のアドレス情報に基づいて、当該ユーザ端末にログイン要求を送信し、当該ユーザ端末から受けたユーザＩＤ及びユーザ認証情報を前記ユーザ属性情報記憶手段内のユーザＩＤ及び参照情報に基づいて認証するログイン処理を実行する手段と、
   前記ログイン処理が成功したとき、当該ログイン処理に用いたユーザＩＤと前記認証連携要求内のサービスプロバイダＩＤとを含むポリシ評価要求を送出する手段と、
   前記送出されたポリシ評価要求内のユーザＩＤに基づいて前記ユーザ属性記憶手段からユーザ属性情報を読み出す手段と、
   前記送出されたポリシ評価要求内のサービスプロバイダＩＤに基づいて前記ポリシ記憶手段からポリシ情報を読み出す手段と、
   前記読み出したポリシ情報に対し、前記読み出したユーザ属性情報、ユーザが利用したいサービスの種類、ユーザが行いたいサービスへの操作、サービスを実行するに際してのユーザの環境条件に適合するか否かに応じて、前記サービスデータの送信を許可するか否かを判定する送信許可判定手段と、
   この判定結果を含むポリシ評価応答を前記ポリシ評価要求の送信元に送出する手段と、
   前記ポリシ評価応答内の判定結果が許可を示す場合、前記ポリシ評価要求内のユーザＩＤとサービスプロバイダＩＤとを含むアカウント連携要求を送出する手段と、
   前記送出されたアカウント連携要求内のサービスプロバイダＩＤに基づいて、前記一部項目名記憶手段からユーザ属性の一部の項目名を読み出す手段と、
   当該読み出した一部の項目名と前記アカウント連携要求内のユーザＩＤとに基づいて、前記ユーザ属性記憶手段内で当該ユーザＩＤに一致するユーザＩＤを含むユーザ属性情報のうち、当該一部の項目名に一致する項目名及びこの項目名に関連付けられた項目値からなるユーザ属性部分情報を取得する手段と、
   前記取得したユーザ属性部分情報にアカウント登録指示を付加してアカウント連携要求メッセージを作成する手段と、
   前記アカウント連携要求メッセージを前記認証連携要求の送信元のサービスプロバイダ装置に送信する手段と、
   前記アカウント連携要求メッセージの送信先のサービスプロバイダ装置から当該サービスプロバイダ装置のサービスプロバイダＩＤと前記ユーザ属性部分情報内のユーザＩＤとを含む登録完了が通知されると、当該登録完了を示すアカウント連携応答を送出する手段と、
   前記送出されたアカウント連携応答内の登録完了に含まれるサービスプロバイダＩＤ及びユーザＩＤに基づいて、前記サービス利用状況記憶手段内のサービス利用状況をサービス未利用からサービス利用中に更新する手段と、
   前記送出されたアカウント連携応答内の登録完了に含まれるサービスプロバイダＩＤ及びユーザＩＤを含む認証連携実行要求を送出する手段と、
   前記認証連携実行要求を受けると、当該認証連携実行要求内のサービスプロバイダＩＤで識別されるサービスプロバイダ装置と自装置との間で共有する認証連携ＩＤを発行し、この認証連携ＩＤと当該認証連携実行要求内のユーザＩＤとを関連付けて前記第１メモリに書き込む手段と、
   前記発行した認証連携ＩＤと、前記ログイン処理の認証方式名とを含むアサーション本文に対して前記署名生成鍵に基づくデジタル署名を生成し、当該アサーション本文と当該デジタル署名とを含む認証アサーションを作成する手段と、
   前記作成した認証アサーションを含む認証連携応答を前記認証連携要求の送信元のサービスプロバイダ装置に送信する手段と
   を備え、
   前記各サービスプロバイダ装置は、
   前記ユーザ端末からサービス要求を受けると、当該サービス要求が認証トークンを含むか否かを判定し、前記認証トークンを含む場合には当該認証トークンと前記サービスデータ記憶手段内のサービスデータとを当該ユーザ端末に送信し、否の場合には自装置のサービスプロバイダＩＤと当該ユーザ端末のアドレス情報とを含む認証連携要求を前記ＩＤプロバイダ装置に送信し、
   前記アカウント連携要求メッセージを受信すると、新規の前記ＳＰ側ユーザＩＤを発行し、当該発行したＳＰ側ユーザＩＤと、当該アカウント連携要求メッセージ内のユーザ属性部分情報とを関連付けて登録し、
   この登録の後、登録したユーザ属性部分情報内のユーザＩＤと自装置のサービスプロバイダＩＤとを含む登録完了を前記アカウント連携要求メッセージの送信元のＩＤプロバイダ装置に通知し、
   前記ＩＤプロバイダ装置から認証連携応答を受けると、当該認証連携応答内の認証アサーションから認証連携ＩＤを抽出し、当該抽出した認証連携ＩＤと、前記登録されたユーザ属性部分情報内のユーザＩＤとを関連付けて前記第２メモリに書き込むと、予め記憶した認証アサーション検証ポリシ内の認証方式名と署名検証鍵とに基づいて、前記認証アサーション内の認証方式名とデジタル署名とをそれぞれ検証し、
   前記検証した結果がいずれも正当のとき、認証トークンを発行し、この認証トークンを前記認証連携ＩＤに関連付けて前記第２メモリに書き込むと、前記書き込まれた認証トークンと、当該認証トークンに前記第２メモリ内で前記認証連携ＩＤを介して関連付けられたユーザＩＤとを含むサービス実行要求を送出し、前記送出されたサービス実行要求に基づいて、当該サービス実行要求内の認証トークンと予め記憶したサービスデータとを前記ユーザ端末に送信することを特徴とするＩＤプロバイダ装置。

Images