qazmlp writes: > The following is my understanding: > - LDAP server encodes the response always in the ASN.1 format > - LDAP client program (E.g. openLDAP client that is released by the SUN) > decodes the ASN.1 encoded response data > - LDAP client program, returns the response in the format as it is > entered in the LDAP entries
I think, by "client" above you mean "LDAP library" (for LDAP client program). > (String, number, true/false etc.) to our client program(Program-1). ..and that is the LDAP client. > Is that correct? Yes. > We have a requirement in our client program(Program-1) to read the > LDAP response and encode it in the ASN.1 format and send to an other > process(Program-2) via the IPC messaging. (...) > Q1. > I would like to know whether we can avoid the 'LDAP client' > implementation to skip the decoding part, so that I can reuse the > already encoded response while sending the IPC messaging. First, a question: Are you doing this optimization, or to keep things simple? If optimization, do you really need it (is this really a bottleneck in the program)? Maybe it's simpler - and thus less error-prone and more maintainable - to use existing code and keep the extra decode-encode steps. Anyway, for your questions: You could skip the LDAP library in Program-1 and just write it as an IPC program which forwards ASN.1 messages between the server and Program-2. If Program-1 in addition needs to know a bit about what is being sent, hopefully your LDAP library has some routines to decode ASN.1 messages which you have received. Maybe it also has separate routines to receive and send single ASN.1 messages, otherwise you'll need to find or write an ASN.1 IPC library. (It's fairly simple if you just want to find how long an ASN.1 message is.) However, there are times when an LDAP connection switches from the LDAP protocol to another protocol: After exchanging a StartTLS request and a success response, the connection switches to the TLS protocol. Further LDAP messages are sent "inside" that protocol, until the connection is closed or just the TLS session is ended and the connection reverts to unencrypted LDAP. The same can happen after a SASL Bind, if the Bind method establishes encryption on the connection. The simplest fix would be to not support SASL and TLS, but just recognize such requests (which means you must parse LDAP requests from Program-2) and send back an unwillingToPerform message or whatever. As a replacement for TLS, you could instead listen to for the 'ldaps' protocol (LDAP inside SSL alias TLS) on a separate port, normally 636. Hopefully you don't need SASL methods that establish encryption. > I could see an API 'ldap_enable_translation()' in the Solaris man > pages. Is this meant for that purpose? No, that is just for translation of the character set/encoding of textual values such as attribute values and error messages. LDAPv3 mostly uses the character encoding UTF-8. The ldap_enable_translation manpages I found on the net referred to the character encoding T.61. That was used in LDAPv2, which has been outdated for 9 years now. > Q2. > The complete LDAP response is sent as an IPC, in the ASN.1 encoded format. > Is there a better alternative to this? If you mean getting LDAP to send text messages - well, not in the LDAP protocol. I remember seeing some work on transmitting LDAP data in XML, but I don't know what came of that. -- Regards, Hallvard --- You are currently subscribed to [email protected] as: [EMAIL PROTECTED] To unsubscribe send email to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the SUBJECT of the message.
