JP2013182460A - サービス提供方法、プログラム、および情報処理装置 - Google Patents

Abstract

【課題】提供するサービス上の他の装置で認証を受けたユーザの役割を適切に決定できるようにする。
【解決手段】受信手段１ｄは、他の情報処理装置で提供される第２のサービスと、ユーザの役割とが示された役割情報を、該ユーザ４が使用する端末装置３から受信する。判断手段１ｅは、自装置と他の情報処理装置との間の関係を示す関係情報１ａｂを参照し、自装置が提供する第１のサービスと、役割情報に示される第２のサービスとの間の関係を判断する。そして決定手段１ｆは、判断された関係と、受信した役割情報に示された役割との組み合わせに応じて、受信した役割情報の送信元の端末装置３を使用するユーザ４の第１のサービス上の役割を決定する。
【選択図】図１

Description

本発明は、ユーザの役割に応じたサービスを提供するサービス提供方法、プログラム、および情報処理装置に関する。

情報通信技術の１つとして、ネットワーク上の複数のサービスを連携させることで、高度なサービスを提供する技術がある。例えば、サービス提供者がＲＥＳＴ（Representational State Transfer）形式のＷｅｂＡＰＩ（Application Program Interface）を開示し、そのＷｅｂＡＰＩを用いてアプリケーション間の連携を可能とする技術がある。なお開示されるＷｅｂＡＰＩに対するアクセスは、例えばＯＡｕｔｈ等の認証プロトコルをつかって適切なアクセス制御が行われる。アプリ開発者はこのＷｅｂＡＰＩ、または他のサービス提供者が提供するＡＰＩと組み合わせてアプリケーションソフトウェアを開発する。このようにして開発されたアプリケーションソフトウェアは、マッシュアップアプリケーションと呼ばれる。

別の情報通信技術としては、ロールベースアクセスコントロール技術がある。ロールベースアクセスコントロールは、認証されたユーザに役割（ロール）を与え、リソースに対するアクセス制御の方式として、役割に応じて許可（パーミッション）を与える形態のアクセスコントロールである。

また複数のドメインに存在する複数のネットワークにアクセスするためのシングル・サイン・オンを可能にする技術も考えられている。この技術は、連携ドメイン環境と非連携ドメイン環境とにおける使用に拡張可能とされている。

さらに、利用者に関する属性を容易かつ安全に設定する認証システムも考えられている。この認証システムでは、認証トークンが、認証が成功したと判別した場合、登録生体情報に対応付けられている属性情報を利用機器に送信する。そして、利用機器が、受信した属性情報が示す利用者の属性を識別し、属性識別部が識別した属性に対応するサービスを提供する。

国際公開第２００６／６７０４号 特開２００９−２３８１２５号公報

あるサーバが、複数の他のサーバそれぞれで認証されたユーザにサービスを提供する場合、各ユーザに対して、ユーザの役割に応じた内容のサービスを提供することが考えられる。ただし、あるサーバから見たときの、他の複数のサーバそれぞれで認証されたユーザの信頼性は、すべて同一というわけではない。

例えば、第１の企業が製品開発を行う際に、資本関係にある第２の企業と資本関係にない第３の企業とのそれぞれに、開発業務の一部を委託した場合を想定する。委託元である第１の企業内のサーバに対する、資本関係にある第２の企業のサーバで認証された開発担当社員からのアクセスであれば、広い範囲の情報にアクセスを許可することができよう。一方、委託元である第１の企業内のサーバに対する、資本関係にない第３の企業のサーバで認証された開発担当社員からのアクセスであれば、アクセスを許可できる情報の範囲は極めて限定的とすることが求められよう。このように、開発担当という同じ役割を有するユーザであっても、認証を受けたサーバが異なれば、サービス内容も異ならせることが適切であろうと発明者は考えた。

しかし、従来の技術では、異なるサーバで認証を受けた同種の役割の複数のユーザそれぞれに、ユーザが認証を受けたサーバに応じて異なる役割を割り当てて、異なる内容のサービスを提供することができない。すなわち、他の装置で認証を受けたユーザに対して割り当てる、適切な役割を判断することができない。

１つの側面では、本発明は、提供するサービス上の他の装置で認証を受けたユーザの役割を適切に決定することができるサービス提供方法、プログラム、および情報処理装置を提供することを目的とする。

１つの案では、情報処理装置が以下の処理を実行するサービス提供方法が提供される。このサービス提供方法によれば、情報処理装置は、他の情報処理装置で提供される第２のサービスと、該第２のサービス上のユーザの役割とが示された役割情報を、該ユーザが使用する端末装置から受信する。次に情報処理装置は、他の情報処理装置により提供される第２のサービスに対応付けて、自装置と該他の情報処理装置との間の関係が示された関係情報を参照し、該自装置で提供する第１のサービスと、受信した役割情報に示される第２のサービスとの間の関係を判断する。次に情報処理装置は、第１のサービスと第２のサービスとの間の関係と、該第２のサービス上の役割との組み合わせに対応する、第１のサービス上における役割を定義した役割割当ポリシを参照し、判断された関係と、受信した役割情報に示された役割との組み合わせに応じて、受信した役割情報の送信元の端末装置を使用するユーザの第１のサービス上の役割を決定する。

１態様によれば、提供するサービス上の他の装置で認証を受けたユーザの役割を適切に決定することができる。

第１の実施の形態に係るシステムの構成の一例を示す図である。 第１の実施の形態の処理手順を示すシーケンス図である。 第２の実施の形態のシステム構成例を示す図である。 本実施の形態に用いるサーバのハードウェアの一構成例を示す図である。 認証連携処理の概要を示す図である。 第２の実施の形態における各装置の機能の一例を示す図である。 役割管理情報記憶部の格納情報の一例を示す図である。 ユーザ管理テーブルのデータ構造の一例を示す図である。 関係定義テーブルのデータ構造の一例を示す図である。 役割割当ポリシ定義テーブルのデータ構造の一例を示す図である。 サービス定義テーブルのデータ構造の一例を示す図である。 トークンに含まれる情報の一例を示す図である。 サービス提供処理の手順の一例を示すシーケンス図である。 自身が認証したユーザへのトークン発行処理の手順の一例を示すフローチャートである。 関係に基づくトークン発行処理の手順の一例を示すフローチャートである。 トークン生成処理の手順の一例を示すフローチャートである。 役割を連鎖させたサービス提供処理の手順の一例を示すシーケンス図である。 複数のサービスを連携させて実行する業務の一例を示す図である。 第３の実施の形態におけるサービス提供処理の手順の一例を示すシーケンス図である。 第４の実施の形態におけるトークンに含まれる情報の一例を示す図である。 サービス提供処理の手順の一例を示すシーケンス図である。 宛先指定のトークンによる役割連鎖によるサービス提供処理の一例を示すシーケンス図である。 第４の実施の形態における関係に基づくトークン発行処理の手順の一例を示すフローチャートである。 宛先指定トークン生成処理の手順の一例を示すフローチャートである。

以下、本実施の形態について図面を参照して説明する。なお各実施の形態は、矛盾のない範囲で複数の実施の形態を組み合わせて実施することができる。
〔第１の実施の形態〕
第１の実施の形態は、他の装置と自装置との関係と、他の装置におけるユーザの役割とに基づいて、他の装置が提供する内部サービス（第１のサービス）上の役割が付与されたユーザに対する、自装置が提供するサービス上の適切な役割を決定するものである。

図１は、第１の実施の形態に係るシステムの構成の一例を示す図である。第１の実施の形態では、情報処理装置１，２と端末装置３とがネットワークで接続されている。
情報処理装置１は、記憶手段１ａ、認証手段１ｂ、役割情報発行手段１ｃ、受信手段１ｄ、判断手段１ｅ、決定手段１ｆ、および処理手段１ｇを有する。

記憶手段１ａは、役割定義１ａａ、関係情報１ａｂ、役割割当ポリシ１ａｃ、およびサービス定義１ａｄを記憶している。役割定義１ａａは、ユーザごとの第１のサービス上の役割を示す情報である。関係情報１ａｂは、他の情報処理装置により提供される第２のサービスに対応付けて、自装置と該他の情報処理装置との間の関係が示された情報である。役割割当ポリシ１ａｃは、第１のサービスと第２のサービスとの間の関係と、該第２のサービス上の役割との組み合わせに対応する、第１のサービス上の役割を定義する情報である。サービス定義１ａｄは、役割に応じて許容されるサービスの範囲を定義する情報である。

認証手段１ｂは、ユーザ４が使用する端末装置３からの認証要求に応じて、ユーザ４のユーザ認証を行う。例えば認証手段１ｂは、認証要求に示される認証情報が、予め登録されたユーザの認証情報と一致するか否かにより、ユーザ認証を行う。

役割情報発行手段１ｃは、ユーザ認証に成功した場合、役割定義１ａａを参照し、第１のサービス上の該認証要求の送信元の端末装置を使用するユーザの役割を決定する。そして役割情報発行手段１ｃは、第１のサービスと決定した役割とを示す役割情報を、端末装置３に送信する。また役割情報発行手段１ｃは、第１のサービスと、決定手段１ｆが決定した役割とを示す役割情報を、端末装置３に送信する。

受信手段１ｄは、他の情報処理装置２で提供される第２のサービスと、第２のサービス上のユーザ４の役割とが示された役割情報を、ユーザ４が使用する端末装置３から受信する。

判断手段１ｅは、関係情報１ａｂを参照し、第１のサービスと、受信した役割情報に示される第２のサービスとの間の関係を判断する。例えば判断手段１ｅは、受信した役割情報に示される第２のサービスに対応付けて示されている、自装置と他の情報処理装置との間の関係を、第１のサービスと、受信した役割情報に示される第２のサービスとの間の関係と判断する。

決定手段１ｆは、役割割当ポリシ１ａｃを参照し、判断手段１ｅで判断された関係と、受信した役割情報に示された役割との組み合わせに応じて、受信した役割情報の送信元の端末装置３を使用するユーザ４の第１のサービス上の役割を決定する。

