To save you the trip, the story is about a security manager’s challenge of ensuring that when an employee leaves the company his/her access is disabled at any point that might cause a security breach.

Here’s the best quote: “Unfortunately, we have neither the budgetary nor the human resources to” ensure an employees access gets disabled properly.

My sense is that people look at this as not so big a deal and those preaching the values of security within an organization are easily identified as this guy:

It’s only when something like this happens that we wish we wouldn’t have compromised security to gain speed to market or shave a few seconds off our call average.

Here are three things to think about if you are about to start building a secure application:

1. Follow the standard practices — Leverage existing standards like OASIS or Project Liberty if you’re thinking about muckin around with your customer’s identity.

2. Do your research — Just because all the cool kids are using OpenID doesn’t mean you should. Think about how easy your solution can be phished and what it means if some savage miscreant gets a hold of that username/password.

3. Think about End-to-End — It’s not just about getting users logged in, its about ensuring those who deserve access are provided access. And keeping those who no longer have the privilege, out. If you can figure a way to get them into your database, think of the process you will need to take to get them out.

The most embarassing thing that can happen to your company is when your customers’ identity/privacy is compromised. Much like any important relationship with someone you care about, once you lose their trust, the road to recovery is a long one.