Customer story – Helping customers that may be overthinking a simple problem

Last week I told you about our unique brand of water cooler chatter here at Progress Software – the innovation of our customer. That’s one of the cool things about working for a software company that enables businesses to do their jobs better – your solutions are limited only by the ingenuity of your customers. In other words, the sky is truly the limit. On the other end of the spectrum, it can be just as satisfying when we find a solution for a business problem that is keeping our customers awake at night when their ingenuity by itself is simply not enough.

So in addition to last week’s example of “failover guy,” let me introduce you to another customer. We were talking recently with a large government agency, and they were having difficulty getting pure single sign-on working in their environment with the current set of JDBC drivers they had. Although the driver supported advanced security, it simply didn’t support delegation of credentials – an essential piece of the security puzzle.

As you know, any time you enter your user name and password in a browser, you create a unique, encrypted credential that remembers this identifying information for future visits. This is a useful function that saves time and increases convenience, but if the database driver you’re using can’t simply take those credentials and pass them to the database then you get into trouble. To be useful, single sign-on must be seamless from the end user to the database, but when the driver you’re using can’t take the credentials and pass them on you’re stuck trying to make all this work in a way that may be a bit kludgy….and that is just what this team did.

When this happens, you can really think your way into a mess. In this instance, after trying to make it work with a number of existing drivers, our customer actually built a whitelist in the application code that would enable any of the users on the list to get to the database. Then, he had to ask the browser for the credentials with the user name and password, and would check that against the whitelist to see if they had permission to log into the database. This involved actually unencrypting the credential for the user name and password, which as you might imagine, is frowned upon no matter what sector you work in.

Beyond the regulatory issues, this led to all sorts of problems maintaining the white list. If the list is tied to your application code, every personnel move means code modification – which is simply not feasible. Even if you make the list outside the code you don’t want it sitting around unencrypted, but then think what happens if some permissions for users in the database actually change. There are all sorts of holes and security attack risks here, and after a good talk with these guys over lunch, they were convinced that DataDirect Connect for JDBC was the best way to go – with support for delegation of credentials.

Was it as hard a problem to solve as the problems that “failover guy” was experiencing? No, but it certainly went a long way toward simplifying a process that a customer shouldn’t have had to worry about in the first place.