処理手段１ｇは、サービス定義１ａｄを参照し、決定手段１ｆが決定した役割に応じて許容されるサービスの範囲内で、第１のサービスの処理を実行する。
情報処理装置２は、記憶手段２ａ、認証手段２ｂ、役割情報発行手段２ｃ、受信手段２ｄ、判断手段２ｅ、決定手段２ｆ、および処理手段２ｇを有する。記憶手段２ａは、役割定義２ａａ、関係情報２ａｂ、役割割当ポリシ２ａｃ、およびサービス定義２ａｄを記憶している。情報処理装置２の各要素の機能は、情報処理装置１の同名の要素の機能と同じである。また記憶手段２ａに記憶された各情報は、記憶手段１ａ内の同名の情報と同種の情報である。

なお、情報処理装置１にとっての第１のサービスは、情報処理装置２にとっての第２のサービスである。また情報処理装置２にとっての第１のサービスは、情報処理装置１にとっての第２のサービスである。

端末装置３は、認証要求手段３ａ、役割情報取得手段３ｂ、および処理要求手段３ｃを有する。
認証要求手段３ａは、ユーザ４からの操作に応じて、ユーザ４がアカウントを有する情報処理装置に認証要求を送信する。

役割情報取得手段３ｂは、ユーザ４のユーザ認証を行った情報処理装置から、役割情報を取得する。
処理要求手段３ｃは、情報処理装置に対する処理要求を送信する。例えば処理要求手段３ｃは、情報処理装置１，２のうちの一方の情報処理装置から取得した役割情報を付与した処理要求を、他方の情報処理装置に送信する。

このようなシステムにより、ユーザ４は、一方の情報処理装置でユーザ認証を受けることで、他方の情報処理装置のサービスの提供を受けることができる。その際、他方の情報処理装置から受けることができるサービスの内容は、ユーザ４が認証を受けた情報処理装置のサービス上のユーザ４の役割と、認証を受けた情報処理装置のサービスと、サービス間の関係とに応じて決定される。

以下、ユーザ４が、情報処理装置２で認証を受け、情報処理装置１でサービスの提供を受ける場合を例に取り、第１の実施の形態における処理手順について説明する。
図２は、第１の実施の形態の処理手順を示すシーケンス図である。図２の例では、情報処理装置１で提供されるサービスを「サービスＡ」とし、情報処理装置２で提供されるサービスを「サービスＢ」とする。またユーザ４は、情報処理装置２にはアカウントを有しているが、情報処理装置１にはアカウントを有していないものとする。さらにサービスＡの提供者とサービスＢの提供者との間には、信頼関係を有し、情報処理装置Ａには、サービスＡに対するサービスＢの関係が定義されているものとする。このような状況のもと、図２に示す処理が実行される。以下、ステップ番号に沿って、図２に示す処理を説明する。

［ステップＳ１］ユーザ４は、端末装置３に対して、情報処理装置２のサービスにログインするためのログイン操作を行う。例えばユーザ４は、ユーザ４自身のユーザＩＤとパスワードとを入力する。

［ステップＳ２］端末装置３の認証要求手段３ａは、情報処理装置２に対して認証情報を送信する。認証情報は、例えばユーザＩＤとパスワードとの組である。
［ステップＳ３］情報処理装置２の認証手段２ｂは、端末装置３から送られた認証情報に基づいて、ユーザ認証を行う。例えば情報処理装置２は、端末装置３から送られた認証情報と、予め登録されている認証情報とを照合し、端末装置３から送られた認証情報と一致する認証情報がある場合、ユーザ４を、一致した認証情報に示されるユーザＩＤの正当なユーザであると認証する。

［ステップＳ４］情報処理装置２の認証手段２ｂは、認証結果を端末装置３に応答する。
［ステップＳ５］端末装置３の認証要求手段３ａは、認証処理の結果を表示する。

［ステップＳ６］その後、ユーザ４は、サービスＡの処理が必要となる操作を、端末装置３に対して入力する。
［ステップＳ７］端末装置３の役割情報取得手段３ｂは、情報処理装置１で提供されるサービスＡの処理が必要であると認識し、まず、認証を受けている情報処理装置２に対して、役割情報要求を送信する。

［ステップＳ８］情報処理装置２の役割情報発行手段２ｃは、役割情報要求に応答し、役割定義１ａａを参照し、サービスＢ上での認証要求の送信元の端末装置３を使用するユーザ４の役割を決定する。

［ステップＳ９］役割情報発行手段１ｃは、サービスＢと、サービスＢ上のユーザ４の役割とを示す役割情報を、端末装置３に送信する。
［ステップＳ１０］端末装置３の役割情報取得手段３ｂは、情報処理装置２から送られた役割情報を取得し、その役割情報を処理要求手段３ｃに渡す。処理要求手段３ｃは、受け取った役割情報を付与した処理要求を情報処理装置１に送信する。

［ステップＳ１１］情報処理装置１の受信手段１ｄは、役割情報が付与された処理要求を受信する。受信手段１ｄは、受信した役割情報を判断手段１ｅに渡す。判断手段１ｅは、関係情報１ａｂを参照し、第１のサービスと、受信した役割情報に示される第２のサービスとの間の関係を判断する。判断手段１ｅは、判断した関係を、決定手段１ｆに通知する。決定手段１ｆは、役割割当ポリシ１ａｃを参照し、判断手段１ｅで判断された関係と、受信した役割情報に示された役割との組み合わせに応じて、受信した役割情報の送信元の端末装置３を使用するユーザ４のサービスＡ上の役割を決定する。決定手段１ｆは、決定した役割を、処理手段１ｇに通知する。

［ステップＳ１２］処理手段１ｇは、サービス定義１ａｄを参照し、決定手段１ｆが決定した役割に応じて許容されるサービスの範囲内で、処理要求で要求されたサービスＡの処理を実行する。

［ステップＳ１３］処理手段１ｇは、処理結果を端末装置３に応答する。
［ステップＳ１４］端末装置３の処理要求手段３ｃは、情報処理装置１から送られた処理結果を表示する。

このようにして、情報処理装置１は、ユーザ４に対し、適切なサービス内容のサービスを提供することができる。例えば、情報処理装置１を管理する企業の子会社が、情報処理装置２を管理しており、ユーザ４が子会社の社員の場合、情報処理装置１は、ユーザ４に対して「子会社の社員」という役割を割り当て、その役割に応じた範囲でサービスを提供できる。また情報処理装置１を管理する企業の取引会社が、情報処理装置２を管理しており、ユーザ４が取引会社の社員の場合、情報処理装置１は、ユーザ４に対して「取引会社の社員」という役割を割り当て、その役割に応じた範囲でサービスを提供できる。これにより、例えば、情報処理装置１では、取引会社の社員への提供を許容するサービスよりも広い範囲のサービスを、子会社の社員に提供できる。

このように他の情報処理装置で認証されたユーザに対して適切な役割を決定できることで、各情報処理装置では、サービスを提供するすべてのユーザのアカウント情報を管理せずにすむ。例えば、情報処理装置１は、ユーザ４のアカウント情報を管理しなくても、ユーザ４に対して適切な範囲でのサービスを提供可能である。その結果、システムの管理負担が軽減される。

なお、認証手段１ｂ，２ｂ、役割情報発行手段１ｃ，２ｃ、受信手段１ｄ，２ｄ、判断手段１ｅ，２ｅ、決定手段１ｆ，２ｆ、および処理手段１ｇ，２ｇは、情報処理装置１，２が有するＣＰＵ（Central Processing Unit）により実現することができる。また、記憶手段１ａ，２ａは、情報処理装置１，２が有するＲＡＭ（Random Access Memory）やハードディスクドライブ（ＨＤＤ:Hard Disk Drive）などにより実現することができる。

また、図１に示した各要素間を接続する線は通信経路の一部を示すものであり、図示した通信経路以外の通信経路も設定可能である。
〔第２の実施の形態〕
次に第２の実施の形態について説明する。第２の実施の形態は、直接の信頼関係を持たないサーバ間でも、認証連携によるサービス提供を可能とするものである。

例えば第１の企業が、資本関係にある第２の企業に開発業務を委託し、第２の企業は、資本関係にない第３の企業に開発の業務の一部を委託した場合を想定する。ここで、第１の企業と第２の企業との間では信頼関係があり、第２の企業と第３の企業との間でも信頼関係がある。他方、第１の企業と第３の企業との間は、信頼関係は確立していないものとする。

このような場合であっても、開発業務に関係する者の間で共有すべき情報がある。例えば発注の大元である第１の企業が、開発に関るすべてのメンバについての認証情報を、第１の企業のサーバで管理することも考えられる。しかし、メンバに関するデータの管理は、夫々の会社で行った方が利便性が高い。そこで、それぞれの会社は個別に開発メンバを管理するサーバを保持する。その上で、第１の企業のユーザは、第１の企業のサーバにアクセスして開発メンバ表を閲覧できるのはもちろんのこと、開発管理者として、第２の企業のサーバにアクセスし開発メンバを閲覧できるようにしたい。さらには、第１の企業と第３の企業とは直接の取引関係はないとしても、第２の企業からの発注先である第３の企業のサーバにもアクセスして、開発メンバを閲覧できるようにしたい。

このような場合において、第２の実施の形態では、連鎖的に役割認証情報を移譲することで、第１の企業のユーザからの、直接の信頼関係のない第３の企業のサーバへのアクセスを可能とする。

図３は、第２の実施の形態のシステム構成例を示す図である。第２の実施の形態では、複数のサーバ１００，２００，３００，・・・がネットワーク１０を介して接続されている。またネットワーク１０には、複数のユーザ２１，２２，２３，・・・それぞれが使用する端末装置３１，３２，３３，・・・が接続されている。

