サブジェクト、ユーザー、プリンシパルの意味と違いは何ですか？
セキュリティフレームワークのコンテキストでは、いくつかの用語がよく発生しますsubject、ser、およびprincipal。定義とそれらの違い。
それで、これらの用語は正確に何を意味し、なぜsubjectとprincipalのこれらの区別が必要なのでしょうか？
これらは、属、種、個体が階層的であるように階層的です。
- Subject-セキュリティコンテキストでは、subjectはobjectへのアクセスを要求するエンティティです。これらは、アクセスを要求しているものと要求が行われているものを示すために使用される一般的な用語です。アプリケーションにログオンすると、あなたがサブジェクトになり、アプリケーションがオブジェクトになります。誰かがあなたのドアをノックすると、訪問者はアクセスを要求する対象であり、あなたの家はオブジェクトへのアクセスが要求される対象です。
- プリンシパル-アカウント、ロール、またはその他の一意の識別子で表されるsubjectのサブセット。実装の詳細レベルに到達すると、プリンシパルはアクセス制御リストで使用する一意のキーになります。人間のユーザー、自動化、アプリケーション、接続などを表します。
- ユーザー-principalのサブセットは、通常人間のオペレーターを指します。 「ユーザー」または「ユーザーID」という言葉は一般的に「アカウント」と交換されるため、この区別は時間とともに曖昧になります。ただし、principalsである広範なクラスと、非決定的な方法でトランザクションを駆動する対話型演算子であるこれらのサブセットを区別する必要がある場合、「ユーザー」が適切なWordです。
サブジェクト/オブジェクトは、文法で使用されるのと同じ用語を継承します。文では、主題は俳優であり、オブジェクトは作用するものです。この意味では、コンピューターが発明される前から使用されています。セキュリティコンテキストでは、サブジェクトは要求を行うことができるものすべてです。上記のように、これはITセキュリティに限定される必要はなく、非常に広範な分類です。興味深いのは、サブジェクトがオブジェクトを暗示していることです。オブジェクトがなければ、サブジェクトはありません。
プリンシパルは、サブジェクトが解決する対象です。あなたがクレジットカードを提示するとき、あなたは対象であり、口座番号は本人です。他のコンテキストでは、ユーザーIDまたは州発行のIDがプリンシパルです。ただし、プリンシパルは、人ではない多くの種類のサブジェクトに関連付けることができます。アプリケーションがシステムレベルの機能を要求する場合、プリンシパルは署名された実行可能コードモジュールの署名者になる場合がありますが、その場合でも、要求を実行するユーザーは依然としてサブジェクトです。
ユーザーは、通常は対話型演算子を指すという点で、サブジェクトまたはプリンシパルよりも具体的です。そのため、グラフィカルプリンシパルインターフェイスではなく、グラフィカルユーザーインターフェイスがあります。ユーザーはsubjectのインスタンスであり、principalに解決されます。 1人のユーザーは任意の数のプリンシパルに解決できますが、どのプリンシパルも1人のユーザーに解決することが期待されます（人々がIDを共有しないという要件を順守すると仮定します）。上記の例では、実行可能コードモジュールの署名者は間違いなくnotユーザーですが、isは有効なプリンシパルです。モジュールをロードしようとする対話型オペレーターはユーザーです。
コメントで述べたように、権威ある情報源でさえこれらの条件に同意していません。この応答を準備しながら、NIST、SANS、IEEE、MITRE、およびセキュリティ試験ガイドなどのいくつかの「準信頼」ソースを検索しました。少なくとも準信頼できる単一の情報源は、3つの用語すべてを網羅しておらず、その使用法はすべて大きく異なりました。これはshouldという用語がどのように使用されるかについての私の見解です。しかし、実用的な観点から、深夜にマニュアルを熟読する場合、定義はベンダーまたはライターが言うものである傾向がありますあります。ここでの回答が、これらの用語を使用して水域をナビゲートし、セキュリティ文書を解析するのに十分な洞察を提供することを願っています。
私の 認証コンセプトマップ を見てください：
用語は [〜＃〜] jaas [〜＃〜] から取ったものだと思います。
アプリケーションがJAAS認証を使用してユーザー（またはサービスなどの他のエンティティ）を認証すると、結果としてSubjectが作成されます。サブジェクトの目的は、認証されたユーザーを表すことです。 サブジェクトは一連のプリンシパルで構成され、各プリンシパルはそのユーザーのIDを表します。たとえば、サブジェクトに名前プリンシパル（「スーザンスミス」）と社会保障番号プリンシパル（「987-65-4321」）を設定して、このサブジェクトを他のサブジェクトと区別することができます。
Subjectは、サービスを要求するエンティティです。ユーザーまたはプロセスを指定できます。おそらくそれが、ユーザーではなくサブジェクトという名前が選択された理由です。
サブジェクトがサービスにアクセスしようとする場合、最初にサブジェクトを認証する必要があります。認証が成功すると、そのサブジェクトのセキュリティプリンシパルが読み込まれます。たとえば、ロールベースのアクセス制御システムでは、認証された（ログインした）ユーザーは通常、userIdとroleIdの2つのプリンシパルを持ちます。このようなシステムでは、権限（つまり、誰が何にアクセスできるか）がロールとユーザーの両方に指定されます。承認中（つまり、要求されたサービスを許可するかどうかを確認する）、セキュリティシステムは両方のプリンシパルに対するアクセシビリティを確認します。
したがって、認可の観点から見ると、プリンシパルはアクセスが許可または拒否される実際のエンティティです。サブジェクトは、一部のプリンシパルを保持するユーザー/スレッド/プロセスです。
T.Robが説明したように、Subjectはオブジェクトへのアクセスを要求するエンティティです。その時点から、javax.security.auth.Subjectコードに関するコメントを見つけました。これは非常に便利で理解しやすいとわかりました。
「サブジェクトは複数のアイデンティティを持つ可能性があります。各アイデンティティはサブジェクト内のプリンシパルとして表されます。プリンシパルは単に名前をサブジェクトにバインドします。たとえば、たまたまアリスであるサブジェクトには2つのプリンシパルがあります。 Alice Bar」、彼女の運転免許証の名前、被験者、および「999-99-9999」、彼女の学生識別カードの番号を被験者にバインドします。両方のプリンシパルは、それぞれが同じ被験者を参照します別の名前があります。」
それが役に立てば幸い。
これは link Oracleからの以下の説明Java SE Documentation。
サブジェクト、プリンシパル、認証、および資格情報リソースへのアクセスを許可するには、アプリケーションは最初にリクエストのソースを認証する必要があります。 JAASフレームワークは、リクエストのソースを表す用語subjectを定義します。サブジェクトは、個人やサービスなどの任意のエンティティです。サブジェクトは javax.security.auth.Subject クラスで表されます。
Authenticationは、サブジェクトのIDを検証するプロセスを表し、安全な方法で実行する必要があります。そうしないと、加害者が他人になりすましてシステムにアクセスする可能性があります。通常、認証には、身元を証明する何らかの形の証拠を示すサブジェクトが含まれます。そのような証拠は、被験者のみが知っているまたは持っている可能性が高い情報（パスワードや指紋など）であるか、被験者のみが生成できる情報（秘密鍵を使用した署名データなど）である可能性があります。
認証されると、サブジェクトには関連付けられたアイデンティティ、またはPrincipals（タイプ Java.security.Principal ）が入力されます。サブジェクトには多くのプリンシパルが含まれる場合があります。たとえば、個人には名前プリンシパル（ "John Doe"）とSSNプリンシパル（ "123-45-6789"）があり、他のサブジェクトと区別されます。
サブジェクトは、関連付けられたプリンシパルに加えて、credentialsと呼ばれるセキュリティ関連の属性を所有できます。クレデンシャルには、新しいサービスに対するサブジェクトの認証に使用される情報が含まれる場合があります。そのような資格情報には、パスワード、Kerberosチケット、および公開鍵証明書が含まれます。資格情報には、サブジェクトが特定のアクティビティを実行できるようにするデータも含まれる場合があります。たとえば、暗号化キーは、サブジェクトがデータに署名または暗号化できるようにする資格情報を表します。パブリックおよびプライベートの資格クラスは、コアJ2SE APIの一部ではありません。したがって、どのクラスも資格を表すことができます。