SharePoint のクレームベース ID
SharePoint のクレームベース ID アーキテクチャの基本事項について説明します。
クレーム ベース認証
クレームベース認証を使用すると、ユーザーが必要以上に個人情報 (社会保障番号や誕生日など) を公開しなくても、システムおよびアプリケーションがそのユーザーを認証できます。 クレームベース認証のクレームの例としては、"18 歳を超えている" や "会社のマーケティング グループに所属している" などが挙げられます。 外部システム (証明書利用者) は、これらのクレームを検証できる認証機関を信頼するだけで、特定の機能についてユーザーを認証できます。
クレーム: 認証対象に関する一連の情報
クレームについて明確に理解するには、これを認証対象に関する一連の情報としてとらえます。 認証対象のほとんどは人物ですが、アプリケーション、コンピューターなどのように、人物以外の場合もあります。 ネットワーク経由で送信された ID は、ある種のトークン (セキュリティ トークンとしても知られています) によって表されます。
要求とは、クレーム プロバイダーがそのサブジェクトについてアサートするサブジェクトに関する情報です。 これは、それ自体または別のサブジェクトに関するサブジェクトによって行われるサブジェクト (名前など) に関するステートメントです。 要求は、電子メール アドレス、名前、年齢、販売ロールのメンバーシップなどの ID 情報のビットと考えることができます。 これは、特定のユーザー、アプリケーション、コンピューター、またはその他のエンティティを表す一意の識別子です。 資格情報を何回も入力しなくても、こうしたエンティティが複数のリソース (アプリケーション、ネットワーク リソースなど) にアクセスできるようにします。 また、この ID を利用すると、リソース側でエンティティからの要求を検証することもできます。 アプリケーションが受け取る要求が多いほど、ユーザーについてより多くの情報が得られてきます。
クレームには 1 つ以上の値が与えられ、セキュリティ トークン サービス (STS) が発行するセキュリティ トークンにパッケージ化されます。
クレームという言葉はその配信方法により、エンタープライズ ディレクトリ環境でよく使用される属性という言葉の代わりに使用されます。 このモデルでは、アプリケーションではディレクトリ内のユーザー属性が検索されません。 代わりに、ユーザーはクレームをアプリケーションに配信します。 各クレームが発行者によって作成され、クレームの発行者を信頼できる場合は、そのクレームを信頼します。 たとえば、ユーザーが作成したクレームよりも、会社のドメイン コントローラーが作成したクレームを信頼します。 クレーム API には issuer プロパティがあり、このプロパティにより、誰がクレームを発行したかを確認できます。
トークン: ID に関する情報
トークンは、ID に関する情報を表すバイトのセットです。 この情報は 1 つ以上の要求で構成され、それぞれにこのトークンが適用されるサブジェクトに関する情報が含まれています。 トークン内の要求には、通常、それを提示するユーザーの名前などの情報が含まれます。 また、他の多くの種類の情報を含めることもできます。要求は、サブジェクトの名前に限定されるものではなく、サブジェクトの名前を含める必要もありません。 また、要求という言葉が示すように、トークンを受け取るアプリケーションは、トークンに含まれる情報を自動的に受け入れることはありません。 代わりに、受信したトークンは通常、アプリケーションが含まれる要求を使用する前に、何らかの方法で検証されます。
重要なのは、クレームは、単にリソース、アプリケーション、またはユーザーを識別するだけの一意の識別子ではないという点です。 リソース、アプリケーション、またはユーザーについて記述するときに使用するのが一連のクレーム (つまり、値) です。 また、クレームはアクセスの認証にも使用されます。