ユーザ２１，２２，２３，・・・は、それぞれ、複数のサーバ１００，２００，３００，・・・のうちの少なくとも１つのサーバに、ユーザアカウントを有している。例えばユーザ２１はサーバ１００にユーザアカウントを有し、ユーザ２２はサーバ２００にユーザアカウントを有し、ユーザ２３はサーバ３００にユーザアカウントを有する。

各サーバ１００，２００，３００，・・・、そのサーバにユーザアカウントを有するユーザに関するアカウント情報を管理している。アカウント情報には、ユーザの認証情報や、役割情報が含まれる。認証情報は、例えばユーザＩＤとパスワードとの組である。

図４は、本実施の形態に用いるサーバのハードウェアの一構成例を示す図である。サーバ１００は、ＣＰＵ１０１によって装置全体が制御されている。ＣＰＵ１０１には、バス１０８を介してＲＡＭ１０２と複数の周辺機器が接続されている。なおサーバ１００が有するＣＰＵ数は１つに限定されず、複数であってもよい。サーバ１００が複数のＣＰＵを有する場合、複数のＣＰＵが連係動作し、装置全体を制御する。

ＲＡＭ１０２は、サーバ１００の主記憶装置として使用される。ＲＡＭ１０２には、ＣＰＵ１０１に実行させるＯＳ（Operating System）のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、ＲＡＭ１０２には、ＣＰＵ１０１による処理に必要な各種データが格納される。

バス１０８に接続されている周辺機器としては、ＨＤＤ１０３、グラフィック処理装置１０４、入力インタフェース１０５、光学ドライブ装置１０６、および通信インタフェース１０７がある。

ＨＤＤ１０３は、内蔵したディスクに対して、磁気的にデータの書き込みおよび読み出しを行う。ＨＤＤ１０３は、サーバ１００の二次記憶装置として使用される。ＨＤＤ１０３には、ＯＳのプログラム、アプリケーションプログラム、および各種データが格納される。なお、二次記憶装置としては、フラッシュメモリなどの半導体記憶装置を使用することもできる。

グラフィック処理装置１０４には、モニタ１１が接続されている。グラフィック処理装置１０４は、ＣＰＵ１０１からの命令に従って、画像をモニタ１１の画面に表示させる。モニタ１１としては、ＣＲＴ（Cathode Ray Tube）を用いた表示装置や液晶表示装置などがある。

入力インタフェース１０５には、キーボード１２とマウス１３とが接続されている。入力インタフェース１０５は、キーボード１２やマウス１３から送られてくる信号をＣＰＵ１０１に送信する。なお、マウス１３は、ポインティングデバイスの一例であり、他のポインティングデバイスを使用することもできる。他のポインティングデバイスとしては、タッチパネル、タブレット、タッチパッド、トラックボールなどがある。

光学ドライブ装置１０６は、レーザ光などを利用して、光ディスク１４に記録されたデータの読み取りを行う。光ディスク１４は、光の反射によって読み取り可能なようにデータが記録された可搬型の記録媒体である。光ディスク１４には、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）などがある。

通信インタフェース１０７は、ネットワーク１０に接続されている。通信インタフェース１０７は、ネットワーク１０を介して、他のサーバまたは通信機器との間でデータの送受信を行う。

以上のようなハードウェア構成によって、本実施の形態の処理機能を実現することができる。なお、図４には、サーバ１００のハードウェア構成例を示したが、他のサーバ２００，３００，・・・や端末装置３１，３２，３３，・・・も同様のハードウェアで実現できる。また、第１の実施の形態に示した情報処理装置１，２や端末装置３も、図４に示したサーバ１００と同様のハードウェアにより実現することができる。

このようなシステムにおいて、各ユーザは、自己がアカウントを有していないサーバから、役割に応じたサービス提供を受けることができる。
図５は、認証連携処理の概要を示す図である。図５の例では、サーバ１００で提供されるサービスを「サービスＡ」、サーバ２００で提供されるサービスを「サービスＢ」、サーバ３００で提供されるサービスを「サービスＣ」としている。

サーバ１００，２００，３００それぞれの管理者間で信頼関係がある場合、信頼関係がある２者のそれぞれが管理するサーバに、信頼関係に基づいた関係が定義される。図５の例では、サーバ１００とサーバ２００との間では、それぞれが提供しているサービス間の関係ｒｅｌ（Ａ，Ｂ）が定義されている。またサーバ２００とサーバ３００との間では、それぞれが提供しているサービス間の関係ｒｅｌ（Ｂ，Ｃ）が定義されている。なお、サーバ１００とサーバ２００との間では、提供しているサービス間の関係は定義されていない。

このような状況下で、例えばサーバ１００にアカウントを有するユーザ２１が、端末装置３１を用いて、サーバ１００との間でユーザ認証の一連の手続きを行ったものとする。このとき、サーバ１００で認証されたユーザ２１が使用する端末装置３１は、サーバ１００から、サーバ１００内に定義されたユーザ２１の「サービスＡ」上の役割を取得することができる。

その後、端末装置３１は、サーバ２００に対してから「サービスＡ」上の役割を通知することで、ユーザ２１の「サービスＢ」上の役割を、サーバ２００から取得することができる。このときサーバ２００は、サーバ１００との間で予め定義された関係ｒｅｌ（Ａ，Ｂ）と、端末装置３１から受け取ったユーザ２１の「サービスＡ」上の役割との組み合わせに応じて、ユーザ２１の「サービスＢ」上の役割を決定する。

さらに端末装置３１は、サーバ３００に対してから「サービスＢ」上の役割を通知することで、ユーザ２１の「サービスＣ」上の役割を、サーバ３００から取得することができる。このときサーバ３００は、サーバ２００との間で予め定義された関係ｒｅｌ（Ｂ，Ｃ）と、端末装置３１から受け取ったユーザ２１の「サービスＢ」上の役割との組み合わせに応じて、ユーザ２１の「サービスＣ」上の役割を決定する。

端末装置３１は、各サーバ１００，２００，３００それぞれから、そのサーバで提供されるサービスに関するユーザ２１の役割に応じたサービスの提供を受けることができる。すなわち、ユーザ２１は、関係を有するサーバを辿り、その都度、サーバから役割を取得することで、認証を受けたサーバ１００と直接的には関係が定義されていないサーバ３００から、役割に応じたサービス提供を受けることが可能となっている。原理的には無制限に役割取得の連鎖が可能である。

以下、図５に示したような処理を実現するための、各サーバの機能について説明する。
図６は、第２の実施の形態における各装置の機能の一例を示す図である。端末装置３１ではアプリケーション３１ａが実行されている。アプリケーション３１ａは、端末装置３１がアプリケーションソフトウェアを実行することによって実現されている機能である。アプリケーション３１ａは、ユーザ２１からの操作入力に応じて、サーバにサービス要求を送信し、各サーバで決定された役割に応じた範囲でのサービスを利用する。なおアプリケーション３１ａは、サーバにサービス要求を送信する前に、そのサーバにトークン発行要求を送信し、そのサーバで提供されるサービス上の役割を含むトークンを取得する。トークンは、決定された役割に応じた範囲内で、サーバで提供されるサービスを使用する権利を有しているユーザであることを証明する情報である。またアプリケーション３１ａは、ユーザ２１がアカウントを有しているサーバに対しては、認証要求を送信し、ユーザ認証を受けることができる。

同様に端末装置３２，３３では、アプリケーション３２ａ，３３ａが実行されている。アプリケーション３２ａ，３３ａは、端末装置３１のアプリケーション３１ａと同様の機能を有する。

サーバ１００は、データベース（ＤＢ）１１０、役割管理情報記憶部１２０、認証部１３０、およびアクセス制御部１４０を有する。
ＤＢ１１０は、データ提供サービスである「サービスＡ」によって提供するデータを記憶する。ＤＢ１１０としては、例えばＨＤＤ１０３内の記憶領域の一部が使用される。

役割管理情報記憶部１２０は、ユーザの役割を決定するための規則に関する情報（役割ポリシ）を記憶する。役割ポリシでは、例えば、自己の認証したユーザに対する自己のサービス上の役割、他のサーバとの間で定義された関係、他のサーバが認証したユーザに対して与える自己のサービス上の役割の決定規則などが定義されている。役割管理情報記憶部１２０としては、例えばＲＡＭ１０２またはＨＤＤ１０３の記憶領域の一部が使用される。

認証部１３０は、役割管理情報記憶部１２０を参照し、サービスを要求したユーザを認証するとともに、認証したユーザの役割を決定する。例えば認証部１３０は、端末装置３１から送られた認証要求に応じて、認証要求に含まれる認証情報が正しいか否かを判断する。認証情報は、例えばユーザＩＤとクレデンシャル（信用情報）との組である。なおクレデンシャルには、例えばパスワードを用いることができる。またクレデンシャルとして、ユーザの指紋情報、手のひら静脈情報などの生態情報を用いることもできる。

また認証部１３０は、端末装置３１からのトークン発行要求に応じて、端末装置３１を使用するユーザ２１に予め対応付けられた役割を含むトークンを生成する。認証部１３０は、生成したトークンを、処理結果として出力する。

さらに、認証部１３０は、他のサーバで発行されたトークンを含むサービス要求に応答し、役割管理情報記憶部１２０を参照し、サービスを要求したユーザの役割を決定する。例えば認証部１３０は、ユーザに対して他のサーバが割り当てた役割と、そのサーバとサーバ１００自身との関係との組に応じた役割を、そのユーザの役割として決定する。次に、認証部１３０は、サービスを要求したユーザの役割を含むトークンを生成する。そして認証部１３０は、生成したトークンを処理結果として出力する。

アクセス制御部１４０は、端末装置３１からのサービス要求に応じてＤＢ１１０から情報を抽出し、抽出した情報を端末装置３１に送信する。なおアクセス制御部１４０は、ＤＢ１１０から情報を抽出する際には、端末装置３１のユーザの役割に応じた範囲内の情報のみを抽出する。またアクセス制御部１４０は、端末装置３１から、認証要求またはトークン発行要求を受け取った場合、認証要求またはトークン発行要求を、認証部１３０に渡す。アクセス制御部１４０は、認証部１３０から認証要求またはトークン発行要求に応じた処理結果を受け取った場合、受け取った結果を端末装置３１に送信する。

