JP2000207363A - ユ―ザ・アクセス制御装置 - Google Patents

Abstract

(57)【要約】 【課題】ネットワーク環境においてアクセス権限の過大
付与も過小付与もないようにユーザのアクセスを制御す
る。 【解決手段】"ユーザ役割"を使用してアクセス制御を行
う。ユーザ役割は、ユーザの機能が何であるかを決定
し、操作上の責任領域を定義する。ユーザ役割によるア
クセス制御は、オブジェクトに対してどのようなアクシ
ョンを取ることができるかを決定するユーザ役割および
アクセス権限を含む。ユーザのユーザ役割が特定のオブ
ジェクトに対して特定のアクションをとる権限をユーザ
に付与するアクセス権限をユーザに与えていれば、ユー
ザはそのアクションを実行することができる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、システム・セキュ
リティ管理の分野に関するもので、特に、ユーザ役割の
使用を通してネットワーク環境における管理およびセキ
ュリティの容易さを推進するようにユーザ・アクセス制
御を実施する方法に関するものである。

【０００２】

【従来の技術】ネットワーク環境における管理(ユーザ
はジョブを実行するため必要なものだけを見る)および
セキュリティ(ユーザは認可されている動作だけを実行
することができる)の容易さを推進するためには、ユー
ザがシステム上で行うことができることを制御すること
ができることが重要である。異なるユーザが異なるレベ
ルの特権を割り当てられネットワークの異なる部分を管
理することができるようにすることによってこのような
目標を達成するため、ユーザが管理することができるオ
ブジェクトおよびユーザが実行することができる操作を
定義するユーザ・アクセス制御が広く使われている。

【０００３】従来技術の製品におけるユーザ・アクセス
制御はドメインによって定義されてきた。ドメインとい
う用語の用途は種々あるが、非公式には、共通の管理、
位置または規格を持つ一群のオブジェクトを記述するた
め使用されている。分散環境においては、コンポーネン
トまたは人々をある単位(またはドメイン)にグループ化
することは非常に重要である。なぜならば、そのような
環境のサイズおよび複雑さが、管理の目的のため各コン
ポーネントまたはユーザを１つの独立した主体として扱
うことを不可能にするからである。従って、環境を関心
および責任領域に細分化することによって管理環境のサ
イズおよび複雑さを減少させるため、ドメインが使用さ
れる。ユーザ・アクセス制御の文脈においては、１つの
ドメインは、単一の管理ポリシーに左右される資源、人
々、特権またはプロセスのようなオブジェクトのセット
に属することができる。グループにおけるエレメントが
単一ポリシーによって管理されることができるようにド
メインはグループ化されなければならない。例をあげれ
ば、ある１つのユーザ・ドメインは、ユーザが何にアク
セスすることができるかという単一ポリシーに従う給料
支払業務に責任のある一組のユーザであり、オブジェク
ト・ドメインは同じアクセス権に従う一組の給料支払フ
ァイルである。ドメインのメンバが単一の実体またはド
メインであることができ、同じ実体／ドメインが１つま
たは複数のドメインに属することもできる。

【０００４】代表的なユーザ・アクセス制御実施形態に
おいては、１つまたは複数のオブジェクト・ドメインに
関連づけられる１つまたは複数のユーザ・ドメインがあ
る。ユーザ・ドメインがオブジェクト・ドメインに関し
て何ができるかを指定するアクセス規則によって、この
関連づけがなされる。基本的アクセス規則は、ユーザ・
ドメイン、オブジェクト・ドメイン、オブジェクト・ド
メインの操作セットを指定する。要求を行うユーザが規
則のユーザ・ドメインの中にあり、要求のオブジェクト
が規制のオブジェクト・ドメインの中にあり、操作名が
オブジェクト・ドメインの操作セットの中にあれば、ア
クセスが許される。要求におけるユーザ、オブジェクト
または操作がいずれの既存のアクセス規則にもあてはま
らないならば、新しいアクセスが定義される。

【０００５】例えば、アクセス規則{Payroll, Payroll_
Files, {read, write}}は、Payroll(給料支払)ユーザ・
ドメインにおけるユーザのすべてがPayroll_Files(給料
支払ファイル)というオブジェクト・ドメインのオブジ
ェクトにread/write(読み書き)することができることを
指定する。異なるユーザがPayrollドメインの範囲内の
異なるサブセットの操作を必要とすれば、複数のアクセ
ス規制が作成されなければならない。従って、もしも、
Payrollユーザ・ドメインがPayroll_Staff(給料支払ス
タッフ)ユーザ・ドメインおよびPayroll_Mgr(給料支払
管理者)ユーザ・ドメイン(ドメイン・メンバはその他の
ドメインでもよい)を含み、Payroll_StaffがPayroll_Fi
lesの読み取りだけを許され、一方、Payroll_Mgrが読み
書きを許されたとすれば、Payroll_Staff{Payroll_Staf
f,Payroll_Files,read}という１つのアクセス規則が作
成されると共に、別のPayroll_Mgr{Payroll_Mgr,Payrol
l_File,{read,write}}という規則が作成されるであろ
う。

【０００６】

【発明が解決しようとする課題】ユーザ・アクセス制御
の既存のモデルに関わる１つの問題は、権限がしばしば
過大付与または過小付与されることである。権限の過大
付与および過小付与はオブジェクト管理およびセキュリ
ティ制御の目標から乖離する。権限の過大付与はシステ
ムをセキュリティ違反に対して脆弱にする。例えば、Ob
jectDomain1が{read,write,create}というアクセスを持
つと定義され、アクセス規則がObjectDomain1{UserDoma
in1, ObjectDomain1, read}に対するreadアクセスをUse
rDomain1に、ObjectDomain1{UserDomain2, ObjectDomai
n1, {readwrite}}に対するread/writeアクセスをUserDo
main2に、ObjectDomain1{UserDomain3, ObjectDomain1,
{read,write,create}}に対するread/write/createアク
セスをUserDomain3にそれぞれ付与すると仮定する。更
に、例えば一人のユーザが複数の役割を引き受けるか別
の従業員の代役をする場合がそうであるように、User1
が事務作業の目的からUserDomain1のメンバであり、管
理の目的からUserDomain2のメンバであり、運用の目的
からUserDomain3のメンバであると仮定する。User1は、
システムにサインオンする時、UserDomain1、UserDomai
n2およびUserDomain3のメンバと認識される。その結
果、User1の通常の業務が純粋に事務作業であり、UserD
omain1のアクセス権を必要とするだけであるのに、その
ユーザ・ドメイン・メンバ権のため、そのユーザは、そ
の仕事のために必要とされる以上の権限であるUserDoma
in2およびUserDomain3のアクセス権を持つという過剰付
与が起きる可能性がある。

【０００７】権限の過小付与は、必要な権限を維持する
ため貴重な時間と資源を消費する。厳格なセキュリティ
が存在し、ユーザには必要に応じて権限が与えられると
いう場合に権限の過小付与が発生する。例えば、User1
は、通常は事務員の役割を引き受けているので、Object
Domain1へのアクセスのためUserDomain1に割り当てられ
る。User1が一時的に管理者の役割を引き受ける必要が
あるとすると、User1にUserDomain2の管理の権限を与え
るアクセス規則が作成される必要がある。同じように、
もしもUser1が一時的に運用従業員の役割を引き受ける
必要があるとすれば、その目的のためのアクセス規則が
作成されなければならない。User1の一時的任務が解か
れると、そのアクセス規則を削除するため時間をさく
か、さもなければ、システムは権限の過大付与にさらさ
れる。

【０００８】既存モデルのユーザ・アクセス制御に関わ
る別の問題は、同じプラットホーム上の複数のアプリケ
ーションでユーザ・アクセス制御が実施される場合に発
生する。ユーザ・アクセス制御機能性に対するニーズが
非常に大きかったので、アプリケーションは、アプリケ
ーションが存在するプラットホーム上でセキュリティ機
能を実施することが必要であるとみなした。例えば、Do
main1が操作セット{Read,Write,Create}によって定義さ
れ、プラットホームが管理ポリシー{UserGroup1、Domai
n1、read}を定義し(但しUserGroup1のメンバがreadアク
セス権を持つ)、Application1が独立して管理ポリシー
{UserGroup1, Domain1,｛read,write}}を定義する。Use
rGroup1のメンバがアプリケーションにサインオンする
時Domain1へのread/writeアクセス権を持つと仮定す
る。

