|
From: Neil W. <nei...@pi...> - 2020-08-28 15:07:39
|
I answered this question on GitHub ( https://github.com/pingidentity/ldapsdk/issues/92), but here’s my response: It is very unlikely that you actually want to do this. The LDAP simple bind operation (which I assume is what you’re using) expects the password to be provided in the clear and without any kind of transformation. This is also true of the PLAIN SASL mechanism. Some other SASL mechanisms, like CRAM-MD5, DIGEST-MD5, and the SCRAM mechanisms, send a digest generated from the password and other information, but even in those cases, you should provide the password to the bind request in the clear-text, unencoded form and let the LDAP SDK generate the proper encoded representation. When an LDAP client sends the bind request to the server, the password (like other LDAP values) is transmitted as an ASN.1 BER octet string. This holds the raw bytes that comprise the password. LDAP generally expects strings to be converted to bytes using the UTF-8 character encoding, and if you provide the password to the LDAP SDK as a string, then the bind request that it sends to the server will contain the bytes for the UTF-8 representation of that password. In the event that you actually need to use some other character encoding, or if the password includes bytes that can’t be represented in a UTF-8 string, then you should provide the password as a byte array rather than as a string when creating the bind request. Even though the LDAPConnection.bind method that takes a bind DN and password only allows you to provide the password as a string, there is a second version of the LDAPConnection.bind method that takes a BindRequest object. You’re almost certainly using an LDAP simple bind, so you should create a SimpleBindRequest object to pass to the LDAPConnection.bind method, and SimpleBindRequest does allow you to provide the raw bytes that comprise the password. Another possibility is that you’re getting confused by seeing the password in an encoded form when you retrieve the entry from the server. There are two potential reasons for this: - Most directory servers don’t actually store the password in the clear. Instead, they encode the password using some scheme in an attempt to prevent attackers from discovering the clear-text value if they happen to gain access to the server data. This encoding generally uses either a one-way algorithm or reversible encryption, and the output of that algorithm is very likely a sequence of bytes that don’t represent a string, so it’s very common for the encoding algorithm to base64-encode the result so that it is easier to represent if the encoded password needs to be displayed as text. However, if the server does automatically encode passwords when it’s storing them, you still need to provide the password in the clear-text, unencoded form when binding. The server will take the appropriate steps to determine whether that clear-text password can be used to generate the encoded form that it stores. - Even if the directory server actually does store the password in the clear without any encoding, if you retrieve the entry in LDIF form (for example, using a tool like ldapsearch), then you might see it represented in base64. That’s because LDIF itself has rules that may require values with special characters to be represented in base64-encoded form. If that’s the case, then you’ll see two colons between the attribute name and value rather than just one. Note, however, that while LDIF is a text-based representation of LDAP data, LDAP doesn’t actually use LDIF when transferring requests and responses between the client and the server. So just because you see a base64-encoded value when you’re looking at the LDIF representation of an entry, that doesn’t mean that you need to use the base64-encoded representation of that value when including it in an LDAP request. In the unlikely event that you do actually need to base64-encode the password before including it in the bind request (either because the server you’re using uses a nonstandard behavior, or perhaps more likely because the password was inadvertently base64-encoded before it was originally written to the server), then you can do that using the com.unboundid.util.Base64 class. The Base64.encode method will allow you to base64-encode the contents of a string or a byte array, and then you can try providing that resulting string as the password for the bind request. On Fri, Aug 28, 2020 at 8:58 AM John Dev <jo...@gm...> wrote: > Hey, > > we are facing the issue that we have all kinds of special characters in > passwords and the need to encode those in base64. > Any idea how we can use the UnboundID LDAP SDK with base64 encoded > passwords? > The LDAPConnection.bind class doesn’t support it. > > Thanks, > John > > _______________________________________________ > ldap-sdk-discuss mailing list > lda...@li... > https://lists.sourceforge.net/lists/listinfo/ldap-sdk-discuss > -- _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._ |
