JP2012512450A - あるユーザに成り代わるための方法およびシステム - Google Patents

Abstract

【課題】本発明は、認証ユーザが別のユーザに成り代わってリソースを改変する方法を提供する。
【解決手段】該方法は、改変対象のリソースに対するロックを取得するステップと、該認証ユーザの身元情報および成り代わられたユーザの身元情報をロック・オブジェクトの内部に格納するステップと、該ロックが、別のユーザに成り代わった該認証ユーザによって成功裏に取得されたことを示すメッセージを生成するステップとを含む。
【選択図】図３

Description

本発明は、あるユーザに成り代わるための方法およびシステムに関し、さらに具体的には、別のユーザに成り代わったユーザがリソースを改変する方法に関する。

ＩＴ環境で、ユーザ認証は、ずいぶん前から専門化されたコンポーネントに委託されてきた。しかしながら、リソースにアクセスするためのユーザ認可は、この認可プロセスが、アプリケーションによって管理されているビジネス・ロジックおよびリソースの内容に大きく左右されるので、今でも一般に同じアプリケーション管理リソースによって管理されている。アプリケーションの複雑性が高まるにつれて、これらアプリケーションは、ユーザおよびユーザの分野の数が増大し、彼らの各々がアプリケーションに対し非常に異なった必要性を有することを考慮に入れざるを得なくなっている。しかして、特定のユーザに利用可能なユーザ・インタフェース、機能、およびビジネス・データは、多くのファクタによって決まり、これらのコンポーネントのどれが特定のユーザに利用可能かを判断するのがアプリケーション中の認可コンポーネントの役割となっている。上記に関連して、アプリケーションに関する問題を有するユーザは、その問題が該アプリケーションが特定のユーザに対しどのように調整されているかにつながっていて、そのため再現が困難なことがあり、トラブル・シューティングすることが難しくなってきている。

米国特許第７，２２５，２５６号

ユーザをサポートする管理者は、ユーザが経験した通りの経験をし、問題を正確に再現するためには、そのユーザのユーザ名とパスワードとが必要になろう。

２００７年５月２９日付でＶｉｌｌａｖｉｅｎｃｉｏに付与された特許文献１は、第一エンティティが、成り代わられた第二エンティティの身元情報に基づいてリソースにアクセスすることを許可するためのシステムを提供している。

本発明の第一態様によって、コンピュータ・システム中のリソースにアクセスする方法が提供され、該方法は、
− 第一および第二識別エレメントを包含する第一身元情報オブジェクトを受信するステップであって、各識別エレメントは、該コンピュータ・システムにおいて宣言された第一および第二ユーザをそれぞれ一意的に識別し、第一および第二ユーザは相異なる、上記受信するステップと、
− 第一ユーザからリソースを改変するための第一要求を受信するステップと、
− 第二ユーザがリソースを改変することを認可されているかどうかを検証するよう指示する第一メッセージを送信するステップであって、該第一メッセージは、第二識別エレメントおよびリソースへの参照を含む、上記送信するステップと、
− 上記検証に基づいて、第二ユーザがリソースを改変することを認可されているかどうかを示す第二メッセージを受信するステップと、
− 第二ユーザがリソースを改変することを認可されている場合は、
− 第一および第二識別エレメントを包含する第一ロック・アナンシエータ（ａｎｎｕｎｃｉａｔｏｒ）を設定するステップであって、該ロック・アナンシエータは、該リソースがロックされていることを示すようになされており、第一ユーザが第二ユーザに成り代わりながらリソースをロックしていることを証している、上記設定するステップと、
を含む。

この態様の利点は、誰が、別のユーザに成り代わらせながらリソースを改変しているかを把握するので、システムの安全性が高まることである。

第一態様の第一展開において、該方法は、
− 第一ユーザに対する身元ベリフィケータ（ｖｅｒｉｆｉｃａｔｏｒ）を受信するステップと、
− 第一ユーザを認証するよう指示する第三メッセージを送信するステップであって、該第三メッセージは、第一識別エレメントおよび身元ベリフィケータを包含する、上記送信するステップと、
− 該認証に基づいて第一ユーザが認証されているかどうかを示す、第四メッセージを受信するステップと、
をさらに含む。

利点は、該方法を実行するシステムの外部のシステムによって上記認証が行えることである。

第一態様の第二展開において、第一識別エレメントはユーザ名であり、身元ベリフィケータはパスワードである。

利点は、この情報がほとんどのアプリケーションに対して一般化していることである。

第一態様の第三展開において、該方法は、第二ユーザがリソースを改変することを認可された段階で、
− 該リソースが、第三および第四識別エレメントを包含する第二ロック・アナンシエータによって既にロックされていることを示す、第五メッセージを受信するステップと、
− 該第一識別エレメントと第三識別エレメントとが整合していることを検証するステップと、
− 該第二識別エレメントと第四識別エレメントとが相異なることを検証するステップと、
をさらに含む。

利点は、成り代わられるユーザに当初取得されていたロックを、上記認証ユーザに再割り当てできることである。これは、成り代わられるユーザが自分のアカウントの問題のためロックを解除できない場合のサポート環境において特に利点がある。

