UnboundId LDAP SDK and Connectionpools

The probably best LDAP Client SDK currently available is the UnboundId LDAP SDK

It has a nice API, good documentation, implements all controls and is still actively maintained and improved.

While using it I had a question regarding the usage of connection pools with different identities. I was a bit confused by the API documentation and posted a question to the old forum, which is apparently going to be switched off in the future. As I found the answers of Neil quite helpful I repost the thread here to capture the wisdom:

My initial post:

I have a quick question whether I should use connection pools or better stick to creating connections on the fly. I have a web application that is accessing an LDAP server. As every user of that application has different rights within LDAP, I need to make sure that the LDAP knows about the user. So far I see these three approaches: 1) Create a connection per LDAP request and bind it with the user credentials. As creating connections is supposed to be expensive, that doesn't seem to be the best approach. 2) Maintain a pool of ldap connections, get a connection from the pool and bind it for every request. However the API states: "Connection pools should generally not be used when performing operations that may change the state of the underlying connections. This is particularly true for bind operations and the StartTLS extended operation, but it may apply to other types of operations as well." If I get that correct using a connection pool is also no option as I need to bind the connections every time. 3) Use a connection pool that binds to an artificial "web user" that has proxy rights for the directory. What I don't like about that approach is that in theory an attacker can easily access all LDAP data once he has hacked the web application and get hold of the web user credentials. What do you think? Are the assumptions above correct? Or is it possible to somehow use approach 2) which would be best of both worlds? And Neils response: If I understand your question correctly, you have an application for which you want to use an LDAP server to verify the identity of a user, and then possibly to perform other operations as that user in the directory. In this case, I would definitely recommend the use of connection pools rather than creating separate connections for each user. If the only thing that your application needs to do in the directory is process binds to verify credentials, then there should be no concern at all about using a connection pool, and you don't need to do anything special. Since all you are going to do is perform binds, then you don't need to worry about changing the identity of those connections. On the other hand, if you are going to bind and then perform other operations as that user, then there are a few approaches that you can take: 1. Use two separate connection pools. One for processing binds and another for all other operations. For the non-bind pool, you would probably use something like the proxied authorization control to indicate that the request is on behalf of the requested user. However, since you indicated that you have security concerns about that, then you may not want to do that if you don't feel that you can appropriately secure your application and the use of that account in the directory. 2. Store the user's credentials in the application session and re-bind as that user before each operation in the directory. That is, when you need to perform an operation in the directory as a given user, then you would do the following: a. Check out a connection from the pool b. Bind using credentials stored in the user's session c. Perform the desired operation d. Release the connection back to the pool This will incur a slight performance hit for each bind, but you may find it to be an acceptable trade-off. 3. Use a separate connection for each user, but have that connection be associated with a connection pool so that you it can be re-used for other users later after the current user no longer needs it. This allows you to avoid the cost of creating a new connection for each user but still have dedicated connections for each user. In this case, when a new user arrives, then you would check out a connection from the pool and associate that connection with the user's session and use it for all operations performed by that user. When the user logs out or the session expires, then return the connection back to the pool so that it can be re-used by another user. The best approach really depends on a number of factors, and there may be other alternatives that I haven't discussed here, but hopefully it's enough to get you started. If you have any additional questions, then post them here and I'll do my best to answer them. My response: The application is doing quite a lot of LDAP queries. It authenticates the users and is often asking for user attributes profiles and group memberships. Solution 2) sounds good. I obviously misunderstood the passage from the API: "Connection pools should generally not be used when performing operations that may change the state of the underlying connections. This is particularly true for bind operations and the StartTLS extended operation, but it may apply to other types of operations as well." Just out of curiosity: What is an example for an operation that shouldn't be done when using a connection pool? Regarding solution 1). Yes, if the additional bind request in solution 2) is not increasing the load too much I would prefer the extra layer of security. And Neils final answer:

Most directory-enabled applications that use connection pooling keep the connections authenticated as the same user the whole time, either through the use of something like the proxied authorization control (which is good for fine-grained auditing and access control) or through the use of some generic account (which may be a little easier in some cases, and can give you the flexibility to do access control in your application rather than the directory server). The warnings are primarily intended to make it clear that performing a bind operation will change the identity of the associated connection, so if you later attempt to re-use a connection then you may not know what identity is associated with it and what capabilities that identity might have. About the only thing that you absolutely shouldn't do when using a pooled connection is something that isn't repeatable (i.e., you can't do more than once on the same connection) or something that isn't reversible (i.e., it could change the state of a connection in a manner that may make it unsuitable for continued use). The StartTLS extended operation is a good example of this because you can only do it once on a given connection and once you have established a secure channel you can't go back to insecure communication. If you want to secure pooled connections using StartTLS, then you'll need to do that with a post-connect processor so that the work is done at the time the connection is created. If you do anything else with pooled connections that could change the state of those connections, then you need to be aware of that and make sure that you put them in a known state either immediately after checking them out of the pool or immediately before releasing them back. If only a small set of operations may place them in an unknown state, then it's probably better to revert that state before releasing them back to the pool since you only need to do that a subset of the time. However, in your case it sounds like just after checking them out is a better time since the "known state" may vary based on who is accessing the operation. The other important thing to keep in mind is that if you are going to perform operations using a connection pool that may alter the state of those connections, then you should only interact with that connection pool by checking out and releasing connections. You shouldn't use the methods that are part of LDAPInterface on the pool itself because those methods internally check out a connection, perform the requested operation, and release that connection back to the pool. If connections can be in an unknown state, then the operations performed using them may not behave as expected.

Google Reader without offline support

I have read the announcement that google is removing the offline support from reader but somehow didn't take it seriously. However this morning the sync icon was removed and I had to face the fact, that google has killed offline support for reader within 2 weeks.

That was the MOST important feature for me in google reader. Where I travel to work the mobile coverage is not good enough to read the items online. So I am pretty annoyed about it. Especially for what I get in return: A better social experience.

Dear google, I don't care about social stuff in my reader. I don't want to have social elements in my reader. I want a product that does the one thing it was build for perfect: READING news feeds.

So what's the alternative? Don't know yet. I have to find a native linux client. I am sure I can find a decent reader but I just don't get it: Google is building Chrome OS where AFAIK everything should run in the browser (which also means that offline support for apps is a must) and now they axe the offline support of reader.

I guess I won't give Chrome OS a try. Switching the feedreader might not be such a huge step but reinstalling and moving to another OS in case google again decides to remove important features within a few weeks is nothing I want to do.

So stupid!

Banning a XP installation into Virtualbox

At work there is no way to avoid windows but I still prefer to do development in linux. So what I want is to convert my existing windows into a virtualbox environment.

So that is what I have done:

1) Use the free VMWare converter to make a logical vmware image of your windows partition. However the converter had some problems so I used the installed Acronis backup software to make a logical copy in a tib archive and used that as input for the converter.

2) The vmware image should start fine using virtualbox. But I still had serious problems with the performance. CPU went to 100% and the image wasn't usable at all. Gladly I stumbled across this site: http://blog.subaquatic.net/archives/virtualbox-p2v-success/

The solution is to choose a simple ACPI PC in the DeviceManager->Computer setting.

However I haven't switched of the IO/APIC setting again.

That solves the performance problem an I am a happy linux with windows in a box user again ;-)