属性ベースのアクセス制御の概要

ポリシーが適用される対象リソース。リソースターゲットは次のような形をとる。domain:entity:action被験者が実行しようとしているアクションを反映します（directory:userprofile:edit ）。 

ターゲットはユーザーが何をしようとしているかを反映し、通常はリソースを編集、表示、または削除するための API 呼び出しに相当します。ポリシーはターゲットに関連付けられます。

ポリシーの対象は、ポリシーが適用されるユーザー、グループ、またはクライアントです。ポリシーには 1 つの主題のみを含めることができます。サブジェクトには次のメンバーが含まれます。

• タイプ：ポリシーが単一のユーザー、ユーザー グループ、特定の OAuth クライアント、またはリソースにアクセスするすべてのユーザー/クライアントに適用されるかどうかを示します。タイプ属性は、ユーザー、グループ、クライアント、またはすべてのいずれかである必要があります。
• id ：ユーザー/グループ/クライアントの GUID。サブジェクトタイプがすべての場合、この値は無視されます。

ポリシーの効果は、条件が満たされたときにポリシーがアクセスを許可するか、条件が満たされたときに直ちにアクセスを拒否するかを示します。ユーザーが ALLOW ポリシーの条件を満たし、必要な権限を持ち、DENY ポリシーによってブロックされていない場合は、リソースへのアクセスが許可されます。

ABAC は、既存のロールベースのアクセス制御や部門別アクセス制御に代わるものではありません。これらと連携して動作し、よりきめ細かなアクセス制御を提供します。ABAC ポリシー評価の結果が ALLOW の場合、システムはアクセスを許可する前に、サブジェクトに必要な権限があるかどうかを確認します。

DENY 効果を持つポリシーは、リソースへのアクセスを拒否する必要がある条件を指定します。ユーザーが DENY ポリシーの条件に一致する場合、同じリソースの ALLOW ポリシーの条件にも一致しているかどうかに関係なく、アクセスは拒否されます。

リソースに少なくとも 1 つのポリシーが添付されているが、ユーザーがいずれのポリシーの条件にも一致しない場合、ユーザーはデフォルトでリソースへのアクセスを拒否されます。

(オプション) ポリシーがアクセスを許可または拒否する特定の条件を確立します。

評価される各条件は、次の基本パターン (JSON で表されます) で表されます。 "attribute.one": { "comparison_operation": "attribute.two" }

ポリシーが評価されると、システムは指定された属性名に対応する属性を取得し、指定された操作を使用してそれらを比較します。

より複雑な条件ロジックを可能にするために、複数の条件を Any (論理 OR を表す) または All (論理 AND を表す) 構造内にネストすることもできます。

(オプション) システムの属性データと比較される、静的な定義済み属性のマップ。たとえば、ポリシー作成者は、特定のロール ID を持つすべてのユーザーにアクセスを許可したい場合、該当するロール ID をポリシー内の事前設定された属性として指定します。

ポリシー作成者は、事前設定された属性名を設定します。システムによって提供される既存の属性と競合する名前は、検証時に拒否されます。プリセット属性名には、英数字、ピリオド (.)、アンダースコア (_) を含めることができますが、リストされているもの以外のスペースや特殊文字は使用できません。

各マップ エントリには、プリセット属性の名前であるキーと、次のメンバーを持つ TypedAttribute オブジェクトである値があります。

• タイプ：属性の基本データ型。
• 価値：属性の値の文字列表現。