第一態様の第四展開において、該方法は、該第一および第二識別エレメントを包含する第六メッセージと、リソースへの参照と、タイムスタンプとを含む第二要求を送信するステップであって、該第二要求は、監査証跡（ａｕｄｉｔ ｔｒａｉｌ）に第六メッセージを記録するよう指示している、該送信するステップをさらに含む。

利点は、アプリケーションが、誰がリソースを改変したかを正しく把握していることである。通常の環境において、監査証跡は、成り代わり機能の特定の状況の如何にかかわらず、認証ユーザがリソースを改変したことを追跡記録することになる。

本発明の第二態様によって、本発明の第一態様による方法の各ステップを遂行するようになされた手段を含む装置が提供される。

利点は、この装置が極めてたやすく得られ、しかして上記方法の実行を容易にすることである。

本発明の第三態様によって、コンピュータ・プログラムがコンピュータ上で実行されるとき本発明の第一態様による方法の各ステップを遂行するための命令を含む該コンピュータ・プログラムが提供される。

利点は、本発明が容易に再生でき、いろいろなコンピュータ・システムで実行できることである。

本発明の第四態様によって、符号化された、本発明の第三態様によるコンピュータ・プログラムを有するコンピュータ可読媒体が提供される。

利点は、この媒体を使って、該方法をさまざまな装置に容易にインストールできることである。

当業者は、図面および詳細な説明を調べることによって、本発明のさらなる利点を明らかにできよう。本発明には任意の追加的な利点を組込むことが意図されている。

以降に、本発明の添付の図面を参照しながら、例証として本発明の実施形態を説明するものとし、図面中の類似の参照番号は類似のエレメントを示す。

本発明が実装可能なシステムを示す。 ユーザが特定のリソースにアクセスするのを認証し許可するプロセスのハイレベル図を示す。 本発明の実行における、ユーザによるリソースの改変を管理するためのプロセスを示す。 本発明の実行における、ユーザによるロックされたリソースの改変を管理するためのプロセスを示す。

図１は、
− アプリケーション（１００）と
− ユーザまたは外部システム（１１０）と、
− 認証システム（１２０）と、
を含むシステムを示す。
該アプリケーションは、以下のオブジェクトの一組、
− いくつかの機能オブジェクト（１４０）と、
− いくつかのリソース・オブジェクト（１５０）と、
− アプリケーションの認可コンポーネントと、
を含む。
アプリケーション（１００）は、安全な環境においてリソースを管理する、任意のコンピュータ・アプリケーションであり得る。該アプリケーションは、通常データベースに格納されたリソースの一組（１５０）へのアクセスを提供する。また、アプリケーション（１００）は、機能オブジェクト（１４０）によって実行される何らかのビジネス・ロジックおよびグラフィカル・ユーザ・インタフェースも提供する。リソース・オブジェクト（１５０）にアクセスする必要があり機能オブジェクト（１４０）中に包含されるビジネス・ロジックを利用する外部システムまたはユーザ（１１０）は、まず、認証システム（１２０）に認証されなければならない。アプリケーションは、認証システム（１２０）が行う認証に依存している。通常、外部システムまたはユーザ（１１０）は、アプリケーションにおいて、自分を一意的に代表する識別エレメントを提示することになる。この識別エレメントは、一般にはユーザ名であり、これはｅメール・アドレスまたは任意の番号であってもよい。外部システムは、要求している身元が真正であることを検証するための別のエレメントも提示することになる。これは、通常、パスワードなどユーザが知っているエレメントであるが、生体識別などのユーザの特徴、またはトークンに格納されたＩＤなどユーザが固有する何らかのものであればよい。これらのエレメントは、該ユーザに対応し、事前にシステムに格納されている身元情報オブジェクトと照合されることになる。認証システム（１２０）は、ユーザの身元を検証する責任を負う。一般に、このコンポーネントは、アクセスの制御を必要とするアプリケーション（１００）の外部にある。この認証システムは通常ＬＤＡＰである。これをアプリケーション自体のコンポーネントとすることもできる。
ユーザの身元が検証されたならば、アプリケーションは、該ユーザが要求するオブジェクト（１５０）へのアクセス、または要求する機能オブジェクト（１４０）に包含されるビジネス・ロジックの実行を確かに認可されているかどうかを管理することになる。リソース・オブジェクトは、短期のまたは長期の保存手段に格納することができる。これは、データベース・エントリ、ファイルなどさまざまなフォームで実装することができる。ビジネス・ロジックは、オブジェクト指向言語、手続き言語、関数型言語などを使って実装することができる。上記認可はアプリケーションにおけるユーザの権利に基づく。これは、ユーザがあるユーザ・クラスのメンバーであるという事実に基づくロール・ベースの認可など、さまざまな形を取ることができ、ＡＣＬ（ａｃｃｅｓｓ ｃｏｎｔｒｏｌ ｌｉｓｔ（アクセス制御リスト））などを使ってリソース・レベルでも権利の定義が可能な、インスタンス・ベースの認可とすることもでき、認可コンポーネントは、アプリケーション自体の一部とすることも、アプリケーションの外部のコンポーネントとすることも、あるいはこれら２つの組合せとすることもできる。例えば、ロール・ベースの認可は、Ｊ２ＥＥ環境におけるように、多くの場合アプリケーションの外部に実装されることになる。また一方、インスタンス・ベースの認可は、この別の認可モデルがアプリケーション中に実装された特定のビジネス・ロジックに深く関係しているので、多くの場合アプリケーションの内部に実装されることになる。ユーザが特定のリソースへのアクセスを認可されていることの点検は、一般に、ユーザ身元情報およびアクセスが要求されているオブジェクトの識別子を添えて認可コンポーネント（１６０）に要求を送信することによって行われる。本発明の実行において、上記認証ユーザは、前もってシステムで宣言された別のユーザに成り代わって処置をすることができる。これは、典型的には、システム管理者が、別のユーザがアプリケーションについて抱えている問題を解決しなければならないときに必要となる。こういったとき、非常に多くの場合において別のユーザが遭遇した問題を再現するのは困難である。システム管理者にとって明らかな代替策は、該別のユーザのユーザ名とパスワードとを使ってシステムに接続することである。さすれば、管理者は、別のユーザが経験していることを正確に知ることができよう。しかしながら、これは、パスワードを共用することが必要になるので、保安上の点からは問題がある。また、管理者が他の人としてシステムにログ・インするのに多大の時間を浪費することもあって非効率的でもある。本発明の実行において、アプリケーション（１００）は、外部ユーザ（１１０）に別のユーザに成り代わる可能性を提供する。この機能は、通常は管理者などシステム中のある特定のユーザに限定すべきである。また、ユーザはこの機能を臨時的に別のユーザに付与することもできる。本発明の実行において、外部ユーザ（１１０）が、別のユーザに成り代わりながらリソース・オブジェクト（１５０）または機能オブジェクト（１４０）へのアクセスを試みるとき、これらのオブジェクトへのアクセスの許可は該他のユーザの身元に対して行われることになる。かくして、該外部ユーザ（１１０）に対し、ユーザ・インタフェース・レベルであれ、ビジネス・ロジック・レベルであれ、またはデータ・レベルであれ、特定ユーザに固有であり何らかの認可を必要とする全てのエレメントは、あたかも該ユーザが成り代わったユーザとしてシステムに接続したかのように見えることになる。