サーバ２００は、ＤＢ２１０、役割管理情報記憶部２２０、認証部２３０、およびアクセス制御部２４０を有する。同様にサーバ３００は、ＤＢ３１０、役割管理情報記憶部３２０、認証部３３０、およびアクセス制御部３４０を有する。サーバ２００，３００内の各要素は、サーバ１００の同名の要素と同じ機能を有する。

なお、図６に示した各要素間を接続する線は通信経路の一部を示すものであり、図示した通信経路以外の通信経路も設定可能である。また図６に示した役割管理情報記憶部１２０，２２０，３２０は、図１に示した第１の実施の形態における記憶手段１ａ，２ａの一例である。また図６に示した認証部１３０，２３０，３３０は、図１に示した第１の実施の形態の認証手段１ｂ，２ｂ、役割情報発行手段１ｃ，２ｃ、受信手段１ｄ，２ｄ、判断手段１ｅ，２ｅ、および決定手段１ｆ，２ｆを合わせた機能の一例である。さらに図６に示したアクセス制御部１４０，２４０，３４０は、図１に示した第１の実施の形態における処理手段１ｇ，２ｇの一例である。

次に、役割管理情報記憶部１２０に格納されている情報について詳細に説明する。
図７は、役割管理情報記憶部の格納情報の一例を示す図である。役割管理情報記憶部１２０には、ユーザ管理テーブル１２１、関係定義テーブル１２２、役割割当ポリシ定義テーブル１２３、およびサービス定義テーブル１２４が格納されている。

ユーザ管理テーブル１２１は、サーバ１００にアカウントを有するローカルユーザを管理するデータテーブルである。例えばユーザ管理テーブル１２１には、各ユーザのユーザＩＤ、役割、パスワートなどが設定されている。

関係定義テーブル１２２は、サーバ１００を管理する組織と信頼関係がある他の組織との関係と、他の組織が管理するサーバの識別情報との組を管理するデータテーブルである。

役割割当ポリシ定義テーブル１２３は、他のサーバにおける役割を有するユーザへの役割割当ポリシを定義するデータテーブルである。
サービス定義テーブル１２４は、ユーザの役割ごとのサービス内容が設定されたデータテーブルである。

以下、役割管理情報記憶部１２０に格納されたデータテーブルのデータ構造について説明する。
図８は、ユーザ管理テーブルのデータ構造の一例を示す図である。ユーザ管理テーブル１２１には、ユーザＩＤ、役割、およびクレデンシャルの欄が設けられている。各欄の行方向に並んだデータが、サーバ１００にアカウントを有するユーザを管理するためのレコードを構成する。

ユーザＩＤの欄には、ユーザの識別子が設定される。役割の欄には、サーバ１００が提供するサービス「サービスＡ」上での、ユーザの役割が設定される。クレデンシャルの欄には、ユーザを認証に使用する信用情報が設定される。信用情報としては、例えばパスワードを用いることができる。役割が設定されたサービスの識別子を「ｓ」、役割を有するユーザの識別子を「ｕ」とした場合、例えば、役割はｒｏｌｅ（ｓ，ｕ）という関数で表される。

このようなユーザ管理テーブル１２１に基づいて、ユーザ認証が行われるとともに、ユーザの役割を判定できる。例えば端末装置３１から、ユーザＩＤとパスワードとの組（認証情報）を含む認証要求をサーバ１００が受信した場合、認証部１３０が、ユーザ管理テーブル１２１から、認証要求に含まれる認証情報に一致するレコードを検索する。そして、認証部１３０は、一致するレコードがある場合、認証要求を送信した端末装置３１を使用しているユーザ２１が、一致したレコードのユーザＩＤで示されたユーザであると認証する。また認証部１３０は、一致したレコードに設定されている役割が、端末装置３１を使用しているユーザ２１の「サービスＡ」上の役割であると判断する。

なお図８に示すユーザ管理テーブル１２１に登録されたレコードは、図１に示す第１の実施の形態における役割定義１ａａ，２ａａの一例である。
図９は、関係定義テーブルのデータ構造の一例を示す図である。関係定義テーブル１２２には、相手のＵＲＬ（Uniform Resource Locator）、および相手との関係の欄が設けられている。各欄の行方向に並んだデータが、他のサーバとの間の関係定義を示すレコードを構成する。

相手のＵＲＬの欄には、サーバ１００を管理している組織との間で直接の信頼関係を有する他の組織が管理するサーバ（相手サーバ）で提供されるサービスに割り当てられたＵＲＬが設定される。相手との関係の欄には、サーバ１００を管理している組織と、相手サーバを管理している組織との間の関係が設定される。相手との関係としては、例えば、取引先、子会社、連結対象会社などがある。

なお図９に示す関係定義テーブル１２２に登録されたレコードは、図１に示す第１の実施の形態における関係情報１ａｂ，２ａｂの一例である。
図１０は、役割割当ポリシ定義テーブルのデータ構造の一例を示す図である。役割割当ポリシ定義テーブル１２３には、相手との関係、相手が認めた役割、および自身が認める役割の欄が設けられている。各欄の行方向に並んだデータが、他のサーバで提供されるサービス上の役割を有するユーザに対して設定する、サーバ１００が提供するサービス上の役割を定義するレコードを構成する。

相手との関係の欄には、サーバ１００を管理している組織と、相手サーバを管理している組織との間の関係が設定される。相手が認めた役割の欄には、相手サーバにおいて、ユーザに対して設定した役割が設定される。自身が認める役割の欄には、相手サーバで提供されているサービス上の役割を有するユーザに対して、サーバ１００自身が割り当てる役割が設定される。

なお図１０に示す役割割当ポリシ定義テーブル１２３に登録されたレコードは、図１に示す第１の実施の形態における役割割当ポリシ１ａｃ，２ａｃの一例である。
図１１は、サービス定義テーブルのデータ構造の一例を示す図である。サービス定義テーブル１２４には、役割とサービス内容との欄が設けられている。各欄の行方向に並んだデータが、役割に応じたサービス内容を定義したレコードを構成する。

役割の欄には、ユーザの役割が設定される。サービス内容の欄には、対応する役割を有するユーザに対して提供するサービスの内容が設定される。サービスの内容としては、例えば、ＤＢ１１０内のすべてのデータへのアクセスを許容するのか、ある属性のデータへのアクセスのみに制限するのかなどが定義される。例えばユーザの役割が予算係であれば、予算関係データへのアクセスを許容するように、サービス内容が設定される。またユーザの役割が社員であれば、例えばサーバ１００を管理する企業の全社員の名簿に対するアクセスを許容するにように、サービス内容が設定される。また役割が子会社の社員であれば、例えば、サーバ１００を管理する企業の各部署の代表者の名簿に対するアクセスを許容するように、サービス内容が設定される。

なお図１１に示すサービス定義テーブル１２４に登録されたレコードは、図１に示す第１の実施の形態のサービス定義１ａｄ，２ａｄの一例である。
また図７〜図１１には、サーバ１００が有する役割管理情報記憶部１２０のデータ構造を示したが、他のサーバ２００，３００の役割管理情報記憶部２２０，２３０にも、同様のデータ構造で同種のデータが格納されている。

以上のようなデータを利用して、各サーバは、相手サーバで提供されるサービスの役割を有するユーザに対して、その役割と相手サーバとの組に応じた役割を設定し、設定した役割に応じたサービスを提供することができる。

なお、第２の実施の形態では、サーバ間での役割を示す情報の受け渡しには、トークンが利用されている。以下、トークンの内容について説明する。
図１２は、トークンに含まれる情報の一例を示す図である。トークン４０には、トークン発行者４１、発行者が認めた役割リスト４２、アクセス主体４３、および電子署名４４が含まれる。

トークン発行者４１は、トークンを発行したサーバの識別子である。サーバの識別子としては、例えばサーバのＵＲＬが用いられる。
発行者が求めた役割リスト４２は、発行者がユーザの役割として認定した役割のリストである。ユーザが複数の役割を担う場合、リストには、複数の役割が設定される。

アクセス主体４３は、アクセスを行うユーザの識別子である。
電子署名４４は、トークン４０の正当性を保証するために、トークン４０の発行者が付与する情報である。

トークン発行者の識別子を「Ｉ」、ユーザの識別子を「ｕ」、ユーザに対して設定されたサービス「ｓ」の役割を「ｒｏｌｅ（ｓ，ｕ）」としたときのトークンは、例えばＴ（ｉｓｓｕｅｒ＝Ｉ，ｓｕｂｊｅｃｔ＝ｕ，ｒｏｌｅ＝ｒｏｌｅ（ｓ，ｕ））と表される。

トークン４０のフォーマットとしては、例えばＳＡＭＬ（Security Assertion Markup Language）２．０のAssertionフォーマットを用いることができる。
以下、役割に応じたサービス提供手順について説明する。

図１３は、サービス提供処理の手順の一例を示すシーケンス図である。図１３には、サーバ２００にアカウントを有するユーザ２２が、サーバ１００で提供されるサービスを利用する場合の例が示されている。なお、図１３に示す処理では、既にユーザ２２は、端末装置３２を用いてサーバ２００からユーザ認証を受け、ユーザ２２のサービスＢ上の役割が確定しているものとする。また、サーバ１００の識別子は「ａ」、サーバ２００の識別子は「ｂ」、ユーザ２２の識別子は「１」であるものとする。

［ステップＳ１１１］ユーザ２２は、端末装置３２を操作し、アプリケーション３２ａに対して、サービスＡへのアクセスが必要となる処理を指示する。
［ステップＳ１１２］端末装置３２のアプリケーション３２ａは、ユーザ２２の操作に応答し、トークン発行要求をサーバ２００に送信する。