【０００９】第１の問題は、UserGroup1に属し、Domain
1のオブジェクトにアクセスするユーザがプラットホー
ムとアプリケーションの間で矛盾した権限の内容を与え
られるという点である。なぜならば、プラットホームに
従えばユーザはDomain1のオブジェクトへのreadアクセ
ス権を持ち、アプリケーションにおいては同じオブジェ
クトへのread/writeアクセス権を持つからである。更
に、このモデルは、アプリケーション統合すなわち２つ
のアプリケーションがドメインを越えてオブジェクトを
共有する能力に問題を与える。例えば、Application1が
プラットホーム{UserGroup1, Domain1, {Read}}と同じ
管理ポリシーを定義するとすれば、Application1のユー
ザは明らかにDomain1のオブジェクトへのwriteアクセス
権を持つべきではないのに、Application2に関して独立
して作成される管理ポリシーのためにDomain1のオブジ
ェクトへのwriteアクセス権を持つというセキュリティ
違反が発生する可能性がある。その結果、アプリケーシ
ョン統合は実施が一層困難となる。

【００１０】従って、ユーザ・アクセス制御モデルがユ
ーザの特定のジョブに合う権限を付与し、アプリケーシ
ョン整合性およびアプリケーション統合を促進すること
ができる手段が必要とされている。

【００１１】

【課題を解決するための手段】課題を解決するため本発
明が提供するコンピュータ・オブジェクトに対するユー
ザ・アクセスを制御する装置は、１つまたは複数のコン
ピュータ読み取り可能記憶媒体、および、上記１つまた
は複数のコンピュータ読み取り可能記憶媒体に所在して
１つまたは複数のユーザ役割を作成するプログラム・コ
ードを備え、上記１つまたは複数のユーザ役割の各々が
ユーザ・セットに関連づけられたアクセス権限セットを
含み、上記アクセス権限の各々が上記ユーザ・セットの
中のユーザによって実行される上記コンピュータ・オブ
ジェクトに対するアクションを記述するように構成され
る。

【００１２】本発明は、ユーザ・アクセス制御に対する
一層柔軟で強力な手法を実施するためユーザ役割という
概念を使用する。ドメイン・モデルが１つまたは複数の
操作セット／オブジェクト・ドメインのペアに対してユ
ーザが持つアクセス権に基づいて１つのオブジェクトへ
のアクセスを決定するのに対して、本発明は、ユーザが
メンバである１つまたは複数のユーザ役割に関して定義
される権利に従ってアクセス権を決定する。本明細書に
おいて、"ユーザ"は、ユーザ認証のために使用されるユ
ニークなＩＤによって識別される。また、"ユーザ"は、
人物、または、特定の要求に関してユーザ役割を継承す
るサーバのいずれかを意味する。ユーザは、１つまたは
複数のユーザ役割のメンバであることができ、ユーザが
ログインする時１つまたは複数のユーザ役割の特徴を継
承することができる。ユーザ役割は、そのユーザ役割の
メンバであるユーザによって実行されることができるア
クションのセットである。(ユーザ役割は、また、他の
ユーザ役割によっても定義されることができる)。ユー
ザ役割は、どのアクションがユーザ役割に属しているか
を決定するアクセス権限をユーザに与える。ユーザが、
自分がメンバである１つまたは複数のユーザ役割にログ
インすると、ユーザは、ユーザ許可を与えるそのような
ユーザ役割のアクションに対するアクセス権を得て、そ
れらのアクションを行う。同じように、サーバは、初期
的にユーザに関連づけられるかまたは特定の要求に関し
てユーザの個性を継承することによって、アクセス権を
得ることができ、従って、認証されたアクションに関し
てフィルタの役を果たすことができる。

【００１３】ユーザ役割によるユーザ・アクセス制御の
実施は、ネットワーク環境における容易な管理およびセ
キュリティという目標を達成する。一般的に、ユーザ・
アクセス制御は、混乱を減少し、ユーザがその仕事を行
うために必要とするものだけをユーザが見ることを可能
にすることによってこのような目標を推進する。複数の
アプリケーションが１つのプラットホーム上に導入さ
れ、オブジェクト・アクセスに対する断片的な制御が混
同、エラーおよびセキュリティ違反につながることがあ
り得る場合にこれは特に重要である。ユーザ役割は、複
数のアプリケーションの間で共有されるオブジェクト上
で実行されることができるアクションを制御する管理性
／セキュリティのレイヤを注入することによって混同を
排除する。例えば、ユーザ役割は、分散システムまたは
ウェブ・ブラウザ上のメニュー項目をグレーにする(使
用不可状態にする)ためユーザ役割を使用することがで
きる。ユーザ役割は、指定された役割におけるユーザの
責任に関してアクセス規則が特に作成されることを可能
にするので、動的な役割切り替えが可能で、権限の過大
付与または過小付与に関連する問題を除去することがで
きる。ユーザが複数アプリケーションの間で許可された
ことだけを一貫して実行することができることを保証す
るため本発明を使用することができる。権限が複数のレ
イヤではなく単一のレイヤによって実施される場合、権
限の矛盾した権限の内容がユーザに与えられる可能性は
少ない。更に、矛盾した権限の適用を除去することによ
って、整合性のある権限許可または共用オブジェクトへ
のアクセスの否定を通してアプリケーションの統合がサ
ポートされる。

【００１４】本発明の第１の側面において、オブジェク
トおよびドメインの概念が存在しない場合のユーザ役割
アクセス制御を実施するため、ウェブに基づくモデルが
使用される。本発明の第２の側面において、ユーザ役割
アクセス制御を実施するため、ユーザ役割がオブジェク
トおよびドメイン概念と相互に関係づけられる。上記両
方の側面において、ユーザ役割アクセス制御は、グラフ
ィカル・ユーザ・インタフェース(すなわちＧＵＩ)フィ
ルタリングおよび選択されたアクションの実行時アクセ
ス検査という２つの形態で使用される。この両者は、ど
のＵＲＬまたはメニュー項目が例えば表示されアクセス
権を与えられるかを決定するユーザ役割のアクセス権に
よって定義される。

【００１５】過去におけるようなアクセス権をオブジェ
クトまたはユーザに関連づける方法に比較してユーザ役
割アクセス制御は一層柔軟である。アクセス権をオブジ
ェクトに関連づけることは、オブジェクトへのアクセス
が新しいユーザに与えられる必要がある場合、構成の修
正を困難にする。多数のオブジェクトが存在し、(一人
が同僚の役を引き受ける時のように)新しい権利が一時
的のものにすぎないような場合特に困難である。また、
(動的ネットワーク環境においては頻繁に起きることで
あるが)新しいオブジェクトが追加される場合や、(病気
や休暇でだれかの代役を務めなければならないような場
合のように)果たさなければならない異なる役割に基づ
いてユーザがアクセス権を変更する必要がある場合、権
限のユーザへの関連づけはその維持が困難である。

【００１６】ユーザ役割アクセス制御は、最高の柔軟性
を提供し、構成の複雑さおよびオーバーヘッドを最小限
にとどめる。例えば、上記第２の側面において、(例え
ば新しいオブジェクトの追加によって)ドメインの定義
を変更することは、そのドメインに関するアクセス規則
を含むユーザ役割のすべてに影響を及ぼす。(例えば新
しいアプリケーションの導入のため新しい操作の追加に
よって)操作セットの定義を変更することは、その操作
セットに関するアクセス規則を含むユーザ役割のすべて
に影響を及ぼす。(例えばアクセス規則の追加または削
除によって)ユーザ役割の定義を変更することは、その
ユーザ役割に割り当てられたすべてのユーザに関するア
クセス権を変更する。影響を受けるユーザ各々について
アクセス権を更新する必要はない。更に、ユーザ役割ア
クセス制御は、大きな、明確に定義されたグループにま
とめられたアクセス権をユーザに付与または否定するこ
とを容易にする。例えば、種々のオブジェクトに関する
種々の操作に関して多数の個別的アクセス権を割り当て
る代わりに、"ネットワーク操作員"ユーザ役割をユーザ
に割り当てることによって、"ネットワーク操作員"権限
をそのユーザに与えることができる。

【００１７】

【発明の実施の形態】本発明は、ユーザ役割を通してユ
ーザ・アクセス制御を実施する方法および装置である。
本明細書において、"ユーザ"は、人、または、特定の要
求に関してユーザ役割を継承するサーバのいずれかを意
味する。ユーザは、ユーザ認証のために使用されるユニ
ークなＩＤによって識別される。ユーザ役割は、ユーザ
の機能が何であるかを決定するアクションのセットであ
る。ユーザ役割は、セキュリティ管理者、ネットワーク
管理者またはシステム管理者のような操作上の責任分野
を定義することができる。