図２は、ユーザが特定のリソースにアクセスするのを認証し認可するハイレベルでのプロセスを示し、該プロセスは、以下のアクテビティ、
− 開始アクテビティ（２００）と、
− ユーザがシステムにアクセスする過程のアクテビティ（２１０）と、
− 身元マネージャがユーザを認証する過程のアクテビティ（２２０）と、
− 該ユーザが認証されているかどうかを検証する判定アクテビティ（２３０）と、
− 認証されていない場合、ユーザに認証エラーを通知し（２４０）、プロセスを終了するアクテビティ（２４５）と、
− 認証されている場合、身元マネージャからのユーザの信用証明を使って、全てのロールに対する認可を点検するアクテビティ（２５０）と、
− アクセス・トークンを格納するアクテビティ（２６０）と、
− ユーザのロールがアクセスできる利用可能なリソースを識別するアクテビティ（２７０）と、
− ユーザがアクセス権を有するかどうかを検証する判定アクテビティ（２８０）と、
− 有しない場合、プロセスを終了するアクテビティ（２４５）と、
− 有する場合、成り代わり機能を有効にして（２９０）、プロセスを終了する（２４５）ステップと、
を含む。
ユーザがアプリケーション（１００）またはシステム（２１０）にアクセスをしようとするとき、該ユーザは自分の身元の証拠を提示しなければならない。これは、通常、ユーザ名およびパスワードである。このユーザ名は、ｅメール・アドレス、番号、または、システムもしくはアプリケーション（１００）において該ユーザを一意的に代表する任意の値とすることができる。パスワードは、アクセスを要求するユーザが真正であることの実証を可能にする。ユーザが認証されたならば、認証システム（１２０）は、ユーザ・セッション・オブジェクトを生成し、ユーザは、その後のシステムまたはアプリケーション（１００）に対する要求の中で該オブジェクトを用いることになる。ユーザ・セッション・オブジェクトは、通常、タイムアウト値を有し、異なるクライアント・システムの間で共有することはできない。本発明のある好適な実施形態において、ユーザ・セッション・オブジェクトは、ユーザＩＤなど、システムにおいて認証ユーザを一意的に代表する識別子を格納するための、ａｕｔｈｅｎｔｉｃａｔｅｄＵｓｅｒＳＮ（認証ユーザＳＮ）フィールド、および上記認証ユーザが成り代わる対象のユーザを一意的に代表する身元情報を格納するための、ａｕｔｈｏｒｉｓｅｄＵｓｅｒＳＮ（許可ユーザＳＮ）フィールドを含む。ユーザ・セッション・オブジェクトは、ユーザが成功裏に認証された（２３０）時点で生成される。生成される時点では、ａｕｔｈｅｎｔｉｃａｔｅｄＵｓｅｒＳＮとａｕｔｈｏｒｉｓｅｄＵｓｅｒＳＮとは、同じ値、すなわち認証ユーザのユーザＩＤに設定される。以降のアクテビティにおいて、アプリケーション（１００）は、ユーザの身元を知得して、該ユーザに関連するロール、リソースに関連するアクセス制御リスト、および、近年の多くのアプリケーションに見られるような他の認可ルールに基づいて、ユーザがアクセスできる利用可能なリソースを判定する（２７０）。ある好適な実施形態において、別のユーザに成り代わる機能（２９０）は、管理者の役割を有するユーザに限定される（２８０）。成り代わり機能を有効にすること（２９０）は、その機能に対応するビジネス・オブジェクトまたは機能オブジェクト（１４０）が、成り代わったユーザに対し利用可能になるという効用をもたらし、グラフィカル・ユーザ・インタフェースもこの機能を可能にする選択ができるように変更される。
成り代わり機能の実行のためには、第二ユーザの身元情報をインプットとして提示する必要がある。次いで、アクセス・トークンのａｕｔｈｏｒｉｓｅｄＵｓｅｒＳＮフィールドが、インプットとして提示された第二ユーザのユーザＩＤにセットされる。認証ユーザは、該第二ユーザの選択を、任意に、もしくは認証ユーザ、リソースのタイプ、リソース自体、現在の時刻等々などに基づいた何らかの事前設定ルールに従って、行うことができる。これら事前設定ルールは、選択肢がより少なくなるので、該機能に関連する安全リスクの限定を可能にする。また、別のユーザに成り代わる機能は、通常の勤務時間内に日常的に行われているようなサポート業務など、特定の状況に基づいて制限することもできる。成り代わり機能へのアクセスを持たせるユーザのクラスの選択は、本発明では限定しない。管理者クラスに加えて、この機能へのアクセスを有する、ユーザの特別なクラスを設けることもできる。管理者に加えこの機能を必要とする典型的なユーザとして、支援担当ユーザ、別のユーザから委任を受けているユーザなどがあり得る。