［ステップＳ１１３］サーバ２００では、アクセス制御部２４０がトークン発行要求を受信し、受信したトークン発行要求を認証部２３０に転送する。すると認証部２３０は、ユーザ２２のサービスＢにおける役割ｒｏｌｅ（Ｂ，１）を証明するトークンＴ（ｉｓｓｕｅｒ＝ｂ，ｓｕｂｊｅｃｔ＝１，ｒｏｌｅ＝ｒｏｌｅ（Ｂ，１））を発行する。

［ステップＳ１１４］サーバ２００の認証部２３０は、サービスＢ上の役割が記された、サービスＢ用のトークンを、アクセス制御部２４０を介して端末装置３２に送信する。
［ステップＳ１１５］端末装置３２のアプリケーション３２ａは、サービスＢ用のトークンを付与した、サービスＡのトークン発行要求を生成する。そしてアプリケーション３２ａは、サービスＡのトークン発行要求をサーバ１００に送信する。

［ステップＳ１１６］サーバ１００のアクセス制御部１４０がトークン発行要求を受信し、受信したトークン発行要求を認証部１３０に転送する。そして、認証部１３０は、関係に基づくトークン発行処理を行う。例えば認証部１３０は、まずトークンの正当性を検証する。なおトークンの正当性の検証は、例えば電子署名の技術などを用いて行われる。その後、認証部１３０は、サービスＢとの関係定義ｒｅｌ（Ａ，Ｂ）と、サービスＢでのユーザの役割ｒｏｌｅ（Ｂ，１）とに基づき、サービスＡにおけるユーザ２２の役割ｒｏｌｅ（Ａ，１）を証明するトークンＴを発行する。ここで、役割割当ポリシでは、関係ｒｅｌ（Ａ，Ｂ）で結ばれた先のサーバ２００で個人認証された、サービスＢ上で役割ｒｏｌｅ（Ｂ，１）のユーザに対して、役割ｒｏｌｅ（Ａ，１）を発行する旨が定義されているものとする。この場合、トークンＴは、例えば、トークンＴ（ｉｓｓｕｅｒ＝ａ，ｓｕｂｊｅｃｔ＝１，ｒｏｌｅ＝ｒｏｌｅ（Ａ，１））と表される。

例えば認証部１３０は、トークン発行要求に、サーバ２００が発行したトークンが付与されていることから、サーバ２００との関係に基づいて、サービスＡ上でのユーザ２２の役割を認定する。例えば認証部１３０は、関係定義テーブル１２２の相手のＵＲＬの欄から、サーバ２００が発行したトークンに示されるサーバの識別子に対応するレコードを検索する。次に認証部１３０は、該当するレコードにおける相手との関係を、サーバ２００との関係と判断する。次に認証部１３０は、役割割当ポリシ定義テーブル１２３内の相手との関係の欄と相手が認めた役割の欄とから、サーバ２００との関係と、サーバ２００が発行したトークンに示された役割との組に対応するレコードを検索する。次に認証部１３０は、該当するレコードの、自身が認める役割を取得する。さらに認証部１３０は、取得した役割を、サービスＡ上でのユーザ２２の役割として認定する。そして認証部１３０は、認定した役割を付与したトークンを生成する。

［ステップＳ１１７］サーバ１００の認証部１３０は、サービスＡ上の役割が記された、サービスＡ用のトークンを、アクセス制御部１４０を介して端末装置３２に送信する。
［ステップＳ１１８］端末装置３２のアプリケーション３２ａは、サーバＡから取得したサービスＡ用のトークンを付与した、サービスＡのサービス要求を生成する。そしてアプリケーション３２ａは、サービスＡのサービス要求をサーバ１００に送信する。

［ステップＳ１１９］サーバ１００のアクセス制御部１４０は、サービス要求に示されるユーザ２２の役割に応じたサービスの範囲内での処理を実行し、処理結果を応答する。例えばアクセス制御部１４０は、サービス定義テーブル１２４から、サービス要求に示される役割のレコードを検索する。次にアクセス制御部１４０は、該当するレコードに定義されたサービス内容に基づき、ユーザ２２に対して許容できるサービスの範囲を認識する。そしてアクセス制御部１４０は、許容できるサービスの範囲内で、サービス要求に応じた処理を実行し、実行結果を端末装置３２に送信する。例えばサービス要求がＤＢ１１０からの情報取得要求であれば、アクセス制御部１４０は、ユーザ２２の役割に応じた範囲内の情報をＤＢ１１０から取得し、取得した情報を端末装置３２に送信する。

［ステップＳ１２０］端末装置３２は、サーバ１００から処理結果の応答を受信すると、処理結果をモニタ１１に表示する。
このようにして、サーバ２００にアカウントを有するユーザ２２が、サーバ１００のサービスを利用することができる。このときサーバ１００においてユーザ２２に提供されるサービスの内容は、サービスＢ上でのユーザ２２の役割と、サーバ１００とサーバ２００との間の関係定義に基づいて決定される。その結果、サーバ１００は、ユーザ２２に対して適切な範囲でのサービスを提供することができる。

次に、サーバにおける、自身が認証したユーザへのトークン発行処理の手順について、詳細に説明する。
図１４は、自身が認証したユーザへのトークン発行処理の手順の一例を示すフローチャートである。以下、図１４に示す処理をステップ番号に沿って説明する。なお、以下の処理は、既にユーザ認証を受けたユーザ２２が使用する端末装置３２から、トークン発行要求を受信した際に実行される。

［ステップＳ１３１］認証部２３０は、現セッションの認証済みのユーザをｕとする。
［ステップＳ１３２］認証部２３０は、ユーザ管理テーブル１２１から、ユーザｕに対応するレコードを検索し、ユーザの役割ｒＢを決定する。

［ステップＳ１３３］認証部２３０は、サーバ２００自身を発行者、役割をｒＢとして、トークンを生成する。
［ステップＳ１３４］認証部２３０は、割り当てる役割があるか否かを判断する。例えば認証部２３０は、ステップＳ１３２の検索において検出したレコードに、役割が設定されていれば、役割があると判断する。また認証部２３０は、ステップＳ１３２の検索において検出したレコードに、役割が設定されていなければ、役割がないと判断する。認証部２３０は、割り当てるべき役割がある場合、処理をステップＳ１３５に進める。また認証部２３０は、割り当てるべき役割がない場合、トークンを送信せずに処理を終了する。

［ステップＳ１３５］認証部２３０は、ステップＳ１３３で生成したトークンを、端末装置３２に送信する。
このような手順で、ユーザ２２がアカウントを有するサーバ２００においてトークンが発行される。

次に、サーバ２００で発行されたトークンを添付したトークン発行要求に応じてサーバ１００が実行する、他のサーバとの間の関係に基づくトークン発行処理の手順について説明する。

図１５は、関係に基づくトークン発行処理の手順の一例を示すフローチャートである。以下、図１５に示す処理をステップ番号に沿って説明する。
［ステップＳ１４１］認証部１３０は、サーバ２００で発行されたトークンを取得する。

［ステップＳ１４２］認証部１３０は、取得したトークンが有効か否かを判断する。例えば認証部１３０は、正当な電子署名が付与されていれば、有効なトークンであると判断する。認証部１３０は、有効なトークンであれば、処理をステップＳ１４３に進める。また認証部１３０は、無効なトークンであれば、トークンを発行せずに処理を終了する。

［ステップＳ１４３］認証部１３０は、トークンを生成する。この処理の詳細は後述する（図１６参照）。
［ステップＳ１４４］認証部１３０は、割り当てるべき役割があるか否かを判断する。例えば認証部１３０は、トークン生成処理の結果、サービスＡにおける役割が設定されたトークンが生成されていれば、役割があると判断する。また認証部１３０は、トークン生成処理において、役割がないためにトークンの生成に失敗した場合、役割がないと判断する。認証部１３０は、役割があれば処理をステップＳ１４５に進める。また認証部１３０は、役割がなければ、トークンを発行せずに処理を終了する。

［ステップＳ１４５］認証部１３０は、ステップＳ１４３で生成したトークンを端末装置３２に送信する。
次に、トークン生成処理の詳細について説明する。

図１６は、トークン生成処理の手順の一例を示すフローチャートである。以下、図１６に示す処理をステップ番号に沿って説明する。
［ステップＳ１５１］認証部１３０は、入力されたトークンで示される役割をｒＢとする。

［ステップＳ１５２］認証部１３０は、入力されたトークンの発行者をＩとする。
［ステップＳ１５３］認証部１３０は、発行者Ｉを関係定義テーブル１２２内の関係定義と照合し、一致するレコードに示された相手との関係を、Ｒとする。

［ステップＳ１５４］認証部１３０は、役割ｒＢと関係Ｒとの組に合致する役割割当ポリシを、役割割当ポリシ定義テーブル１２３から検索する。そして認証部１３０は、該当するレコードに自身が認める役割を取得し、役割ｒＡとする。

［ステップＳ１５５］認証部１３０は、自身を発行者、役割をｒＡとして、電子署名を施したトークンを生成する。なお、生成するトークンのアクセス主体には、入力されたトークンに示されるアクセス主体が設定される。

このようにして、サーバ２００において認証を受けたユーザ２２は、サーバ２００で提供されるサービスＢ上の役割に応じて、サーバ１００で提供されるサービスＡの役割の割り当てを受けることができる。ユーザ２２に対して割り当てられる役割は、サーバ１００とサーバ２００との関係と、サーバ２００で提供されるサービスＢ上でのユーザ２２の役割との組に応じて決定される。

なお、サーバ１００との間で直接的な関係が定義されていないサーバ３００にアカウントを有するユーザ２３であっても、連鎖的に役割の割り当てを受けることで、サーバ１００が提供するサービスＡの利用が可能となる。以下、役割を連鎖させることによるサービス提供処理について説明する。