【００１８】ユーザ役割アクセス制御は、(図２に示さ
れているような)１つまたは複数のコンピュータ読取可
能記憶媒体２３２で実施されることができ、１つまたは
複数のユーザ役割２００、２０２、２０４を作成するプ
ログラム・コードが上記１つまたは複数のコンピュータ
読取可能記憶媒体２３２上に存在する。１つまたは複数
のユーザ役割２００、２０２、２０４の各々は、ユーザ
・セットに関連するアクセス権セット２２６、２２８、
２３０を含み、アクセス権２２６、２２８、２３０の各
々は、ユーザ・セットの中のユーザによってコンピュー
タ・オブジェクト・セットに関して実行されるアクショ
ン２０６、２０８、２１０、２１２、２１４、２１６、
２１８、２２０、２２２を記述する。

【００１９】ユーザ役割アクセス制御は、また、ユーザ
・アクセスを制御する方法の形態で実施されることもで
きる。この方法は、コンピュータ・セッションの間にア
クションを実行すべき要求をユーザから受け取り、その
要求に応答して、上記ユーザが当該セッションに関して
そのメンバである１つまたは複数のユーザ役割２００、
２０２、２０４を取り出すステップを含む。この場合、
１つまたは複数のユーザ役割２００、２０２、２０４の
各々は、ユーザが当該セッションに関して有する１つま
たは複数のアクセス権２２６、２２８、２３０を決定
し、その１つまたは複数のアクセス権２２６、２２８、
２３は、当該セッションの間に当該ユーザが実行するこ
とができる１つまたは複数のアクション２０６、２０
８、２１０、２１２、２１４、２１６、２１８、２２
０、２２２を決定する。該方法は、更に、当該ユーザが
そのメンバである１つまたは複数のユーザ役割２００、
２０２、２０４が要求されたアクションを許可するアク
セス権２２６、２２８、２３０を含むか否かを判断する
ことによって当該ユーザが要求されたアクションを実行
する権限を与えられているか否かを判断するステップを
含む。

【００２０】図１は、ユーザ・アクセス制御のドメイン
・モデルを図示している。このモデルにおいては、オブ
ジェクト・ドメイン１０６、１０８、１１０に対するユ
ーザのアクセス権は、アクション・セット１００、１０
２、１０４の１つまたは複数ペアリングによって決定さ
れる。このモデルにおいては、要求されたオブジェクト
を含むオブジェクト・ドメインに対する要求されたアク
ションを含む操作セットのペアリングを定義するアクセ
ス権をユーザが割り当てられている場合に、ユーザはそ
のオブジェクトに関するアクションに対する権限を与え
られる。

【００２１】図２は、本発明のユーザ役割アクセス制御
の実施形態を示している。本発明のユーザ役割アクセス
制御においては、ユーザが、１つまたは複数のアクショ
ン２０６、２０８、２１０、２１２、２１４、２１６、
２１８、２２０、２２２に対する１つまたは複数のアク
セス権２２６、２２８、２３０を含む１つまたは複数の
ユーザ役割２００、２０２、２０４のメンバであれば、
そのユーザの特定の要求に権限が付与される。ただし、
この場合、少なくとも１つのアクセス権が要求されたア
クションを含む。言い換えると、要求されたアクション
に対する少なくとも１つのアクセス権を含むユーザ役割
にユーザが関連づけられていれば、そのアクションは許
可される。

【００２２】第１の好ましい実施形態 本発明の第１の好ましい実施形態において、ユーザのア
クション起動を許可または否定するユーザ役割アクセ制
御がウェブ型環境において実施される。この場合、ＵＲ
Ｌが特定のアクションに対するユーザのアクセス権を決
定する。ウェブ型ユーザ役割モデルに関するこの実施形
態は、ウェブ・ブラウザおよびウェブ・サーバとは独立
したメカニズムである。ウェブ型ユーザ役割アクセス制
御は、ランチャと呼ばれる１つのウェブ・アプリケーシ
ョンの形態で実施され、ＵＲＬを通してユーザにアクシ
ョンの実行を可能にさせる。

【００２３】本発明の１つの側面において、活動的ユー
ザ役割に関して定義されるアクションに対してＧＵＩを
フィルタリングするため、ユーザ役割アクセス制御がラ
ンチャ・ウィンドウの表示に適用される。ユーザは、表
示されるいかなるＵＲＬをも選択することができるよう
に認められる。別の側面においては、ユーザ役割アクセ
ス制御が実行時アクセス検査のため使用される。この場
合、アクションに関するＵＲＬがユーザのセッションの
１つまたは複数のユーザ役割に関して定義されていれ
ば、そのユーザはそのアクションを実行する権限を与え
られる。

【００２４】ユーザ・ログインおよびセッション初期設
定 １つまたは複数のユーザ役割によって定義されるアクセ
ス権を得るように認証され、権限を取得するためには、
ユーザはウェブ・セッションを開始しなければならな
い。セッションは、特定の表示上の特定のユーザに関連
するアプリケーションのグループである。(例えばウェ
ブ・セッションのための最上位ＧＵＩのような)ランチ
ャ・ウィンドウから直接または間接始動されるアプリケ
ーションがセッションの一部であり、情報を共有するこ
とができる。所与のウェブ・ブラウザ・プロセスに関し
てログインが行われていない場合、あるいは、ウェブ・
セッションが活動の構成可能期限をすぎた場合、新しい
ウェブ・セッションを開始することができる。ウェブ・
セッションの状態の一部は、ユーザのＩＤ(ユーザ名)お
よびユーザが実行の資格を持つものを定義するユーザ役
割のリストである。一旦ウェブ・セッションが作成され
たならば、ユーザは、そのセッションに関するユーザ役
割によって許可されるＵＲＬに自由にアクセスすること
ができる。このようなユーザ役割は、ユーザの活動的ユ
ーザ役割と呼ばれる。このような活動的ユーザ役割は、
どのＵＲＬが表示されるかという観点からどのような種
類のユーザ・インタフェースをユーザが見るかを決定す
る。このユーザ役割は、また、ユーザが起動することが
できる実行時ＵＲＬを決定する。この実施形態におい
て、該ユーザに対するユーザ役割のすべてが活動的であ
る場合、ユーザは、該ユーザがそのメンバであるユーザ
役割のすべてを与えられる。本発明は、また、ユーザの
権限を制限または拡張するため、どのユーザ役割が活動
的でありどのユーザ役割が非活動的であるかをユーザが
選択することを可能にする概念を含む。

【００２５】図３において、ユーザは、ランチャに関す
るＵＲＬをウェブ・ブラウザ３００に入力することによ
ってセッションを開始する。例えば "http://hostname/OvCgi/ovlaunch.exe" のようなランチャに関するＵＲＬが起動される。このＵ
ＲＬは、セッションが開始する時アクセス権限に応じて
実行することができるＵＲＬ引数を受け入れることがで
きる(ＵＲＬがovlaunchに指定されない場合、ログイン
の後デフォルト・ランチャ・ウィンドウが表示され、そ
こでユーザはランチャを通してまたはウェブ・ブラウザ
を通してＵＲＬを起動することができる)。ランチャに
関するＵＲＬ要求は、ワールド・ワイド・ウェブにおい
て情報にアクセスするために使用されるクライアント／
サーバ・プロトコルを通してウェブ・サーバ３０２へ転
送される(図３のステップ３０４)。このプロトコルは、
ハイパーテキスト・トランスファ・プロトコル(すなわ
ちＨＴＴＰ)と呼ばれる。ウェブ・サーバは、ＨＴＭＬ
ログイン画面を提示しユーザ名およびパスワードの入力
をユーザに促すＣＧＩ(すなわちCommon Gateway Interf
ace)プログラムのovlaunchを起動する(ステップ３０
８)。画面がウェブ・サーバに送り戻される(ステップ３
３８)。