図３は、ユーザによるリソースの改変を管理するためのプロセスを示し、該プロセスは以下のアクテビティ、
− 開始アクテビティ（３００）と、
− ユーザからリソースにアクセスする要求を受信するアクテビティ（３１０）と、
− 認可されたユーザ・ロールに関連する利用可能なアクションを提示するアクテビティ（３２０）と、
− ユーザからアクションを実行する要求を受信するアクテビティ（３３０）と、
− 該要求が、リソースを変更または改変するためのものどうかを判定するアクテビティ（３４０）と、
− 変更・改変でない場合、該アクションを実行し（３７０）、アクセス・トークンとともに該アクションを監査証跡中に記録し（３８０）、プロセスを終了する（３６５）アクテビティと、
− リソースの改変または変更である場合、該リソースに対するロックを取得する（３５０）アクテビティと、
− ロックが取得された場合にあっては（３５６）、改変を実行し（３７０）、アクセス・トークンとともに該アクションを監査証跡中に記録し（３８０）、プロセスを終了する（３６５）アクテビティと、
− ロックが拒否された場合にあっては（３６０）、ユーザに通知し（３６０）、プロセスを終了する（３６５）アクテビティと、
を含む。
このプロセスの過程で、ユーザは、自分がアクセスできる利用可能なリソースのリストに目を通す（２１０）。該ユーザに利用可能なリソースのセットは、ユーザ・セッション・オブジェクト中のａｕｔｈｏｒｉｓｅｄＵｓｅｒＳＮの値に基づいている。アプリケーション（１００）は、ａｕｔｈｏｒｉｓｅｄＵｓｅｒＳＮフィールド中の値を使って、選択されたリソースに対しユーザに認可された全てのロールをクエリする。次いで、返答されたアプリケーション（１００）の各ロールに対しそのロールに関連するアクションをアクションの累積セットに加える。認証ユーザも、特定のリソース・オブジェクト（１５０）に対し利用可能なこれらアクション（１４０）を見知する。次いで、該ユーザはリソースを改変する許可を受けることができるが、かかるアクションは、該ユーザが別のユーザに成り代わっていなければ、該ユーザには利用できなかったものである。リソースへのアクセス許可に対し、ユーザ・セッション・オブジェクトのａｕｔｈｏｒｉｓｅｄＵｓｅｒＳＮフィールドへの考慮を、アプリケーションの改変に取り入れることは認可コンポーネント（１６０）において行うことができる。ユーザがリソースを変更することを認可されているかどうかの判定（３４０）は、そのリソースに関連するアクセス制御リストを、このユーザが、書き込みアクセスなど十分な許可レベルを有してこのアクセス制御リストの一員となっているかどうか検索することによって実施することができる。一部のアプリケーションは、ユーザが、リソースに関連するリンクの変更を可能にすることによって該リソース自体を改変できる、リンク許可などの中間許可を可能にしている。あるリソースまたはあるリソースに関連するリンクを改変する場合、該リソースの同時並行の改変を防止するために、該リソースに対するロックを取得しなければならない。本発明の実施における、リソースに対するロックの取得のプロセス（３５０）は、図４に関連してさらなる詳細を説明する。このプロセスの結果は２つに成り得る。一つは、例えば別のユーザが既にリソースを改変しつつありそれに対するロックを先に取得しているという理由で、ロックが拒否される（３５３）。この場合、ユーザに、現時点では該リソースをユーザが改変することはできないことが通知され（３６０）てプロセスが終了する。あるいは、ロックが取得され（３５６）、ユーザは改変アクションを実行できる（３７０）。リソースの改変後ロックは開放される。最新のアプリケーションは、該アプリケーションが管理するリソースの改変をモニタし、かかる変更の追跡を可能にする関連情報を監査証跡中に記録する（３８０）ようになっている。本発明のある実施形態において、アプリケーション（１００）は、他の証跡中に、認証ユーザの識別子、成り代わられた認可ユーザの識別子、改変されたリソースへの参照、システム中で該リソースを一意的に識別することを可能にする参照、および、改変が行われた時間を正確に示すためのタイムスタンプを記録する。また、リソースの内容、別ユーザに成り代わったユーザによって改変が行われたことを示すタグを含め、さらなる情報を監査証跡に格納することもできる。これは、後日、誰かが、何らかの成り代わりアクテビティに対する監査証跡に関し調査を必要とするとき有用となろう。