図１７は、役割を連鎖させたサービス提供処理の手順の一例を示すシーケンス図である。図１７には、サーバ３００にアカウントを有するユーザ２３が、サーバ１００で提供されるサービスを利用する場合の例が示されている。なお、図１７に示す処理では、既にユーザ２３は、端末装置３３を用いてサーバ３００からユーザ認証を受け、ユーザ２３のサービスＣ上の役割が確定しているものとする。また、サーバ１００の識別子は「ａ」、サーバ２００の識別子は「ｂ」、サーバ３００の識別子は「ｃ」、ユーザ２３の識別子は「２」であるものとする。さらに、アプリケーション３３ａには、サーバ３００とサーバ１００とは、サーバ２００を間に挟んだ間接的な関係を有していることが、予め定義されているものとする。

［ステップＳ１６１］ユーザ２３は、端末装置３３を操作し、アプリケーション３３ａに対して、サービスＡへのアクセスが必要となる処理を指示する。
［ステップＳ１６２］端末装置３３のアプリケーション３３ａは、ユーザ２３の操作に応答し、トークン発行要求をサーバ３００に送信する。

［ステップＳ１６３］サーバ３００では、アクセス制御部３４０がトークン発行要求を受信し、受信したトークン発行要求を認証部３３０に転送する。すると認証部３３０は、サービスＣにおける役割ｒｏｌｅ（Ｃ，１）を証明するトークンＴ（ｉｓｓｕｅｒ＝ｃ，ｓｕｂｊｅｃｔ＝２，ｒｏｌｅ＝ｒｏｌｅ（Ｃ，２））を発行する。

［ステップＳ１６４］サーバ３００の認証部３３０は、サービスＣ上の役割が記された、サービスＣ用のトークンを、アクセス制御部３４０を介して端末装置３３に送信する。
［ステップＳ１６５］端末装置３３のアプリケーション３３ａは、サーバ３００から取得したサービスＣ用のトークンを付与した、サービスＢのトークン発行要求を生成する。そしてアプリケーション３３ａは、サービスＢのトークン発行要求をサーバ２００に送信する。

［ステップＳ１６６］サーバ２００のアクセス制御部２４０がトークン発行要求を受信し、受信したトークン発行要求を認証部２３０に転送する。そして、認証部２３０が、トークンの正当性を検証する。その後、認証部２３０は、サービスＣとの関係定義ｒｅｌ（Ｂ，Ｃ）に基づく役割割当ポリシに基づき、サービスＢにおけるユーザ２３の役割ｒｏｌｅ（Ｂ，２）を証明するトークンＴを発行する。トークンＴは、例えばトークンＴ（ｉｓｓｕｅｒ＝ｂ，ｓｕｂｊｅｃｔ＝２，ｒｏｌｅ＝ｒｏｌｅ（Ｂ，２））と表される。

［ステップＳ１６７］サーバ２００の認証部２３０は、サービスＢ上の役割が記された、サービスＢ用のトークンを、アクセス制御部２４０を介して端末装置３３に送信する。
［ステップＳ１６８］端末装置３３のアプリケーション３３ａは、サーバ２００から取得したサービスＢ用のトークンを付与した、サービスＡのトークン発行要求を生成する。そしてアプリケーション３３ａは、サービスＡのトークン発行要求をサーバ１００に送信する。

［ステップＳ１６９］サーバ１００のアクセス制御部１４０がトークン発行要求を受信し、受信したトークン発行要求を認証部１３０に転送する。そして、認証部１３０が、トークンの正当性を検証する。その後、認証部１３０は、サービスＢとの関係定義ｒｅｌ（Ａ，Ｂ）に基づく役割割当ポリシに基づき、サービスＡにおけるユーザ２３の役割ｒｏｌｅ（Ａ，１）を証明するトークンＴを発行する。トークンＴは、例えばトークンＴ（ｉｓｓｕｅｒ＝ａ，ｓｕｂｊｅｃｔ＝１，ｒｏｌｅ＝ｒｏｌｅ（Ａ，１））と表される。

［ステップＳ１７０］サーバ１００の認証部１３０は、サービスＡ上の役割が記された、サービスＡ用のトークンを、アクセス制御部１４０を介して端末装置３３に送信する。
［ステップＳ１７１］端末装置３３のアプリケーション３３ａは、サーバＡから取得したサービスＡ用のトークンを付与した、サービスＡのサービス要求を生成する。そしてアプリケーション３３ａは、サービスＡのサービス要求をサーバ１００に送信する。

［ステップＳ１７２］サーバ１００のアクセス制御部１４０は、サービス要求に示されるユーザ２３の役割に応じたサービスの範囲内での処理を実行し、処理結果を応答する。
［ステップＳ１７３］端末装置３３は、サーバ１００から処理結果の応答を受信すると、処理結果をモニタ１１に表示する。

このようにして、役割の割り当てを連鎖させ、サーバ１００と直接的には関係を有していないサーバ３００のユーザ２３に対して、サーバ１００がサービスＡを提供できる。しかも、サーバ１００とサーバ２００との関係、サーバ２００とサーバ３００との関係、およびサーバ３００が提供するサービスＣ上でのユーザ２３の役割に応じて、提供されるサービスの内容が決定される。これにより、アカウントを有するサーバが異なれば、アカウントを有するサーバで割り当てられた役割が同じユーザであっても、異なるサービスが提供される。

以下に、複数のサービスを連携させて実行する業務の例について説明する。
図１８は、複数のサービスを連携させて実行する業務の一例を示す図である。図１８には、典型的なソフトウェア開発プロジェクトにおけるサービスの連携例が示されている。

例えば、元請企業１社、下請企業３社、孫請企業９社によってソフトウェア開発プロジェクトが進められている。それぞれの会社には、複数のプロジェクト従事者がいる。
サーバ１００は、元請企業が管理している。サーバ２００，２００ａ，２００ｂは、下請企業が管理している。サーバ３００，３００ａ，３００ｂ，３００ｃ，３００ｄ，３００ｅ，３００ｆ，３００ｇ，３００ｈは、孫請企業が管理している。各サーバには、管理している企業内のプロジェクト従事者のアカウント情報（例えばユーザＩＤとパスワード）が登録されている。各サーバは、登録されたアカウント情報を用いて、そのサーバを管理している企業の管理職や社員などのユーザ認証を行う。

サーバ１００には、サーバ２００との間の関係として「子会社」と定義されている。逆に、サーバ２００には、サーバ１００との間の関係として「親会社」と定義されている。またサーバ２００には、サーバ３００との間の関係として「子会社」と定義されている。逆に、サーバ３００には、サーバ２００との間の関係として「親会社」と定義されている。サーバ２００には、ユーザ２２の役割として「社員」と定義されている。またサーバ３００には、ユーザ２３の役割として「社員」と定義されている。

このような関係定義が設定されている状況下で、元請企業のサーバ１００のＤＢ１１０に、プロジェクト従事者間で共有する情報（共有情報１１１）が格納されている。この場合、元請企業のサーバ１００は、サーバ２００で認証されたユーザ２２の使用する端末装置３２から、「社員」の役割を示すトークンが付与されたトークン発行要求を受信すると、「子会社の社員」という役割を示すトークンを発行する。するとユーザ２２は、サーバ１００で管理される共有情報１１１における、「子会社の社員」という役割に対して許容される範囲の情報に対してアクセス可能となる。

また下請企業のサーバ２００は、サーバ３００で認証されたユーザ２３の使用する端末装置３３から、「社員」の役割を示すトークンが付与されたトークン発行要求を受信すると、「子会社の社員」という役割を示すトークンを発行する。その後、元請企業のサーバ１００は、端末装置３３から、「子会社の社員」の役割を示すトークンが付与されたトークン発行要求を受信すると、「孫会社の社員」という役割を示すトークンを発行する。するとユーザ２３は、サーバ１００で管理される共有情報１１１における、「孫会社の社員」という役割に対して許容される範囲の情報に対してアクセス可能となる。

このようにして、元請企業のサーバ１００において、プロジェクトの全メンバのアカウントを集中管理せずに、各メンバから共有情報１１１へのアクセスを許容することが可能となる。しかも、元請企業と、各メンバが所属する企業との関係、および各メンバの所属企業内での役割に応じて、共有情報１１１へのアクセス制限を行うことが可能である。すなわち、元請企業のサーバ１００で、全メンバのアカウントを管理せずに、各メンバから共有情報１１１へのきめ細かいアクセス制御が可能となる。

また第２の実施の形態では、ユーザのアカウントを有するサーバでは、予めユーザ認証に成功したユーザからのトークン発行要求に応じて、サービス上の役割が示されたトークンを発行する。それ以前は、サーバは、認証したユーザの端末装置に対して、例えば、図１２に示すトークン４０中の発行者が認めた役割リスト４２を含まないトークンを渡しておくことができる。このようなトークンは、図１２に示したトークン４０よりもデータ量が少なくてすむ。ユーザが使用する端末装置は、このようなデータ量の少ないトークンを付与したアクセス要求を、ユーザ認証を受けたサーバに送信する。これにより、ユーザ認証を受けたサーバから、役割に応じたサービスの提供を受けることができる。このようにすることで、自己のアカウントがあるサーバで提供されるサービスを利用する限りにおいては、データ量の少ないトークンを用いることができ、処理効率が向上する。

〔第３の実施の形態〕
次に第３の実施の形態について説明する。第３の実施の形態は、ユーザ認証と同時に、連携用の最初のトークンを発行するようにしたものである。なお第３の実施の形態を実現するシステム構成は、第２の実施の形態と同様である。そこで、図２〜図１２に示した第２の実施の形態の各要素の符号を用いて、第３の実施の形態における第２の実施の形態と異なる処理を説明する。

第２の実施の形態では、既に認証を受けたユーザが使用する端末装置からトークン発行要求が出力された場合に、サーバにおいてトークンが発行される。他方、第３の実施の形態では、ユーザ認証時にトークンを発行する。これにより、トークン発行までの端末装置とサーバとの間の通信回数を減らすことができる。

