4. 認可状態

すべての LDAP セッションは, 関連付けられた認可状態を持つ. この状態は, どのような (もしあれば) 認証状態が確立されたか, それがどのように確立されたか, どのようなセキュリティサービスが整っているかなど, 多数の要因から成る. 一部の要因はプロトコルイベント (例えば Bind, StartTLS, TLS クローズ) によって決定および/または影響され, 一部の要因は外部イベント (例えば時刻やサーバー負荷) によって決定されることがある.

認可状態を (本技術仕様でしばしば行うように) "匿名状態" といった単純化した言葉で捉えると便利なことが多いが, LDAP 実装における認可システムは一般に, 複雑に相互関連する多くの要因を伴うことに留意されたい.

LDAP における認可はローカルな事項である. 認可の決定における主要な要因の一つは認可アイデンティティである. Bind 操作 ([RFC4511] の 4.2 節で定義され, 以下第 5 節でさらに論じる) は, LDAP セッションの認可アイデンティティを確立するためにクライアントとサーバーの間で情報を交換することを可能にする. Bind 操作は, LDAP セッションを匿名認可状態へ移行させるためにも用いられることがある (5.1.1 節参照).

LDAP セッションが最初に確立された時点で, そのセッションは匿名認可アイデンティティを持つ. とりわけこのことは, クライアントが LDAP メッセージ層の最初の PDU で BindRequest を送る必要がないことを意味する. クライアントは Bind 操作を行う前に任意の操作要求を送ってよく, サーバーはそれを匿名 Bind 操作 (5.1.1 節) の後に行われたものとして扱わなければならない (MUST).

サーバーは Bind 要求を受信すると, 直ちにセッションを匿名認可状態へ移行させる. Bind 要求が成功した場合, セッションは要求された認証状態とそれに関連付けられた認可状態へ移行する. そうでなければ, セッションは匿名状態のままである.

LDAP の内部および外部の他の事象によっても, 認証状態と認可状態が匿名のものへ移行しうることに留意されたい. 例えば, データセキュリティサービスの確立, 変更, またはクローズによって匿名状態へ移行することがあり, またユーザーの資格情報 (例えば証明書) が失効していることもある. 前者は LDAP 内部の事象の例であり, 後者は LDAP 外部の事象の例である.