図４は、ユーザによるロックされたリソースの改変を管理するためのプロセスを示し、該プロセスは、以下のアクテビティ、
− 開始アクテビティ（４００）と、
− リソースが、リソース・ロック・オブジェクトに関連付けられているかどうかを点検するアクテビティ（４０５）と、
− 関連付けられていない場合は、リソース・ロック・オブジェクトを生成し（４０７）、それをユーザに割り当て（４１０）、直近アクセス時間を更新し（４１５）、ロック取得メッセージを送信し（４２０）、プロセスを終了する（４２５）アクテビティと、
− 関連付けられている場合は、該リソースに関連付けられたロック・オブジェクトを読み出すアクテビティ（４３０）と、
− このロックが保有状態かどうかを点検するアクテビティ（４３５）と、
− 保有状態でない場合、ロック・オブジェクトの盗窃（ｓｔｅａｌｉｎｇ）を可能にし（４４０）、ロック・オブジェクトについての競合状態の点検がＯＫかどうかを判定し（４４５）、この判定がＯＫでない場合にあっては、ロック拒否メッセージを送信し（４５０）、この判定がＯＫの場合にあっては、該ロックをユーザに割り当て（４１０）、直近アクセス時間を更新し（４１５）、ロック取得メッセージを送信し（４２０）、プロセスを終了するアクテビティ（４２５）と、
− 保有状態の場合、処理中のロック・オブジェクトをユーザ・セッション・オブジェクトと対比点検するアクテビティ（４５５）と、
− ロックが同じセッションによって保有されているかどうかを判定するアクテビティ（４６０）と、
− 保有されている場合には、該ロックが同一のユーザ身元によって保有されているかどうかを判定し（４６５）、ユーザの身元が同一の場合にあっては、直近アクセス時間を更新して（４１５）ロック取得メッセージを送信し（４２０）、ユーザ身元が異なる場合にあっては、ロック・オブジェクトの盗窃を可能にし（４４０）、ロックについての競合状態の点検がＯＫかどうかを判定し（４４５）、その判定の後、既述の全てのアクテビティを実行する、アクテビティと、
− ロックが同じセッションに保有されていない場合は、該ロックが期限切れかどうかを判定するアクテビティ（４７０）と、
− 期限が切れている場合にあっては、ロックについての競合状態の点検がＯＫかどうかを判定し（４４５）、その判定の後、既述の全てのアクテビティを実行する、アクテビティと、
− 期限が切れていない場合にあっては、ロックが、同一のａｕｔｈｅｎｔｉｃａｔｅｄＵｓｅｒＳＮまたはａｕｔｈｏｒｉｓｅｄＵｓｅｒＳＮによって保有されているどうかか判定するアクテビティ（４７５）と、
− ロックが同一のユーザＩＤによって保有されていなければ、ロック拒否メッセージを送信するアクテビティ（４５０）と、
− ロックが同じユーザＩＤに保有されていれば、ユーザに該ロックを盗窃するかどうかを問い合わせるアクテビティ（４８０）と、
− ユーザがロックの取得を望むかどうかについてユーザのレスポンスを判定するアクテビティ（４８５）と、
− ユーザが望んでいる場合、ロックについての競合状態の点検がＯＫかどうかを判定し（４４５）、その判定の後、既述の全てのアクテビティを実行する、アクテビティと、
− ユーザがロックの取得を望まない場合、ロック拒否メッセージを送信するアクテビティ（４５０）と、
を含む。
リソース（１５０）の改変を可能にする前に、アプリケーション（１００）は、該リソースの同時並行改変が生じ得ないことを確実にする必要がある。典型的なメカニズムに、ロック・オブジェクトをリソースと関連付け、これにより、該リソースに対する書き込みが行われていることを具現化し、他のユーザが同時に書き込みを行うのを防止することがある。本発明の好適な実施形態において、ロック・オブジェクトは、成り代わり機能のサポートのため、ａｕｔｈｅｎｔｉｃａｔｅｄＵｓｅｒＳＮおよびａｕｔｈｏｒｉｓｅｄＵｓｅｒＳＮフィールドを含む。また、ロック・オブジェクトには、該ロックが取得されたときにアクティブであったセッションを識別するためのセッションＩＤフィールドも含めることができる。該セッションＩＤフィールドは、ユーザ・セッション・オブジェクトからコピーすることができる。ロック・オブジェクトには、ロックが対応するリソース中に取得された時点を表すｔｉｍｅＷｈｅｎＡｃｑｕｉｒｅｄ（取得時点）フィールド、リソースに対するロックが有効であった間の、読み取りまたは書き込みいずれか直近のアクションが実施された時点を表すｔｉｍｅＷｈｅｎＬａｓｔＡｃｃｅｓｓｅｄ（直近のアクセス時点）フィールド、および該ロック・オブジェクトにより制御されるリソースへの参照をさらに含めることができる。リソースが既にロックされているのでなければ、ユーザは、該リソースに対するロックを安全に取得し（４０７）、ロック・オブジェクト中に全ての関連パラメータを設定することができる（４１０、４１５）。このとき、フィールドａｕｔｈｅｎｔｉｃａｔｅｄＵｓｅｒＳＮおよびａｕｔｈｏｒｉｓｅｄＵｓｅｒＳＮの値は、それぞれ、ユーザ・セッション・オブジェクトの対応するフィールドからコピーされる。認証ユーザが別のユーザに成り代わる場合、これはリソース・ロック・オブジェクトに反映される。リソース（１５０）がリソース・ロック・オブジェクトによって既に保護されている場合、アプリケーション（１００）は、只今のユーザが別のユーザに成り代わろうとしている可能性を考慮に入れて、該ロック・オブジェクトをそのユーザに再割り当てしようとする。
アプリケーション（１００）は、最初に、既存のロック・オブジェクトが既に保有状態にあるかどうかを、具体的には該既存のロック・オブジェクトのフィールドを解析することによって点検する（４３５）。ロックが保有状態にない場合、すなわち、ａｕｔｈｅｎｔｉｃａｔｅｄＵｓｅｒＳＮおよびａｕｔｈｏｒｉｓｅｄＵｓｅｒＳＮなど、一部のフィールドが空白の場合、アプリケーションは、該ユーザにリソースのロック・オブジェクト安全に割り当て（４１０）、該ロック・オブジェクトに適切なフィールド値を設定する（４１５）ことができる。具体的には、フィールドａｕｔｈｅｎｔｉｃａｔｅｄＵｓｅｒＳＮおよびａｕｔｈｏｒｉｓｅｄＵｓｅｒＳＮの値は、それぞれ、ユーザ・セッション・オブジェクト中の対応するフィールドからコピーされる。
ロックが既に保有されている場合、リソース・ロック・オブジェクト中のフィールドの値とユーザ・セッション・オブジェクト中のフィールドの値との照合（４５５）が実行される。リソース・ロック・オブジェクトのセッションＩＤフィールド値が、ユーザ・セッション・オブジェクトのセッションＩＤフィールド値と整合し、同一のセッションにおいて、ユーザ・セッション・オブジェクト中およびリソース・ロック・オブジェクト中のａｕｔｈｅｎｔｉｃａｔｅｄＵｓｅｒＳＮフィールドが整合している場合、たとえａｕｔｈｏｒｉｓｅｄＵｓｅｒＳＮフィールドが異なっていたとしても、認証ユーザは別のユーザに成り代わる要求を前に行っており、現在の要求に先立って該オブジェクトのロックを得ている。このとき、オブジェクトのロックを要求しているユーザの身元は同じであり（４６５）、ロック・オブジェクトの盗窃を可能にする（４４０）のは、特にアプリケーションで多重スレッドの実行が可能でない場合には、安全である。ロックを只今のユーザに割り当てる前に、アプリケーション（１００）は、別のセッションが、同じロックを獲得するための競合状態で競っていないことを点検する（４４５）。このステップに問題がなければ、次いで、ロックを該ユーザに割り当て（４１０）、ロック・オブジェクトの関連フィールドを更新する（４１５）のは安全である。このステップが不首尾の場合、すなわち他のセッションが競合状態に勝った場合、このときは、リソースに対するロック取得するのは不可能でありロック拒否メッセージを生成（４５０）しなければならない。ロックが別のセッションに保有されている場合、該ロックがまだ有効か期限切れかを点検（４７０）しなければならない。期限切れの場合、該ロックを現在のユーザに割り当てることは安全であり得る。アプリケーション（１００）は、再び、前述のような、ロックを獲得するための競合状態についての点検（４４５）をしなければならない。
該ロックが期限切れでない場合、その状況のさらなる解析を行わなければならない。ロック・オブジェクトのフィールドａｕｔｈｅｎｔｉｃａｔｅｄＵｓｅｒＳＮによって示されるエンティティが、セッション・オブジェクトの対応するフィールドと整合する場合、このとき、このロックは、同一のユーザによって異なったセッション（おそらく中断）で取得されていたに違いない。この場合、ユーザにロックの盗窃について尋ねる（４８０）のが適切である。ａｕｔｈｅｎｔｉｃａｔｅｄＵｓｅｒＳＮフィールド中の身元が異なる場合、このとき、ユーザはａｕｔｈｏｒｉｓｅｄＵｓｅｒＳＮフィールドの値を検討する。ユーザ・セッション・オブジェクト中のａｕｔｈｏｒｉｓｅｄＵｓｅｒＳＮフィールドの値が、ソース・ロック・オブジェクト中のａｕｔｈｅｎｔｉｃａｔｅｄＵｓｅｒＳＮまたはａｕｔｈｏｒｉｓｅｄＵｓｅｒＳＮの値と整合する場合、それは、認証ユーザによって成り代わられた他のユーザ、またはこの他のユーザに成り代わった別のユーザ（例えば、サポート・チームの別の要員など）が、リソースを改変しようと試み、それに対するロック・オブジェクトを取得したことを意味する。このときは、これらの他のユーザは、これ以上リソースにアクセスすることができないことがあり得るので、該ロック・オブジェクトを盗窃しそれを只今の認証ユーザに再割り当するのが適切であり得る。只今のユーザは、ロックを盗窃するかどうかを尋ねられる（４８０）。ユーザが受諾した場合（４８５）、次いで該ロックの盗窃が監査証跡に記録される。ユーザが拒否した場合には、ロック拒否メッセージが生成される（４５０）。
ユーザ・セッション・オブジェクト中のａｕｔｈｏｒｉｓｅｄＵｓｅｒＳＮフィールドの値が、リソース・ロック・オブジェクト中のａｕｔｈｅｎｔｉｃａｔｅｄＵｓｅｒＳＮまたはａｕｔｈｏｒｉｓｅｄＵｓｅｒＳＮの値と整合しない場合、このときロックは取得できず、ロック拒否メッセージが生成される（４５０）。
ユーザがロックの盗窃を受諾したあらゆる場合において、次のステップは、前述のように競合状態について点検する（４４５）ことである。これらの競合状態に問題がなければ、ロックは只今のユーザに割り当てられ（４１０）、ロック・オブジェクトの関連フィールドは更新され（４１５）ロック取得メッセージが生成される（４２０）。