図１９は、第３の実施の形態におけるサービス提供処理の手順の一例を示すシーケンス図である。図１３には、サーバ２００にアカウントを有するユーザ２２が、サーバ１００で提供されるサービスを利用する場合の例が示されている。

［ステップＳ１８１］ユーザ２２は、端末装置３２を操作し、アプリケーション３２ａに対して、ユーザＩＤとクレデンシャル（パスワードなど）を入力する。
［ステップＳ１８２］端末装置３２のアプリケーション３２ａは、ユーザ２２の操作に応答し、ユーザＩＤとクレデンシャルと組をサーバ２００に送信する。

［ステップＳ１８３］サーバ２００では、アクセス制御部２４０がユーザＩＤとクレデンシャルとの組を受信し、受信した情報を認証部２３０に転送する。すると認証部２３０は、ユーザＩＤとクレデンシャルとの組により、ユーザ認証を行う。例えば認証部２３０は、ユーザＩＤとクレデンシャルとの組に対応するレコードが、ユーザ管理テーブルに登録されていれば、ユーザ２２を正しいユーザであると認証する。

［ステップＳ１８４］認証部２３０は、ユーザ認証に成功した場合、認証部２３０は、ユーザ２２のサービスＢにおける役割を証明するトークンを発行する。
［ステップＳ１８５］サーバ２００の認証部２３０は、サービスＢ上の役割が記された、サービスＢ用のトークンを、アクセス制御部２４０を介して端末装置３２に送信する。

［ステップＳ１８６］端末装置３２のアプリケーション３２ａは、サーバ２００から取得したサービスＢ用のトークンをＲＡＭなどのメモリ内に記憶する。
［ステップＳ１８７］アプリケーション３２ａは、モニタ１１に認証成功通知を表示する。

［ステップＳ１８８］ユーザ２２は、端末装置３２を操作し、アプリケーション３２ａに対して、サービスＡへのアクセスが必要となる処理を指示する。
［ステップＳ１８９］端末装置３２のアプリケーション３２ａは、ユーザ２２の操作に応答し、トークン発行要求をサーバ２００に送信する。

以降、ステップＳ１９０〜Ｓ１９４の処理は、図１３に示したステップＳ１１５〜Ｓ１２０の処理と同様である。
このようにして、ユーザ認証と同時にトークンを発行し、通信回数を削減することができる。

〔第４の実施の形態〕
次に第４の実施の形態について説明する。第４の実施の形態は、トークンに対して、そのトークンを役割認証の連携に使用可能な他のサーバを特定する情報（宛先）を付与するものである。各サーバは、他のサーバで発行されたトークンが付与されたトークン発行要求を受信した場合、付与されたトークンに示される宛先に自分が指定されている場合にのみ、トークンを発行する。これにより、トークンの悪用を抑止できる。

例えば、サービスＢを提供するサーバ２００において、情報の機密性が十分に確保できていない場合、サーバ２００で発行されたトークンが、悪意のある第三者に漏洩する可能性がある。第２，第３の実施の形態では、悪意のある第三者は、不正に取得したトークンを用いて、サーバ２００にアカウントを有するユーザになりすますことが可能となる。すなわち、悪意のある第三者は、サーバ２００との間に信頼関係に基づく関係定義が設定されたすべてのサーバからサービスの提供を受けることが可能となる。そこで、第４の実施の形態では、トークンに宛先を含めることで、このようなサービスの不正利用を抑止する。

なお第４の実施の形態を実現するシステム構成は、第２の実施の形態と同様である。そこで、図２〜図１２に示した第２の実施の形態の各要素の符号を用いて、第４の実施の形態における第２の実施の形態と異なる部分を説明する。

図２０は、第４の実施の形態におけるトークンに含まれる情報の一例を示す図である。トークン５０には、トークン発行者５１、発行者が認めた役割リスト５２、トークンの宛先５３、アクセス主体５４、および電子署名５５が含まれる。トークン発行者５１、発行者が認めた役割リスト５２、アクセス主体５４、および電子署名５５については、図１２に示した第２の実施の形態におけるトークン４０内の同名の情報と同様の情報である。

トークンの宛先５３は、トークン５０を利用できるサーバの識別情報である。例えば、トークン５０を利用できるサーバのＵＲＬが、トークンの宛先５３として設定される。
以下、役割に応じたサービス提供手順について説明する。

図２１は、サービス提供処理の手順の一例を示すシーケンス図である。図２１には、サーバ２００にアカウントを有するユーザ２２が、サーバ１００で提供されるサービスを利用する場合の例が示されている。なお、図２１に示す処理では、既にユーザ２２は、端末装置３２を用いてサーバ２００からユーザ認証を受け、ユーザ２２のサービスＢ上の役割が確定しているものとする。

［ステップＳ２０１］ユーザ２２は、端末装置３２を操作し、アプリケーション３２ａに対して、サービスＡへのアクセスが必要となる処理を指示する。
［ステップＳ２０２］端末装置３２のアプリケーション３２ａは、ユーザ２２の操作に応答し、サービスＡ宛のトークンの発行を要求する、トークン発行要求をサーバ２００に送信する。すなわち、トークン発行要求には、発行するトークンの宛先を示す情報が含まれる。

［ステップＳ２０３］サーバ２００では、アクセス制御部２４０がトークン発行要求を受信し、受信したトークン発行要求を認証部２３０に転送する。すると認証部２３０は、ユーザ２２のサービスＢにおける役割を証明するとともに、サービスＡを宛先とする宛先指定のトークンを発行する。

［ステップＳ２０４］サーバ２００の認証部２３０は、サービスＢ上の役割とサービスＡが宛先であることとが記されたトークンを、アクセス制御部２４０を介して端末装置３２に送信する。

［ステップＳ２０５］端末装置３２のアプリケーション３２ａは、サービスＡを宛先とするトークンを付与した、サービスＡのトークン発行要求を生成する。そしてアプリケーション３２ａは、サービスＡのトークン発行要求をサーバ１００に送信する。

［ステップＳ２０６］サーバ１００のアクセス制御部１４０がトークン発行要求を受信し、受信したトークン発行要求を認証部１３０に転送する。そして、認証部１３０が、付与されたトークンの正当性と、そのトークンの宛先がサービスＡであることを検証する認証部１３０は、サービスＡ宛の正当なトークンが付与されていることを確認後、サービスＡにおけるユーザ２２の役割を証明するトークンを発行する。

その後のステップＳ２０７〜ステップＳ２１０の処理は、それぞれ図１３に示した第２の実施の形態におけるステップＳ１１７〜ステップＳ１２０の処理と同様である。
このようにして、宛先指定のトークンを用いて認証連携を行うことで、サーバ２００で発行したサービスＡ宛のトークンは、サービスＡを提供するサーバ１００でしか使用できなくなる。その結果、１つのサーバから取得したトークンが、宛先以外のサービスに利用されることを抑止できる。すなわちトークンの不正使用が抑止される。

宛先指定のトークンを用いて、役割の割り当てを連鎖させることもできる。
図２２は、宛先指定のトークンによる役割連鎖によるサービス提供処理の一例を示すシーケンス図である。図２２には、サーバ３００にアカウントを有するユーザ２３が、サーバ１００で提供されるサービスを利用する場合の例が示されている。なお、図２２に示す処理では、既にユーザ２３は、端末装置３３を用いてサーバ３００からユーザ認証を受け、ユーザ２３のサービスＣ上の役割が確定しているものとする。またアプリケーション３３ａには、サービスＣとサービスＢとの間に関係が定義され、サービスＢとサービスＡとの間に関係が定義されていること、サービスＣとサービスＡとの間には関係が定義されていないことが、予め設定されている。そしてアプリケーション３３ａは、サーバ３００にアカウントを有するユーザがサービスＡを利用するには、サービスＣ、サービスＢ、サービスＡの順で、連鎖的に役割の割り当てを受ける必要があることを認識しているものとする。

［ステップＳ２２１］ユーザ２３は、端末装置３３を操作し、アプリケーション３３ａに対して、サービスＡへのアクセスが必要となる処理を指示する。
［ステップＳ２２２］端末装置３３のアプリケーション３３ａは、ユーザ２３の操作に応答し、サービスＢ宛のトークンの発行を要求する、トークン発行要求をサーバ３００に送信する。すなわち、トークン発行要求には、発行するトークンの宛先を示す情報が含まれる。

［ステップＳ２２３］サーバ３００では、アクセス制御部３４０がトークン発行要求を受信し、受信したトークン発行要求を認証部３３０に転送する。すると認証部３３０は、ユーザ２３のサービスＣにおける役割を証明するとともに、サービＢを宛先とする宛先指定のトークンを発行する。

［ステップＳ２２４］サーバ３００の認証部３３０は、サービスＣ上の役割とサービスＢが宛先であることとが記されたトークンを、アクセス制御部３４０を介して端末装置３３に送信する。

［ステップＳ２２５］端末装置３３のアプリケーション３３ａは、サービスＢを宛先とするトークンを付与し、サービスＡ宛のトークン発行要求を生成する。そしてアプリケーション３３ａは、サービスＡ宛のトークン発行要求をサーバ２００に送信する。

［ステップＳ２２６］サーバ２００では、アクセス制御部２４０がトークン発行要求を受信し、受信したトークン発行要求を認証部２３０に転送する。すると認証部１３０が、付与されたトークンの正当性と、付与されたトークンの宛先がサービスＢであることを検証する認証部１３０は、サービスＢ宛の正当なトークンが付与されていることを確認後、ユーザ２３のサービスＢにおける役割を証明するとともに、サービスＡを宛先とする宛先指定のトークンを発行する。

その後のステップＳ２２７〜ステップＳ２３３の処理は、それぞれ図２１に示したステップＳ２０４〜ステップＳ２１０の処理と同様である。
このようにして、役割指定のトークンについても、役割を連鎖させたサービスの提供が可能となる。

