Security & Single Sign-on – You Can Have Both!

Security is one of those critical functions that as developers and programmers, we just hope will seamlessly work in the background. Unfortunately, this isn’t always the case. I was talking to an architect the other day who had an application server up and running and wanted to connect to a SQL Server database configured for Kerberos using Active Directory as the KDC. He wanted to "delegate" his active directory credentials from the browser through his application, to the driver – enabling true single sign-on for all users of the system. The application had successfully retrieved the credentials from the browser, but he couldn’t pass the credentials through to the SQL Server driver he was using because it didn’t accept delegated credentials.

To get around this problem, the architect had to open up the Kerberos credentials, exposing the username and password, and rewrite a new, insecure ID and password to pass to the driver – defeating the purpose of the security architecture altogether. This is essentially the same faux pas as handing Chris Berman press credentials to the Super Bowl and subsequently having to reevaluate his credentials before he gets to access the locker room and again before doing a sideline interview!

Rather than blocking your access at every checkpoint, using a driver should to make your life easier – the security vulnerability this architect faced doesn’t have to happen to everyone. Rather than kludging together an insecure workaround, you can use JDBC drivers like DataDirect’s to support delegated credentials within an app server.  Kerberos credentials can pass through the driver and behave like they’re intended to – a Super Bowl press pass without the hassle at every check point!