別の実施形態は、ウェブ・アプリケーションにおいて別のユーザに成り代わる方法を含み、該方法は、現在のユーザ・セッションに関連するデータ制御ブロックのフィールドａｕｔｈｅｎｔｉｃａｔｅｄＵｓｅｒＳＮ中にユーザ身元情報を組み入れて、外部アクセス管理システムを使いユーザを認証するステップと、外部アクセス管理システムとアプリケーション・コンテナとの協調した動きにより、外部アクセス管理システム中の一つ以上のグループ中に該ユーザを包含することによって、アプリケーション・ロールを該認証されたユーザに関連付けるステップと、相異なる認証ユーザに対し、認証時にユーザに認可されているロールの機能として各種機能が実施できるようにするステップと、成り代わり機能を実施可能にするステップと、成り代わり機能の実行に際し、第一ユーザが成り代わりたい第二ユーザの（パスワード以外の）身元情報を受信するステップと、成り代わられるユーザに対しカスタム化された情報を反映するため、アプリケーションのユーザ・インタフェースを操作して、現在のユーザ・セッションに関連するデータ制御ブロックのａｕｔｈｏｒｉｓｅｄＵｓｅｒＳＮフィールド中にこの身元情報を組み入れるステップと、を含む。

さらに別の実施形態は、別のユーザに成り代わった認証ユーザがリソースを改変する方法を含み、該方法は、改変対象のリソースに対するロックを取得するステップと、認証ユーザの身元情報および成り代わられるユーザの身元情報をロック・オブジェクトの内部に格納するステップと、該ロックが、別のユーザに成り代わった認証ユーザによって首尾よく取得されたことを示すメッセージを生成するステップと、を含む。