【００２６】ウェブ・サーバは、画面を読み取り、ovlo
gin３１２を起動し(ステップ３１０)、このブラウザに
関するセッションが存在するか否かを判断するためユー
ザによって入力されたユーザ名およびパスワードを渡
す。この判断は、OvWebSessionと呼ばれるブラウザ・ク
ッキーが設定されているか否か検査することによって行
われる(詳細は後述)。このクッキーが設定されていれ
ば、ユーザが既にログインされていることを標示するメ
ッセージが返され、ovloginはクッキーからセッション
番号を取得して、ovsessionmgrを用いてセッションを検
証するためそのセッション番号を使用する。クッキーが
設定されてなければ、ovloginは新しいセッションを要
求する。両方のケースにおいて、ovloginは、セッショ
ン情報に関してサーバの役割を果たすovsessionmgr３１
６へ接続する(ステップ３１４)ことを試みる。ovsessio
nmgrへ接続されると、ovloginは、クッキー・セッショ
ン番号を渡す(ステップ３１８)ことによって既存のセッ
ションを検証するか、または、現在時環境によって定ま
る遠隔ＩＰアドレスと共にユーザ名およびパスワードを
ovsessionmgrに渡す(ステップ３１８)ことによって新し
いセッションを要求する。

【００２７】ユーザ名およびパスワードが有効でないと
すれば、ovsessionmgrはこの情報をovloginに中継し(ス
テップ３２８)、ovloginはそれをウェブ・サーバに送る
(ステップ３４０)。loginページは、ウェブ・ブラウザ
によって受け取られる(ステップ３０４)エラー標示によ
って置き換えられ、次に表示される。ユーザ名およびパ
スワードが有効であれば、現行セッションは検証されつ
つあり、ovsessionmgrは、ユーザが既にログオン済みで
あることを標示するメッセージをovloginに送り返す(ス
テップ３２８)。次に、ovloginは、そのメッセージをウ
ェブ・サーバ経由(ステップ３４０)でウェブ・ブラウザ
に送り戻す(ステップ３０４)。ユーザ名およびパスワー
ドが有効で、新しいセッションが要求されていれば、ov
sessionmgrは、ログインが成功したことを標示するメッ
セージをovloginに送り(ステップ３２８)、次にovlogin
がそのメッセージをウェブ・サーバ経由(ステップ３４
０)でウェブ・ブラウザに送り戻す(ステップ３０４)。

【００２８】ログインが成功していれば、ovsessionmgr
は、グローバル・セッション情報を維持するセッション
構成ファイル３２０を読む。Ovsessionmgrは以下のフィ
ールドに関する値を受け取る(ステップ３２１)： ・UserLogin：ユーザ認証の有無にかかわらずセッショ
ンが作成されることを可能にする。値はon/offであり、
デフォルト値はoffである。 ・LoginLogging：成功および失敗したログイン試行を記
録する。値はon/offであり、デフォルト値はoffであ
る。 ・AccessLogging：アクセスが成功したＵＲＬを記録す
る。値はon/offであり、デフォルト値はoffである。 ・セッション・タイムアウト：セッションがタイムアウ
トとなる時間量を指定する。値は０より大きな整数であ
り、デでフォルト値は９である(単位は時間)。

【００２９】これらの値のいずれかが最後のセッション
から変わったならば、ovsessionmgrはその内部構成値を
更新する。UserLoginがoffであれば、それ以上の認証を
必要とすることなくセッションが作成される。UserLogi
nがonであれば、ovsessionmgrは、管理者によって設置
されhtpasswdプログラム３２４によって記憶された(ス
テップ３２３)暗号化されたユーザ・パスワードのレポ
ジトリであるユーザ・パスワード・ファイル３２２を読
み取ることによってユーザを認証する。ユーザ・パスワ
ード・ファイルは、"banana:FXDFRAxjRkuFA"という形式
を持つ。この第１の値はユーザ名であり第２の値は暗号
化されたパスワードである。

【００３０】ユーザ・パスワード・ファイルによって返
された(ステップ３２５)パスワードが、ユーザが入力し
たパスワードと一致すれば、ユーザは認証され、セッシ
ョンが作成され、以下のセッション情報がovsessionmgr
に関連して記憶される。 ・ユーザ名 ・パスワード：パスワードは、(例えば各文字に対する
論理的ＸＯＲを行うことによって)プロセス・メモリの
読み取りによって明示的テキストで見ることができない
ような形式で記憶される。 ・ユーザ役割：ovsessionmgrは、どのユーザがどのユー
ザ役割に属しているかを指定するhtpgroupファイル３２
６を読むことによってこの情報を取得する。ただし、こ
の場合、各ユーザは１つまたは複数のユーザ役割に属し
ていることができる。ユーザ役割ファイルは、 my-users：pumpkin peanuts almonds walnuts という形式を持つ。この形式において、最初の値はユー
ザ役割であり、後続の値は、そのユーザ・グループに属
するユーザである。ユーザ役割ファイル３２７は、現在
ユーザがそのメンバであるユーザ役割をovsessionmgrに
送り返す(ステップ３２７)。その結果、ユーザは、その
ユーザ役割のすべてに関するアクセス権のすべてを与え
られる。しかしながら、本発明は、また、ユーザがユー
ザ役割にログインし、複数の役割の間で切り替えを行う
ことを可能にする。 遠隔ＩＰアドレス：これは、セッション番号に基づいて
呼び出し元の評価を更に実施するため使用される。

