回答:
これらは、属、種、個体が階層的であるように階層的です。
サブジェクト/オブジェクトは、文法で使用されるのと同じ用語を継承します。文では、主語は俳優で、主語は演じられるものです。この意味で、コンピューターが発明される前から使用されています。セキュリティコンテキストでは、サブジェクトは要求を行うことができるすべてのものです。上記のように、これはITセキュリティに限定される必要はないため、非常に広い分類になります。興味深いのは、主語が目的を意味するということです。オブジェクトがなければ、主題はありません。
プリンシパルは、被験者が解決するものです。クレジットカードを提示すると、あなたが主体となり、口座番号が本人となります。他のコンテキストでは、ユーザーIDまたは州発行のIDがプリンシパルです。しかし、プリンシパルは、人間ではない多くのタイプのサブジェクトに関連付けることができます。アプリケーションがシステムレベルの機能を要求する場合、プリンシパルは署名された実行可能コードモジュールの署名者である場合がありますが、その場合でも、要求を駆動するユーザーが対象になります。
ユーザーは、主に対話型のオペレーターを指すという点で、件名や主体よりも具体的です。これが、グラフィカルプリンシパルインターフェースではなく、グラフィカルユーザーインターフェースがある理由です。ユーザーは、プリンシパルに解決されるサブジェクトのインスタンスです。1人のユーザーは任意の数のプリンシパルに解決できますが、すべてのプリンシパルは1人のユーザーに解決されることが予想されます(IDを共有しないという要件を人々が遵守していると想定)。上記の例では、実行可能コードモジュールの署名者は間違いなくユーザーではありませんが、有効なプリンシパルです。モジュールをロードしようとする対話式オペレーターはユーザーです。
コメントに記載されているように、信頼できる情報源でさえこれらの条件に同意していません。この応答を準備している間、私はNIST、SANS、IEEE、MITRE、およびセキュリティ試験ガイドなどのいくつかの「準信頼できる」情報源を検索しました。少なくとも準信頼できるものであると私が見つけた単一の情報源は、3つすべての用語をカバーしておらず、それらの使用法はすべて大幅に異なっていました。これは、用語がどのように私のテイクである必要があります使用することが、実用上の観点から、あなたが夜中に取扱説明書を熟読の上にされている場合、定義はベンダーやライターは、彼らが言う何でもする傾向があります。うまくいけば、ここでの応答が水をナビゲートし、これらの用語を使用してセキュリティドキュメントを解析するのに十分な洞察を提供することを願っています。
John (human) SUBJECT > username_1 PRINCIPAL > password_1 USER
John (human) SUBJECT > username_1 PRINCIPAL > password_2 USER
John (human) SUBJECT > username_1 PRINCIPAL > smartcard_1 USER
John (human) SUBJECT > username_1 PRINCIPAL > cellphone_1 USER
私の認証コンセプトマップを見てください:
用語はJAASから取ったものだと思います。
アプリケーションがJAAS認証を使用してユーザー(またはサービスなどの他のエンティティ)を認証すると、結果としてサブジェクトが作成されます。サブジェクトの目的は、認証されたユーザーを表すことです。サブジェクトは一連のプリンシパルで構成され、各プリンシパルはそのユーザーのIDを表します。たとえば、サブジェクトの名前はプリンシパル( "スーザンスミス")と社会保障番号のプリンシパル( "987-65-4321")にすることができるため、このサブジェクトを他のサブジェクトと区別できます。
サブジェクトは、サービスを要求するエンティティです。これは、ユーザーまたはプロセスです。おそらくそれが、ユーザーではなくサブジェクトという名前が選ばれた理由です。
サブジェクトがサービスにアクセスしようとするとき、サブジェクトは最初に認証される必要があります。認証が成功すると、そのサブジェクトのセキュリティプリンシパルがロードされます。たとえば、役割ベースのアクセス制御システムでは、認証された(ログインした)ユーザーには通常、userIdとroleIdの2つのプリンシパルがあります。そのようなシステムでは、特権(つまり、誰が何にアクセスできるか)は、ロールとユーザーの両方に指定されます。承認中(つまり、要求されたサービスを許可する必要があるかどうかのチェック)、セキュリティシステムは両方のプリンシパルに対するアクセス可能性をチェックします。
したがって、承認の観点から見ると、プリンシパルはアクセスが許可または拒否される実際のエンティティです。サブジェクトは、いくつかのプリンシパルを保持するユーザー/スレッド/プロセスです。
T.Robが説明したように、Subjectはオブジェクトへのアクセスを要求するエンティティです。その時点から、私はjavax.security.auth.Subjectコードに関するコメントを見つけました。非常に便利で理解しやすいコードです。
「サブジェクトは複数のアイデンティティを持つ可能性があります。各アイデンティティはサブジェクト内のプリンシパルとして表されます。プリンシパルは単にサブジェクトに名前をバインドします。たとえば、人であるサブジェクトのアリスは2つのプリンシパルを持つ可能性があります。彼女の運転免許証上の名前である「アリスバー」とサブジェクトの別の名前、および「999-99-9999」(彼女の学生IDカード上の番号)をサブジェクトにバインドします。どちらのプリンシパルも、それぞれが同じサブジェクトを参照します別の名前です。」
それが役に立てば幸い。
これは、Oracle JAVA SEドキュメントからの以下の説明へのリンクです。
サブジェクト、プリンシパル、認証、および資格情報リソースへのアクセスを承認するには、まずアプリケーションがリクエストのソースを認証する必要があります。JAASフレームワークでは、リクエストのソースを表すサブジェクトという用語を定義しています。サブジェクトは、個人やサービスなどの任意のエンティティです。サブジェクトは、javax.security.auth.Subjectクラスによって表されます。
認証は、サブジェクトのIDが検証されるプロセスを表し、安全な方法で実行する必要があります。そうでなければ、加害者はシステムにアクセスするために他人になりすます可能性があります。認証には通常、サブジェクトがその身元を証明する何らかの形の証拠を示すことが含まれます。そのような証拠は、対象だけが知っているまたは持っている可能性が高い情報(パスワードや指紋など)、または対象だけが生成できる情報(秘密キーを使用した署名付きデータなど)の場合があります。
認証されると、サブジェクトには関連するIDまたはプリンシパル(java.security.Principalタイプ)が入力されます。サブジェクトは多くのプリンシパルを持つことができます。たとえば、人には、プリンシパル( "John Doe")とSSNプリンシパル( "123-45-6789")という名前があり、他のサブジェクトと区別されます。
サブジェクトは、関連付けられたプリンシパルに加えて、資格情報と呼ばれるセキュリティ関連の属性を所有する場合があります。クレデンシャルには、新しいサービスの対象を認証するために使用される情報が含まれる場合があります。このような資格情報には、パスワード、Kerberosチケット、および公開鍵証明書が含まれます。資格情報には、サブジェクトが特定のアクティビティを実行できるようにするデータが含まれている場合もあります。たとえば、暗号化キーは、サブジェクトがデータに署名または暗号化できるようにする資格情報を表します。パブリックおよびプライベートの資格情報クラスは、コアJ2SE APIの一部ではありません。したがって、どのクラスでも資格を表すことができます。
rahulmohanによると、私は、認証がサブジェットになる前、認証がプリンシパルになった後、本質的に、サブジェットは多くのプリンシパルを持つことができると思います