本発明は、全体がハードウエア実施形態の形、全体がソフトウエア実施形態の形、またはハードウエアおよびソフトウエア両方のエレメントを包含する実施形態の形を取ることができる。ある好適な実施形態において、本発明は、以下に限らないが、ファームウエア、常駐ソフトウエア、マイクロコードなどを含むソフトウエアに実装される。

さらに、本発明は、コンピュータまたは任意の命令実行システムでの使用またはこれらに関連させての使用のためのプログラム・コードを備えた、コンピュータ可用またはコンピュータ可読媒体からアクセス可能なコンピュータ・プログラム製品の形を取ることもできる。この説明の目的の上で、コンピュータ可用またはコンピュータ可読媒体は、命令実行システム、装置、またはデバイスでの使用またはこれらに関連させての使用のためのプログラムを、包含、格納、通信、伝播、または移送可能な任意の装置とすることができる。

該媒体は、電子的、磁気的、光学的、電磁気的、赤外的な、または半導体のシステム（または装置またはデバイス）あるいは伝播媒体とすることができる。コンピュータ可読媒体の例には、半導体または固体メモリ、磁気テープ、着脱可能コンピュータ・ディスケット、ランダム・アクセス・メモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、剛体磁気ディスク、および光ディスクが含まれる。光ディスクの現今の例には、読み取り専用コンパクト・ディスク（ＣＤ−ＲＯＭ）、読み取り／書き込みコンパクト・ディスク（ＣＤ−Ｒ／Ｗ）およびＤＶＤが含まれる。

