4. État d'autorisation
Chaque session LDAP possède un état d'autorisation associé. Cet état est constitué de nombreux facteurs, tels que l'état d'authentification (le cas échéant) établi, la manière dont il l'a été et les services de sécurité en place. Certains facteurs peuvent être déterminés et/ou affectés par des événements du protocole (par exemple Bind, StartTLS ou la fermeture de TLS), et d'autres peuvent être déterminés par des événements externes (par exemple l'heure ou la charge du serveur).
Bien qu'il soit souvent commode d'envisager l'état d'autorisation en termes simplistes (comme nous le faisons souvent dans la présente spécification technique), par exemple « un état anonyme », il convient de noter que les systèmes d'autorisation des implémentations LDAP mettent couramment en jeu de nombreux facteurs qui s'articulent de manière complexe.
L'autorisation dans LDAP est une affaire locale. L'un des facteurs clés des décisions d'autorisation est l'identité d'autorisation. L'opération Bind (définie à la section 4.2 de [RFC4511] et examinée plus en détail à la section 5 ci-dessous) permet l'échange d'informations entre le client et le serveur afin d'établir une identité d'autorisation pour la session LDAP. L'opération Bind peut également servir à faire passer la session LDAP dans un état d'autorisation anonyme (voir la section 5.1.1).
Lors de l'établissement initial de la session LDAP, celle-ci possède une identité d'autorisation anonyme. Cela implique notamment que le client n'a pas besoin d'envoyer de BindRequest dans la première PDU de la couche de messages LDAP. Le client peut envoyer toute demande d'opération avant d'effectuer une opération Bind, et le serveur DOIT (MUST) la traiter comme si elle avait été effectuée après une opération Bind anonyme (section 5.1.1).
À la réception d'une demande Bind, le serveur fait immédiatement passer la session dans un état d'autorisation anonyme. Si la demande Bind réussit, la session passe à l'état d'authentification demandé, avec l'état d'autorisation qui lui est associé. Sinon, la session reste dans un état anonyme.
Il convient de noter que d'autres événements internes ou externes à LDAP peuvent entraîner le passage des états d'authentification et d'autorisation à un état anonyme. Par exemple, l'établissement, la modification ou la fermeture de services de sécurité des données peut entraîner un passage à un état anonyme, ou les informations d'authentification de l'utilisateur (par exemple un certificat) peuvent avoir expiré. Le premier cas est un exemple d'événement interne à LDAP, tandis que le second est un exemple d'événement externe à LDAP.