【００３１】ウェブ・セッションに属している(すなわ
ちウェブ・セッションの文脈の範囲内で開始された)ウ
ェブ・アプリケーションは、現行ユーザに関するセキュ
リティおよびアクセス制御情報に対するアクセス権を有
する。(ウェブ・アプリケーションは、例えば、Javaア
プレットおよびＣＧＩプログラムである。）この情報
は、セッション・プロパティを通してウェブ・アプリケ
ーションにとって利用可能となる。このセッション・プ
ロパティは、アプリケーション・プログラミング・イン
タフェース(すなわちＡＰＩ)を介してウェブ・セッショ
ンに属しているどのようなアプリケーションもアクセス
することができる。図４は、セッション特性にアクセス
するためのJavaクラスのサンプル定義であり、図５は、
セッション特性にアクセスするためのＣ言語ＡＰＩのサ
ンプル定義である。

【００３２】図４において、セッションが初期設定され
(４００)、現在時セッションに関するセッションＩＤが
ランチャから取得される(４０６)。セッションが有効で
ないとすれば(すなわちユーザが認証されていなけれ
ば)、Javaアプレットから出るか、他の適切な措置が取
られる(４０２)。一旦セッションが始まると、ログイン
が使用可能とされていれば(４０４)、Javaアプレットは
ユーザのログイン名を取得することができる(４０８)。
次に、Javaアプレットは、ログインが使用不可にされて
ない限りそのユーザに関するユーザ役割のリストを取り
出すことができる(４１０)。このJavaアプレットは、ま
た、実行時アクセス検査を実行することができる(４１
２)。この検査は、ＧＵＩを通して視認できるものより
一層きめこまかいアクセス制御を可能にする。

【００３３】図５において、ＣＧＩプログラムは、確保
した変数が真であればユーザが既にログインしているか
否かを検査する(５００)。ユーザがまだログオンしてい
なければ、確保した引数を真にセットしてOVwwwInitを
呼出し、ログイン・ページをユーザに提示する。ユーザ
がログインに成功した後、ＣＧＩプログラムは再び呼び
出される。図４のJavaアプレットと同様に、セッション
が有効でなければ、このＣＧＩプログラムから出るか、
または、他の適切な措置が取られる(５０２)。セッショ
ンが有効であれば、セッションＩＤが取得される(５０
４)。ログインが使用可能であれば(４０６)、ＣＧＩは
ユーザ名を取り出す(５０８)。ＣＧＩプログラムは、ま
た、ユーザの役割を取り出し(５１０)、ユーザが特定の
役割に属しているか検査する(５１２)。このＣＧＩは、
また、実行時アクセス検査を実施することができる(５
１４)。

【００３４】図３を再び参照すれば、セッション・プロ
パティLoginLoggingが使用可能とされていれば、ログ・
メッセージがログイン・ログ・ファイル３３２に書き込
まれる(３３０)。新しいセッションを作成する時、ovse
ssionmgrは、ランダムに生成されたセッション番号をov
loginに返し(３２８)、ユーザがログインしたという証
明の役目を果たすブラウザ・クッキーOvWebSessionを作
成する。ユーザがブラウザから出る時、あるいは、非活
動の構成期間の後セッションが時間切れとなった時、ク
ッキーは無効となりセッションは終了する。一旦ovsess
ionmgrがセッションの後の評価のためブラウザ・クッキ
ーOvWebSessionにセッション番号を記憶すると(このク
ッキーは現行セッションを検査するためovloginによっ
て使用される)、ユーザは、ＵＲＬを実行することによ
ってアクションを実行することができる。

【００３５】ランチャ・ウィンドウからＵＲＬを選択す
るか、ユーザのログインと共に自動的に実行されるよう
にランチャにＵＲＬ引数を与えるか、または、ウェブ・
ブラウザからＵＲＬを直接起動することによって、ＵＲ
Ｌは実行されることができる。ＵＲＬを選択するという
第１の方法におけるアクセス権限は、ランチャ初期設定
時に定義される。この場合、ユーザの役割によって認可
されるＵＲＬに対してＧＵＩをフィルタリングすること
によってユーザ役割アクセス制御が実施される。後者の
２つの方法におけるアクセス権限はＵＲＬ実行時に定義
される。この場合、ユーザ役割アクセス制御は実行時ア
クセス検査によって実施される。

【００３６】ランチャ初期設定およびＧＵＩフィルタリ
ング (ログイン・プロシージャの後)ovlaunchＣＧＩプログラ
ムを実行するデフォルト動作はランチャ・ウィンドウを
立ち上げることである。(デフォルト動作は、いかなる
ＵＲＬ引数をも必要とすることなくＣＧＩプログラムov
launchを要求することを指す。）ランチャ・ウィンドウ
は、現在時セッションに関してユーザ役割によって許容
される機能性すべてをユーザが利用することができるよ
うにするＧＵＩである。ランチャ・ウィンドウは、ユー
ザ役割構成によってユーザに許容される操作を提示する
多くの可能な方法の１つである。一般的概念は、ユーザ
が権限を与えられる操作だけをＧＵＩがユーザに提出す
るようにフィルタリングを行うことである。

【００３７】ランチャ・ウィンドウは、ユーザ役割に基
づく管理機能性(すなわちアクション)の表示を提供し、
ＵＲＬを介しその機能性を起動するJavaアプレットであ
る。ランチャ・ウィンドウは、その内容がランチャ登録
ファイルから取得される２つの部分、すなわち、管理機
能性および活動的ヘルプに分割される。管理機能性領域
は、管理操作のカテゴリを標示するタブ・セットを含
む。各カテゴリは小さいアイコンによって標示される。
カテゴリのリストは、例えば、タスク、ツール、オブジ
ェクト・ビュー、管理領域およびヘルプを含む。各カテ
ゴリの範囲内に、関連した操作の階層的な(ツリー・リ
スト)表現が存在する。これらのツリー・リストの内容
は、ユーザのユーザ役割(1)およびランチャ・セッショ
ンの局地性(2)によって決定される。ユーザが関連づけ
られるユーザ役割がランチャ・ウィンドウに現れる操作
を決定するが、ユーザが役割のサブセットを選択するこ
ともできる。

【００３８】ユーザは、コンテナ・ノードを開いたり閉
じたりする標準メカニズムを使用してツリー・リストを
逐次調べる。コンテナ・ノードを１回クリックすればノ
ードが広がる。葉ノードを１回クリックすれば、ＵＲＬ
を実行するためのものである関連アクションが起動され
る。ランチャ・カテゴリが空であれば(すなわちその下
にリスト項目がなければ)、カテゴリはユーザに提示さ
れない。ランチャ・コンテナ・エントリが空であれば、
コンテナ・エントリは表示されない。(これは空のメニ
ュ・カスケードに似ている。コンテナの下にただ１つの
項目が存在すればメニューの崩壊はない。）活動的ヘル
プ領域は、カーソルが置かれる操作の機能を説明する短
いヘルプ・メッセージを表示する。

【００３９】ランチャ・ウィンドウに表示されるアクシ
ョンは、セッションに関する活動的ユーザ役割に依存す
る。ユーザ役割は、通常は開発者によって提供されるが
管理者によって修正または補足されることができるラン
チャ登録ファイルを介して構成される。ランチャ登録フ
ァイルは以下の項目を含む： ・表示文字列、バージョン、著作権および説明を含むア
プリケーション情報。このブロックはランチャによって
表示されないが、ランチャ登録ファイルにおける有用な
情報を提供するためにだけこの項目は使用される。 ・タブ・ブロックは、オプションのアイコン・ファイル
名がリスト項目エントリを含むタブ上に表示されること
を可能にする。このブロックは、また、ユーザがタブを
選択する時に提示されるオプションの活動的ヘルプ・テ
キストを含む。 ・リスト・ブロックはリスト項目エントリを含む。リス
ト項目のコンポーネントは、優先順位値、リスト項目
名、アイコン、活動的ヘルプおよび機能を含む。２つの
可能な機能は、アクション機能およびリスト機能であ
る。アクション機能は、アクション定義を持つアクショ
ン・ブロックを指し示す終端リスト項目を示す。リスト
機能は、階層的ツリーの定義を可能にするため、リスト
・ブロックを指し示すコンポーネント・リスト項目を示
す。 ・アクション・ブロックは次のようないくつかのステー
トメントを含む。−アクションを起動するＵＲＬを含む
ＵＲＬステートメント。−このアクションに対するアク
セス権を持つユーザー役割のリストであるアクセス・ス
テートメント。アクセス・ステートメントが存在しなけ
れば、すべての有効なユーザがアクションにアクセスす
ることができる。ユーザ役割アクセス制御の要点はこの
ステートメントで定義される。−ＵＲＬがそこにロード
されるウィンドウの特性を指定するWebWindowステート
メント。

【００４０】図６は、ランチャ登録ファイルのサンプル
であり、これは、アプリケーション情報６００、リスト
項目エントリおよび２つの活動的アイコンを定義するタ
ブ・ブロック６０２、アクション・ブロックを指し示す
リスト・エントリを含むリスト・ブロック６０４、およ
び、各々がそのアクションに関して起動されるべきＵＲ
Ｌおよびそのアクションを実行する権限を与えられるユ
ーザ役割を含む２つのアクション・ブロック６０６(ａ)
および６０６０(ｂ)を含む。

【００４１】ランチャ初期設定の間にＧＵＩフィルタリ
ングによって実施されるウェブ・ブラウザにおけるユー
ザ役割アクセス制御が図７に示されている。ユーザは、
ウェブ・サーバ３０２に要求を送る(３０４)ウェブ・ブ
ラウザ３００を経由してovlaunchＵＲＬを起動する。ウ
ェブ・サーバ３０２はovlaunchreg７０２を起動して(７
００)、ランチャ登録ファイル７０６から登録情報を取
り出す(７０４)。Ovlaunchregは、次に、ovsessionmgr
３１６に関連して記憶されている情報から７０８のセッ
ション情報(すなわちユーザおよびユーザ役割)を取り出
す(７０８)。Ovlaunchregは、構文解析ライブラリを呼
び出して、登録情報を解析し、ユーザが認可されている
ユーザ役割に基づいてそれをフィルタリングする。その
関連アクションに関してユーザが認可されていれば、エ
ントリは、ウェブ・サーバ３０２、ウェブ・ブラウザ３
００およびランチャ・ウィンドウ７１４にそれぞれ返さ
れる(７１０、３０４、７１２)。いくつかのツリー・リ
ストが、ランチャ・ウィンドウにおいて、各々タブを付
けられた枠の上に構築される。結果として、ユーザは、
認可されているものだけを見るので、ランチャ・ウィン
ドウにおいて使用可能となっているすべてのＵＲＬに対
するアクセス権を持つ。

【００４２】アクション呼び出しおよび実行時アクセス
検査 ユーザに関する関連操作のＧＵＩフィルタリングに加え
て、ユーザが実際にアクションを起動する時の実行時ア
クセス検査によってアクセス制御を実施することができ
る。ユーザは、以下の最初２つの方法によって示される
ようにＣＧＩプログラムovlaunchの使用を通して、ある
いは、最後の方法によって示されるようにovlaunchを使
用せずにアクションを起動することができる。

【００４３】ユーザがアクションを起動することができ
る１つの方法は、ＵＲＬおよびその関連したアクション
に対応するランチャ・ウィンドウにおける項目をクリッ
クすることによるものである。ＧＵＩフィルタリングが
実施されていなくても、あるいは付加的セキュリティ・
レイヤとしてさえ、実行時アクセス検査をこのシナリオ
で実施することができる。アクション起動の結果、引数
として要求されたアクションのＵＲＬを使用するovlaun
chＣＧＩプログラムが起動される。ovlaunchＣＧＩプロ
グラムは、Ｃ言語ウェブ・セッションＡＰＩを使用し
て、有効なセッションがあることを検証するためovsess
ionmgrプログラムと対話する。ovlaunchＣＧＩプログラ
ムは、また、ＡＰＩ呼び出しを使用して、そのセッショ
ンに関する活動的ユーザ役割に基づいて特定のアクショ
ンを実行することをユーザが許可されていることを検証
する。

【００４４】ユーザがアクションを起動する別の１つの
方法は、ウェブ・ブラウザを使用してＵＲＬ引数でovla
unchに関するＵＲＬを起動するものである(例えばhttp:
//OvCgi/ovlaunch.exe?URL=http://some/path)。そこ
で、Ovlaunchは、ＵＲＬによって指定された要求アクシ
ョンを開始するが、そのアクションはセッションに関す
るユーザのアクセス権に依存する。これは、ブックマー
クとして保存されるアクションに対するアクセス権を得
るため役立つ。この動作は、また、ランチャ・ウィンド
ウの代わりに"代替コンソール"を開始するため使用する
ことができる。

【００４５】最後に、ユーザは、ウェブ・ブラウザから
直接その関連ＵＲＬを要求することによって(ovlaunch
ＣＧＩプログラムの介在なしに)アクションを起動する
ことができる。これは、制限された機能性にアクセスす
る潜在的"後方ドア"メカニズムを構成するので、付加的
セキュリティ・メカニズムが必要である。第１に、ウェ
ブ・ブラウザから見えるように構成されてない特別な"
保護された"ディレクトリにＨＴＭＬドキュメントが置
かれる。そこで、ovlaunchＣＧＩプログラムに対するＵ
ＲＬ引数としてそれらドキュメントを要求することによ
ってのみこれらＨＴＭＬドキュメントへのアクセスが可
能となる。ovlaunchＣＧＩプログラムは、ＨＴＭＬドキ
ュメントに関する"保護トされた"ディレクトリを検査し
て、ユーザが適切なアクセス権を持つとすればそれを返
す。"保護された"ディレクトリにおけるＨＴＭＬドキュ
メントは、それらを要求することによって直接取り出さ
すことはできない。第２に、ウェブ・アプリケーション
(本実施形態におけるＣＧＩプログラムおよびJavaアプ
レット)が、ウェブ・セッションＡＰＩを使用して実行
時アクセス検査を行うことができる。セッションが存在
すること(すなわちユーザが既にログインして認証され
ている)、および、要求されているアクションが現在時
ユーザに関するユーザ役割の中にあることをこれらプロ
グラムは確認することができる。ユーザがウェブ・アプ
リケーションによって表されるアクションに関する許可
を取得していないとすれば、プログラムから出るか、他
の適切なアクションをとることができる。

【００４６】ユーザはovlaunchＣＧＩプログラムを潜在
的にバイパスすることができるけれども、このプログラ
ムはいくつかの理由から必要とされる。第１に、ovlaun
chＣＧＩプログラムは、ＵＲＬを実行するための特別仕
様のウェブ・ブラウザ・ウィンドウの作成のような、セ
キュリティに関連しない他の役割を提供する。第２に、
ovlaunchは、"保護された"ディレクトリにおけるＨＴＭ
Ｌドキュメントに対する安全なアクセスを提供する。第
３に、ovlaunchは、ウェブ・セッションＡＰＩを使用す
るように修正されていないウェブ・アプリケーションに
関する一定レベルのアクセス検査を提供する。ユーザが
アクションを起動するためのＵＲＬを知らないとすれ
ば、これは特に真である。これは、既存のウェブ・アプ
リケーションの統合を一層容易にする。しかしながら、
一層高いレベルのセキュリティに関する限り、ウェブ・
アプリケーションがユーザ役割セキュリティに関連する
ウェブ・セッションＡＰＩを使用することが必要であ
る。

【００４７】図８は、ＣＧＩプログラムovlaunchを使用
してＵＲＬを介してユーザがアクションを起動する際実
行時アクセス検査によって実施されるウェブ・ブラウザ
におけるユーザ役割アクセス制御を示す。フィルタリン
グされてないメニュー項目をクリックすることによっ
て、あるいは、ovlaunchＵＲＬにＵＲＬ引数を直接提供
することによってウェブ・ブラウザ３００を経由して、
ユーザは、ランチャ・ウィンドウ７１４を介してアクシ
ョンを起動することができる。両方の要求はウェブ・サ
ーバ３０２に送られ(３０４，８１６)、結果としてＣＧ
Ｉプログラムovlaunchが実行される(３３８)。セッショ
ンが存在することを検証した後、ovlaunchは、ovsessio
nmgrに照会する(８０２)ことによって、要求されたアク
ションがユーザの活動的ユーザ役割のうちの１つによっ
て許可されているか否か検証することができる。Ovsess
ionmgrは、セッション初期設定時にovlaunchreg７０２
から取得した(７０８)ユーザ役割情報をキャッシュ記憶
した後、その結果をovlaunch３０８に返す(８０２)。ユ
ーザがアクション実行の権限を与えられていれば、ovla
unchregはウェブ・ブラウザへＨＴＭＬページを返し(３
３８、３０４)、その結果、起動されたＵＲＬによって
標示されるＣＧＩプログラム８１０の実行を要求する
(８１２)要求が自動的に出される(３０４)。

【００４８】図９は、ＣＧＩプログラムovlaunchを使用
せずに、ＵＲＬを介してユーザがアクションを起動する
際実行時アクセス検査によって実施されるウェブ・ブラ
ウザにおけるユーザ役割アクセス制御を示す。ユーザ
が、ＣＧＩプログラムovlaunchを使用せずに、ウェブ・
ブラウザ３００を通してＵＲＬに直接入力すると、ウェ
ブ・サーバ３０２は、起動されたＵＲＬによって標示さ
れるＣＧＩプログラム８１０を実行する(８１２)。起動
されたＵＲＬのＣＧＩプログラムは、ウェブ・セッショ
ンＣ言語ＡＰＩを使用して、ovsessionmgr３１６と通信
して、セッションが存在すること、および、要求されて
いるアクションが現在時ユーザに関するユーザ役割によ
って許可されていることを検証する。(前述の場合と同
様に、ovsessionmgrは、セッション初期設定時にovlaun
chreg７０２からユーザ役割情報を取得して、キャッシ
ュ記憶する。）セッションが存在し、ユーザがアクショ
ンに関して認可されていれば、ＣＧＩプログラムは、設
計されたアクション(例えばＵＲＬ実行)の実行を続行す
る。

【００４９】第２の好ましい実施形態 本発明の第２の好ましい実施形態において、ユーザのア
クション起動を認可または否定するユーザ役割アクセス
制御が任意のネットワーク環境において実行される。こ
の場合、アクセス規則がアクションに対するアクセス権
をユーザに与える。アクセス規則は、特定の操作セット
と特定のドメインの間の関係である。操作セットはその
英語表現Operation Setを短縮して以下op-setと呼称す
る場合がある。操作セットは、オブジェクトに関して取
られることができるアクションのセットである。大部分
の操作はオブジェクトの特定クラスに関するものである
が、一部の操作はオブジェクトに特定しない一般的操作
である。操作の例には、システムのリブート、ＡＴＭス
イッチの追加、ルートの検出およびレコードの追加が含
まれる。操作セットは、典型的には、プリンタの管理に
必要とされるすべてのアクションのような論理的に関連
するアクションのグループである。ドメインは、関心の
ある分野および責任分野に細分化することによって管理
環境のサイズおよび複雑さを減らすため使用されるオブ
ジェクトのセットである。ドメインは、管理される目標
オブジェクトを定義し、ドメイン内のすべてのオブジェ
クトに何らかの共通のアクセス制御ポリシーを適用する
目的からグループ化される。ドメインは、地理、ネット
ワーク・トポロジ、機能、組織のような種々の目的のた
め定義される。ドメインは、(例えば"すべてのルータ
ー"あるいは"WindowsNT4.0を実行するすべてのＰＣ"の
ような)規則セットの観点から定義されるか、または明
示的に定義されるメンバで定義される。

【００５０】典型的には、管理されるオブジェクトはユ
ーザ役割定義に暗示されている。例えば、１つのユーザ
役割が米国東部に関するネットワーク管理者であり、別
のユーザ役割が米国西部に関するネットワーク管理者で
ある。要求されたオブジェクトに対して要求された操作
が実行されることを許可するアクセス規則を含むユーザ
役割をユーザが持つとすれば、そのユーザはオブジェク
トに対する操作の実行の権限を与えられている。例え
ば、ＡがＰのメンバでありＸがＱのメンバであるよう
に、操作セットＰとドメインＱのペアとして定義される
アクセス規則を含むユーザ役割をあるユーザが与えられ
たとすれば、そのユーザはオブジェクトＸに対する操作
Ａを実行する権限を与えられる。本実施形態は、ユーザ
・アクセス権限の上に更にユーザ・アクセスに対する制
約を付加することを可能にする。例えば、時間制約が午
前８時０分と午後５時０分の間にユーザがログオンする
ように制限し、位置制約が、一定の物理的に安全保護さ
れたシステムへログオンする時にユーザがアクセス権を
取得するように制限することができる。

【００５１】本実施形態におけるユーザ役割アクセス制
御は、ヒューレット・パッカード社のOpenViewアプリケ
ーションにおいて実施されることができる。ユーザがOp
enViewアプリケーションへログオンする時、ユーザは、
この実施形態における１つまたは複数のユーザ役割を引
き受ける。ユーザは、ユーザが許可を与えられたユーザ
役割のすべてである付与されたユーザ役割を持つ。ログ
インする時、ユーザは、付与されたユーザ役割のサブセ
ットを請求する。これは、請求されたアクセス権または
活動的ユーザ役割と呼ばれる。活動的ユーザ役割が、ど
のメニューが表示されるか、どのオブジェクトが見える
かという観点からどのような種類のユーザ・インタフェ
ースをユーザが見るかを決定する。活動的ユーザ役割に
関する操作セットにおける操作のすべてがメニューおよ
びボタンのようなＧＵＩ制御機構を介して使用可能とさ
れる。活動的ユーザ役割の操作セットに現れない操作は
ＧＵＩ制御機構に現れない。ユーザが新しい役割を活動
的ユーザ役割のリストに追加すれば、それら操作に関す
るＧＵＩ制御機構がユーザ・インタフェースに現れる。
同様に、活動的ユーザ役割に関するアクセス規則に含ま
れるドメインの各々におけるオブジェクトのすべてがユ
ーザ・インタフェースを通して表示される。これらのド
メインにないオブジェクトはユーザ・インタフェースを
通して表示されない。ユーザの活動的ユーザ役割は、ま
た、ユーザがどの実行時操作を実行することができるか
を決定する。本実施形態において、(同僚が病気の時の
ように)ユーザがたまに一定の役割を必要する時に役立
つ特権の追加または削除を行うため、ユーザは役割を動
的に切り換えることができる。

【００５２】ユーザ・インタフェースにおける操作およ
びオブジェクトの存在は、操作およびオブジェクトが異
なるアクセス規則に属することができるので、ユーザが
そのオブジェクトに関するその操作を実行することがで
きることを意味しない。例えば、オブジェクトＸに対す
る操作ＡおよびオブジェクトＹに対する操作Ｂをユーザ
が実行することを許容するアクセス規則が存在しても、
これは、ユーザがオブジェクトＹに対する操作Ａを実行
することができることを意味しない。このような理由か
ら、また、セキュリティ管理者がオペレータのアクセス
権を変更するかもしれないという事実のため、本発明
は、実行時アクセス検査を含む。ユーザがオブジェクト
Ｘに対するアクションＡの実行を要求する時点で、Ａが
活動的ユーザ役割に関する操作セットのメンバであり、
Ｘがそのアクセス規則に関するドメインのメンバである
というアクセス規則(すなわちop-set/ドメイン・ペア)
が活動的ユーザ役割の１つに存在するか否か検査され
る。両方の条件が存在すればアクションが取られる。

【００５３】図１０は、本発明の第２の好ましい実施形
態のセキュリティ・モデルのサンプルを示す。このモデ
ルは、ユーザ役割１０００、操作セット１００２および
ドメイン１００４を定義する。この例では、ユーザJoe
SmithおよびSue Edwards１０１４がユーザ役割NFS_Admi
nistrator１００６のメンバである。彼らは、１つまた
は複数のオブジェクト・ドメイン１０１におけるオブジ
ェクト・セットに対する１つまたは複数の操作セット１
００８における操作セットを実行することのできるアク
セス規則１０２４、１０２６、１０２８、１０３０を有
する。op-setは、例えば、op-setNFS_Admin１０１６が
ＮＦＳサーバ読み取り、ＮＦサーバ構成、ノード読取り
および可視性という操作セットを含むように定義されて
いる。ドメインもまた、例えばdoc_serv1、ノード東
部、doc_serv1:/、doc_serv1：/ProjDocsを含むよう
に、定義されている。従って、例えば、Joe Smithがユ
ーザ役割NFS_Administratorにログインして、ドメイン
東部に対して(NFS_Admin操作セットに定義されている)
ＮＦサーバ読み取り操作を実行しようとすれば、アクセ
ス規則定義｛NFS_Admin,東部}が彼にアクセス権を与え
る。一方、彼がドメイン南部に対して同じことをしよう
とすると、{NFS_Admin,南部}を定義するアクセス規則が
存在しないため、アクセスは否定される。

【００５４】図１１は、本発明の第２の好ましい実施形
態におけるユーザ役割アクセス制御を更に例示してい
る。ここでは、ユーザ１１００、１１０２、１１０４が
１つまたは複数のユーザ役割１１１４、１１６に割り当
てられている(１１０６、１１０８、１１１０、１１１
２)。各ユーザ役割は、１つまたは複数のアクセス規則
１１１８、１１２０、１１２２、１１２４すなわち操作
セット１１２６、１１２８のドメイン１１３０、１１３
２に対するペアによって定義されている。例えば、ユー
ザ役割東部操作員は、{ルーター管理, 東部}および{セ
キュリティ管理、東部}という２つのアクセス規則を持
つ。

【００５５】ユーザ役割アクセス制御は、ユーザが１つ
または複数のユーザ役割にログインしたり役割を動的に
切り換えることを可能にする強力で広範囲なセキュリテ
ィ・モデルである。本発明の好ましい実施形態におい
て、ユーザが見るものをフィルタリングしたりユーザが
とるアクションについて実行時検査を行うためユーザ役
割アクセス制御がネットワーク環境で実施される。この
セキュリティ・モデルの機能は、柔軟な構成および実施
形態を提供することによって、従来技術モデルが遭遇す
るドメイン・モデル・セキュリティのような既存の問題
を解決する。

【００５６】本発明のユーザ役割アクセス制御の実施形
態が、ユーザが実行することができるアクションをＧＵ
Ｉ上でそれらアクションをフィルタリングすることによ
って決定されるという観点から主として記述されたが、
ユーザ役割アクセス制御を別の形態で実施することが可
能であることは理解されるべきである。ユーザが実行す
ることができるアクションを"舞台裏で"フィルタリング
することによってアクションを決定するためユーザ役割
アクセス制御を使用することもできる。この場合、ユー
ザがアクセス権を持つまたは持たない対象はユーザにと
って透過的である。例えば、ユーザ役割は、ユーザがア
クセス権を持つまたはそれに対してアクションを実行す
ることができるマシンをフィルタリングすることによっ
て、ユーザが実行することができるアクションを決定す
ることもできる。この例では、ユーザ役割は、ユーザ
が、マシン１およびマシン２上に存在するがマシン３上
には存在しないデータ・ファイルに対するアクセス権を
ユーザが持つことを決定することができる。ユーザがマ
シン１およびマシン２上のデータ・ファイルへのアクセ
ス権を有してはいるが、それらはユーザが見ることがで
きるようにＧＵＩに表示されず、むしろ、"舞台裏で"１
つまたは複数の活動的ユーザ役割によって決定される。

【００５７】以上、本発明の好ましい実施形態を詳細に
記述したが、本発明の概念は上記と異なる種々の形態で
実施されることができる点は理解されるべきであろう。

【００５８】本発明には、例として次のような実施様態
が含まれる。 (1)コンピュータ・オブジェクトに対するユーザのアク
セスを制御する装置であって、該装置が、１つまたは複
数のコンピュータ読み取り可能記憶媒体と、上記１つま
たは複数のコンピュータ読み取り可能記憶媒体に所在し
て１つまたは複数のユーザ役割を作成するプログラム・
コードと、を備え、上記１つまたは複数のユーザ役割の
各々がユーザ・セットに関連づけられたアクセス権限セ
ットを含み、上記アクセス権限の各々が上記ユーザ・セ
ットの中のユーザによって実行される上記コンピュータ
・オブジェクトに対するアクションを記述する、ユーザ
・アクセス制御装置。

【００５９】(2)該装置が上記１つまたは複数のコンピ
ュータ読み取り可能記憶媒体に所在する第２のプログラ
ム・コードを更に含み、該第２のプログラム・コード
が、所与のユーザがコンピュータ・セッションを初期化
するたび毎に上記１つまたは複数のユーザ役割のどれが
活動的であり該所与のユーザを参照するかを決定するス
テップと、活動的で所与のユーザを参照する上記１つま
たは複数のユーザ役割に基づき、また、上記１つまたは
複数のユーザ役割において所与のユーザに関連づけられ
ているすべてのアクセス権限によって決定されているも
のとして、上記ユーザ・セットの中のユーザによって取
られる上記コンピュータ・オブジェクトのセットに対す
る上記アクションをフィルタリングするステップと、を
含む、前記(1)に記載の装置。 (3)上記ユーザ・セットの中のユーザによって取られる
上記コンピュータ・オブジェクトのセットに対する上記
アクションをフィルタリングする上記ステップが、所与
のユーザがアクセスを許されているエレメントだけを該
所与のユーザに活動的に表示するように、該所与のユー
ザに提示される１つまたは複数のグラフィカル・ユーザ
・インタフェースのエレメントをフィルタリングするス
テップを含む、前記(2)に記載の装置。

【００６０】(4)該装置が上記１つまたは複数のコンピ
ュータ読み取り可能記憶媒体に所在する第３のプログラ
ム・コードを更に含み、該第３のプログラム・コードが
所与のユーザがアプリケーションを起動するたび毎に上
記１つまたは複数のユーザ役割のどれが活動的であって
該所与のユーザを参照するかを決定するステップと、活
動的で所与のユーザを参照する上記１つまたは複数のユ
ーザ役割に基づき、また、上記所与のユーザに関連づけ
られているすべてのアクセス権限によって決定されてい
るものとして、上記ユーザ・セットの中のユーザによっ
て取られる上記コンピュータ・オブジェクトのセットに
対する上記アクションをフィルタリングするステップ
と、を含む、前記(1)に記載の装置。 (5)上記ユーザ・セットの中のユーザによって取られる
上記コンピュータ・オブジェクトのセットに対する上記
アクションをフィルタリングする上記ステップが、所与
のユーザがアクセスを許されているエレメントだけを該
所与のユーザに活動的に表示するように、該所与のユー
ザに提示される１つまたは複数のグラフィカル・ユーザ
・インタフェースのエレメントをフィルタリングするス
テップを含む、前記(4)に記載の装置。

【００６１】(6)該装置が上記１つまたは複数のコンピ
ュータ読み取り可能記憶媒体に所在する第４のプログラ
ム・コードを更に含み、該第４のプログラム・コード
が、所与のユーザが所与のコンピュータ・オブジェクト
に対するアクションを実行しようとするたび毎に上記１
つまたは複数のユーザ役割のうちの１つの活動的ユーザ
役割において上記所与のユーザと上記所与のコンピュー
タ・オブジェクトが関連づけられていることを検証する
ステップと、上記１つまたは複数のユーザ役割のうちの
１つの活動的ユーザ役割において上記所与のユーザと上
記所与のコンピュータ・オブジェクトが関連づけられて
いる時にのみ上記所与のコンピュータ・オブジェクトに
対するアクセス権限を上記所与のユーザに付与するステ
ップと、を含む、前記(1)に記載の装置。

【００６２】(7)上記アクションのうちの所与のものが
ウェブ型環境におけるＵＲＬに対するアクセスを含む、
前記(1)に記載の装置。 (8)上記１つまたは複数のアクセス権限の各々が１つま
たは複数のアクセス規則によって決定され、上記１つま
たは複数のアクセス規則の各々が操作セット／オブジェ
クト・ドメインのペアを含み、上記オブジェクト・ドメ
インがユーザ役割において参照されたユーザがそれに対
するアクセス権限を持つ１つまたは複数のオブジェクト
を含み、上記操作セットがユーザ役割において参照され
たユーザが実行することができる１つまたは複数のアク
ションを含む、前記(1)に記載の装置。

【００６３】(9)コンピュータ・オブジェクトに対する
ユーザのアクセスを制御する方法であって、コンピュー
タ・セッションの間にアクションを実行する要求をユー
ザから受け取るステップと、上記要求に応答して上記ユ
ーザがそのメンバとして属する１つまたは複数のユーザ
役割を取り出すステップであって、上記１つまたは複数
のユーザ役割の各々が、上記セッションに関して上記ユ
ーザが有する１つまたは複数のアクセス権限を決定し、
上記１つまたは複数のアクセス権限が上記セッションの
間上記ユーザが実行することができる１つまたは複数の
アクションを決定する、ステップと、上記ユーザがメン
バである上記１つまたは複数のユーザ役割が上記要求さ
れたアクションを許可するアクセス権限を含むか否かを
決定することによって上記ユーザが上記要求されたアク
ションを実行する権限を与えられ手いるか否かを決定す
るステップと、を含む方法。 (10)上記１つまたは複数のアクセス権限が、ユーザがウ
ェブ環境における１つまたは複数のＵＲＬにアクセスす
ることができるか否かを決定する、前記(9)に記載の方
法。

【００６４】

【発明の効果】本発明のユーザ役割の利用によると、ユ
ーザの特定のジョブに見合う権限を付与するユーザ・ア
クセス制御モデルが実現される。

【図面の簡単な説明】

【図１】ユーザ・アクセス制御のドメイン・モデルを示
すブロック図である。

【図２】本発明において実施されるアクセス制御のユー
ザ役割モデルを示すブロック図である。

【図３】セッション・ログインに関連するコンポーネン
トを示すブロック図である。

【図４】セッション特性にアクセスするために使用され
るJavaクラスを定義するサンプル・コードである。

【図５】セッション特性にアクセスするために使用され
るＣ言語ＡＰＩ定義のサンプル・コードである。

【図６】ランチャ登録ファイルのサンプルを示すブロッ
ク図である。

【図７】ランチャ初期設定を通してＧＵＩをフィルタリ
ングすることによってウェブ・ブラウザにおいて実施さ
れるユーザ役割アクセス制御に関連するコンポーネント
を示すブロック図である。

【図８】ＵＲＬ実行時にovlaunchコンポーネントを使用
して実行時アクセス検査を行うことによってウェブ・ブ
ラウザにおいて実施されるユーザ役割アクセス制御に関
連するコンポーネントを示すブロック図である。

【図９】ＵＲＬ実行時にovlaunchコンポーネントを使用
せずに実行時アクセス検査を行うことによってウェブ・
ブラウザにおいて実施されるユーザ役割アクセス制御に
関連するコンポーネントを示すブロック図である。

【図１０】本発明の第２の好ましい実施形態に関するセ
キュリティ構成の例を示すブロック図である。

【図１１】本発明の第２の好ましい実施形態に関するセ
キュリティ・モデルのサンプルを示すブロック図であ
る。

【符号の説明】

２００、２０２、２０４ ユーザ役割 ２０６、２０８、２１０、２１２、２１４、２１６、２
１８、２２０、２２２
アクション ２２６、２２８、２３０ アクセス権限 ２３２ コンピュータ読み取り可
能記憶媒体

───────────────────────────────────────────────────── フロントページの続き (72)発明者 ブルース・シー・ウェルチ アメリカ合衆国98004ワシントン州ベルヴ ュー、ノースイースト・ファースト・スト リート 9563 (72)発明者 ジュディス・シー・ウォーカー アメリカ合衆国80525コロラド州フォー ト・コリンズ、サウスショアー・コート 4270

Claims (1)

【特許請求の範囲】
1. 【請求項１】コンピュータ・オブジェクトに対するユー
   ザのアクセスを制御する装置であって、 １つまたは複数のコンピュータ読み取り可能記憶媒体
   と、 上記１つまたは複数のコンピュータ読み取り可能記憶媒
   体に所在して１つまたは複数のユーザ役割を作成するプ
   ログラム・コードと、 を備え、 上記１つまたは複数のユーザ役割の各々がユーザ・セッ
   トに関連づけられたアクセス権限セットを含み、 上記アクセス権限の各々が上記ユーザ・セットの中のユ
   ーザによって実行される上記コンピュータ・オブジェク
   トに対するアクションを記述する、 ユーザ・アクセス制御装置。