Please share information how unboundid LDAP SDK is maintaining LDAP session. I want to know if possible we can access LDAP session and alter authentication state information.
How does this LDAP session is handled in the clustered node ?
It will be helpful if you provide some example on this.
Thanks in advance.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
LDAP is a connection-oriented protocol, and individual connections can last for long periods of time. In general, well-designed LDAP applications establish one or more connections and continue to reuse those connections over the life of the application. This is a big difference from protocols like HTTP where connections are very short-lived and it's not unusual for a client to create a separate connection for each request.
Whenever an LDAP connection is first established (which is basically just opening a TCP connection to the appropriate port on the directory server), that connection is unauthenticated. The client is free to issue any kind of request over that connection, but the server may decide to refuse to process some kinds of requests from clients, or limit the information that the client is allowed to access, until they complete a bind operation in order to authenticate. Once a successful bind has been processed, then any subsequent operations will be processed under the authority of that authenticated user, at least until another bind operation is processed on that connection to change the authenticated identity.
LDAP connections don't really need to maintain any state information because the server does that for them. However, if you want to determine the identity of the user as whom a connection is authenticated, you have two options. The first is to include an authorization identity request control in the bind request, which will cause the response to include a control that provides information about the user that was authenticated. The second is to use a "Who am I?" extended request, which will also provide the authorization identity, but can be requested at any time without needing to attach it to a bind operation. The javadoc for the com.unboundid.ldap.sdk.controls.AuthorizationIdentityRequestControl and com.unboundid.ldap.sdk.extensions.WhoAmIExtendedRequest includes example code that demonstrates how to use this capability.
The server may need to maintain state information about a user beyond just who is authenticated on a connection (e.g., if there have been multiple failed attempts to authenticate as a user, and an account should be locked after too many failed attempts, or if a user is only allowed to use the same password for a specified period of time before they will be required to change it). This is something that the server maintains, and the way in which that is done may vary from one server to another (although it is often accomplished through the use of operational attributes stored in a user's entry). You'll need to consult the documentation for whatever directory server you're using to learn about this.
If this doesn't answer your questions, then please provide more specific details about what it is that you want to know.
Neil
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Please share information how unboundid LDAP SDK is maintaining LDAP session. I want to know if possible we can access LDAP session and alter authentication state information.
How does this LDAP session is handled in the clustered node ?
It will be helpful if you provide some example on this.
Thanks in advance.
LDAP is a connection-oriented protocol, and individual connections can last for long periods of time. In general, well-designed LDAP applications establish one or more connections and continue to reuse those connections over the life of the application. This is a big difference from protocols like HTTP where connections are very short-lived and it's not unusual for a client to create a separate connection for each request.
Whenever an LDAP connection is first established (which is basically just opening a TCP connection to the appropriate port on the directory server), that connection is unauthenticated. The client is free to issue any kind of request over that connection, but the server may decide to refuse to process some kinds of requests from clients, or limit the information that the client is allowed to access, until they complete a bind operation in order to authenticate. Once a successful bind has been processed, then any subsequent operations will be processed under the authority of that authenticated user, at least until another bind operation is processed on that connection to change the authenticated identity.
LDAP connections don't really need to maintain any state information because the server does that for them. However, if you want to determine the identity of the user as whom a connection is authenticated, you have two options. The first is to include an authorization identity request control in the bind request, which will cause the response to include a control that provides information about the user that was authenticated. The second is to use a "Who am I?" extended request, which will also provide the authorization identity, but can be requested at any time without needing to attach it to a bind operation. The javadoc for the com.unboundid.ldap.sdk.controls.AuthorizationIdentityRequestControl and com.unboundid.ldap.sdk.extensions.WhoAmIExtendedRequest includes example code that demonstrates how to use this capability.
The server may need to maintain state information about a user beyond just who is authenticated on a connection (e.g., if there have been multiple failed attempts to authenticate as a user, and an account should be locked after too many failed attempts, or if a user is only allowed to use the same password for a specified period of time before they will be required to change it). This is something that the server maintains, and the way in which that is done may vary from one server to another (although it is often accomplished through the use of operational attributes stored in a user's entry). You'll need to consult the documentation for whatever directory server you're using to learn about this.
If this doesn't answer your questions, then please provide more specific details about what it is that you want to know.
Neil