プログラム・コードを格納または実行あるいはその両方を行うのに適したデータ処理システムは、システム・バスを介して直接的または間接的にメモリ・エレメントに連結された少なくとも一つのプロセッサを包含することになる。該メモリ・エレメントには、プログラム・コードの実際の実行の過程で用いられるローカル・メモリ、大容量記憶装置、および、実行の間に大容量記憶装置からコード読み出しを行わねばならない回数を低減するため、少なくとも一部のプログラム・コードの一時的保存を提供するキャッシュ・メモリを含めることができる。

システムには、直接に、あるいは介在Ｉ／Ｏコントローラを通して、入力／出力またはＩ／Ｏデバイス（以下に限らないが、キーボード、ディスプレイ、ポインティング・デバイスなどを含む）を連結することができる。

また、ネットワーク・アダプタをシステムに連結し、該データ処理システムが、介在する私的または公共的ネットワークを通して、他のデータ処理システム、もしくは遠隔のプリンタまたは記憶デバイスに連結できるようにすることができる。モデム、ケーブル・モデムおよびイーサネット（Ｒ）カードは、現在利用可能なネットワーク・アダプタのほんの一部である。

Claims (8)

1. コンピュータ・システム中のリソースにアクセスする方法であって、
   − 第一および第二識別エレメントを包含する第一身元情報オブジェクトを受信するステップであって、各識別エレメントは、前記コンピュータ・システムにおいて宣言された第一および第二ユーザをそれぞれ一意的に識別し、前記第一および第二ユーザは相異なる、前記受信するステップと、
   − 前記第一ユーザから前記リソースを改変するための第一要求を受信するステップと、
   − 前記第二ユーザが前記リソースを改変することを認可されているかどうかを検証するよう指示する第一メッセージを送信するステップであって、前記第一メッセージは、前記第二識別エレメントおよび前記リソースへの参照を含む、前記送信するステップと、
   − 前記検証に基づいて、前記第二ユーザが前記リソースを改変することを認可されているかどうかを示す第二メッセージを受信するステップと、
   − 前記第二ユーザが前記リソースを改変することを認可されている場合は、
   − 前記第一および第二識別エレメントを包含する第一ロック・アナンシエータを設定するステップであって、前記ロック・アナンシエータは、前記リソースがロックされていることを示すようになされており、前記第一ユーザが前記第二ユーザに成り代わりながら前記リソースをロックしていることを証している、前記設定するステップと、
   を含む、前記方法。
2. − 前記第一ユーザに対する身元ベリフィケータを受信するステップと、
   − 前記第一ユーザを認証するよう指示する第三メッセージを送信するステップであって、前記第三メッセージは、前記第一識別エレメントおよび前記身元ベリフィケータを包含する、前記送信するステップと、
   − 前記認証に基づいて前記第一ユーザが認証されているかどうかを示す、第四メッセージを受信するステップと、
   をさらに含む、請求項１に記載の方法。
3. 前記第一識別エレメントはユーザ名であり、前記身元ベリフィケータはパスワードである、請求項２に記載の方法。
4. 前記第二ユーザが前記リソースを改変することを認可された段階で、
   − 前記リソースが、第三および第四識別エレメントを包含する第二ロック・アナンシエータによって既にロックされていることを示す、第五メッセージを受信するステップと、
   − 前記第一識別エレメントと第三識別エレメントとが整合していることを検証するステップと、
   − 該第二識別エレメントと第四識別エレメントとが相異なることを検証するステップと、
   を含む、先行する請求項のいずれかに記載の方法。
5. − 前記第一および第二識別エレメントを包含する第六メッセージと、前記リソースへの参照と、タイムスタンプとを含む第二要求を送信するステップであって、前記第二要求は監査証跡に前記第六メッセージを記録するよう指示している、前記送信するステップを、
   さらに含む、先行する請求項のいずれかに記載の方法。
6. 請求項１〜５のいずれか一つに記載の前記方法の各ステップを遂行するようになされた手段を含む装置。
7. コンピュータ・プログラムがコンピュータ上で実行されたとき請求項１〜５のいずれか一つに記載の前記方法の前記ステップを遂行するための命令を含む、前記コンピュータ・プログラム。
8. 符号化された、請求項７に記載のコンピュータ・プログラムを有するコンピュータ可読媒体。

Images