次に、サーバ２００における宛先指定のトークン発行処理について詳細に説明する。
図２３は、第４の実施の形態における関係に基づくトークン発行処理の手順の一例を示すフローチャートである。図２３に示す処理のうち、ステップＳ２４１，Ｓ２４３，Ｓ２４６，Ｓ２４７の各処理は、それぞれ図１５に示した第２の実施の形態の処理のステップＳ１４１，Ｓ１４２，Ｓ１４４，Ｓ１４５と同様である。第２の実施の形態と異なるのは、ステップＳ２４２，Ｓ２４４，Ｓ２４５の処理である。ステップＳ２４２，Ｓ２４４，Ｓ２４５の処理は以下の通りである。

［ステップＳ２４２］認証部２３０は、トークン発行要求に示された宛先を取り出し、Ｔとする。
［ステップＳ２４４］認証部２３０は、トークン発行要求に付与されたトークンの宛先が、サーバ１００自身であるか否かを判断する。例えば認証部２３０は、宛先がＵＲＬで示されている場合、宛先のＵＲＬが、サーバ１００のＵＲＬであれば、宛先が自分であると判断する。認証部２３０は、宛先が自分であれば、処理をステップＳ２４５に進め、トークンの生成、発行処理を行う。また認証部２３０は、宛先が自分でなければ、トークンを発行せずに処理を終了する。

［ステップＳ２４５］認証部２３０は、宛先指定トークンを生成する。この処理の詳細を以下に示す。
図２４は、宛先指定トークン生成処理の手順の一例を示すフローチャートである。図２４に示す処理のうち、ステップＳ２５１〜Ｓ２５４の各処理は、それぞれ図１６に示した第２の実施の形態の処理のステップＳ１５１〜Ｓ１５４と同様である。第２の実施の形態と異なるのは、ステップＳ２５５の処理である。ステップＳ２５５の処理は以下の通りである。

［ステップＳ２５５］認証部２３０は、自身を発行者、役割をｒＡ、トークンの宛先をＴとして、電子署名を施したトークンを生成する。なお、生成するトークンのアクセス主体には、入力されたトークンに示されるアクセス主体が設定される。

以上のようにして、トークンに宛先を含め、他のサーバで発行されたトークンが付与されたトークン発行要求を取得した場合には、付与されたトークンの宛先が自分宛の場合にのみ、トークン発行要求を送信したユーザに対してサービスへの役割の設定が行われる。これにより、あるサービスの利用者に成りすまして、そのサービスとの間で関係が定義されたすべてのサービスを不正に利用するような行為を抑止することができる。

〔その他の実施の形態〕
端末装置上で動作するアプリケーションは、ＯＳネイティブのアプリケーションでもよく、ブラウザ上で動作するアプリケーションでもよい。

また上記の実施の形態では、サービス間の関係の例として、企業間の資本関係を用いたが、サービス間の関係は、企業間の関係には限定されない。例えば、自治体の保健所のサーバに対して、病院の医師が、市立病院内のサーバでユーザ認証を受けてアクセスする場合、保健所と病院との関係が、サービス間の関係として定義される。例えば、市立病院の医師（役割：医師）からの保健所のサーバのＤＢへのアクセスの許容範囲と、個人病院の医師（役割：医師）からの保健所のサーバのＤＢへのアクセスの許容範囲とを異ならせることができる。

上記の各実施の形態に示した処理機能は、コンピュータによって実現することができる。その場合、端末装置３１，３２，３３やサーバ１００，２００，３００が有する機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、磁気記憶装置、光ディスク、光磁気記録媒体、半導体メモリなどがある。磁気記憶装置には、ハードディスク装置（ＨＤＤ）、フレキシブルディスク（ＦＤ）、磁気テープなどがある。光ディスクには、ＤＶＤ、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ／ＲＷなどがある。光磁気記録媒体には、ＭＯ（Magneto-Optical disk）などがある。なおプログラムを記録する記録媒体には、一時的な伝搬信号自体は含まれない。

プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ、ＣＤ−ＲＯＭなどの可搬型記録媒体が販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。

プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムに従った処理を実行することもできる。

また、上記の処理機能の少なくとも一部を、ＤＳＰ（Digital Signal Processor）、ＡＳＩＣ（Application Specific Integrated Circuit）、ＰＬＤ（Programmable Logic Device）などの電子回路で実現することもできる。

以上、実施の形態を例示したが、実施の形態で示した各部の構成は同様の機能を有する他のものに置換することができる。また、他の任意の構成物や工程が付加されてもよい。さらに、前述した実施の形態のうちの任意の２以上の構成（特徴）を組み合わせたものであってもよい。

１，２ 情報処理装置
１ａ，２ａ 記憶手段
１ａａ，２ａａ 役割定義
１ａｂ，２ａｂ 関係情報
１ａｃ，２ａｃ 役割割当ポリシ
１ａｄ，２ａｄ サービス定義
１ｂ，２ｂ 認証手段
１ｃ，２ｃ 役割情報発行手段
１ｄ，２ｄ 受信手段
１ｅ，２ｅ 判断手段
１ｆ，２ｆ 決定手段
１ｇ，２ｇ 処理手段
３ 端末装置
３ａ 認証要求手段
３ｂ 役割情報取得手段
３ｃ 処理要求手段
４ ユーザ

Claims (9)

1. 情報処理装置が、
   他の情報処理装置で提供される第２のサービスと、該第２のサービス上のユーザの役割とが示された役割情報を、該ユーザが使用する端末装置から受信し、
   前記他の情報処理装置により提供される前記第２のサービスに対応付けて、自装置と該他の情報処理装置との間の関係が示された関係情報を参照し、該自装置で提供する第１のサービスと、前記受信した役割情報に示される前記第２のサービスとの間の関係を判断し、
   前記第１のサービスと前記第２のサービスとの間の関係と、該第２のサービス上の役割との組み合わせに対応する、前記第１のサービス上における役割を定義した役割割当ポリシを参照し、前記判断された関係と、前記受信した役割情報に示された役割との組み合わせに応じて、前記受信した役割情報の送信元の端末装置を使用するユーザの前記第１のサービス上の役割を決定する、
   ことを特徴とするサービス提供方法。
2. 前記情報処理装置が、さらに、
   役割に応じて許容される、自装置で提供するサービスの範囲が定義されたサービス定義を参照し、前記決定した役割に応じて許容されるサービスの範囲内で、前記第１のサービスの処理を実行する、
   処理を実行することを特徴とする請求項１記載のサービス提供方法。
3. 前記情報処理装置が、さらに、
   前記第１のサービスと前記決定した役割とを示す役割情報を、前記端末装置に送信する、
   処理を実行することを特徴とする請求項１または２のいずれかに記載のサービス提供方法。
4. 前記情報処理装置が、さらに、
   前記第１のサービス上の役割を示す役割情報を付与した処理要求を受信すると、役割に応じて許容されるサービスの範囲が定義されたサービス定義を参照し、該処理要求に示される役割に応じて許容されるサービスの範囲内で、前記第１のサービスの処理を実行する、
   処理を実行することを特徴とする請求項３記載のサービス提供方法。
5. 前記情報処理装置が、
   役割情報の受信では、宛先となるサービスが指定された役割情報を受信し、
   役割の決定では、前記受信した役割情報の宛先となるサービスが前記第１のサービスである場合に、前記受信した役割情報の送信元の端末装置を使用するユーザの前記第１のサービス上の役割を決定する、
   ことを特徴とする請求項１乃至４のいずれかに記載のサービス提供方法。
6. 前記情報処理装置が、さらに、
   ユーザが使用する端末装置からの認証要求に応じて、該ユーザのユーザ認証を行い、
   ユーザ認証に成功した場合、ユーザごとの前記第１のサービス上の役割を示す役割定義を参照し、前記第１のサービス上の該認証要求の送信元の端末装置を使用するユーザの役割を決定し、前記第１のサービスと該決定した役割とを示す役割情報を、前記端末装置に送信する、
   処理を実行することを特徴とする請求項１乃至５のいずれかに記載のサービス提供方法。
7. 前記情報処理装置が、
   役割情報の送信では、宛先となるサービスを指定した役割情報を送信する、
   ことを特徴とする請求項６記載のサービス提供方法。
8. 情報処理装置に、
   他の情報処理装置で提供される第２のサービスと、該第２のサービス上のユーザの役割とが示された役割情報を、該ユーザが使用する端末装置から受信し、
   前記他の情報処理装置により提供される前記第２のサービスに対応付けて、自装置と該他の情報処理装置との間の関係が示された関係情報を参照し、該自装置で提供する第１のサービスと、前記受信した役割情報に示される前記第２のサービスとの間の関係を判断し、
   前記第１のサービスと前記第２のサービスとの間の関係と、該第２のサービス上の役割との組み合わせに対応する、前記第１のサービス上の役割を定義した役割割当ポリシを参照し、前記判断された関係と、前記受信した役割情報に示された役割との組み合わせに応じて、前記受信した役割情報の送信元の端末装置を使用するユーザの前記第１のサービス上の役割を決定する、
   処理を実行させるプログラム。
9. 他の情報処理装置で提供される第２のサービスと、該第２のサービス上のユーザの役割とが示された役割情報を、該ユーザが使用する端末装置から受信する受信手段と、
   前記他の情報処理装置により提供される前記第２のサービスに対応付けて、自装置と該他の情報処理装置との間の関係が示された関係情報を参照し、該自装置で提供する第１のサービスと、前記受信した役割情報に示される前記第２のサービスとの間の関係を判断する判断手段と、
   前記第１のサービスと第２のサービスとの間の関係と、該第２のサービス上の役割との組み合わせに対応する、前記第１のサービス上の役割を定義した役割割当ポリシを参照し、前記判断された関係と、前記受信した役割情報に示された役割との組み合わせに応じて、前記受信した役割情報の送信元の端末装置を使用するユーザの前記第１のサービス上の役割を決定する決定手段と、
   を有する情報処理装置。

Images