The Single Sign On

Oddly enough, I've actually DONE this with off the shelf products, and didn't really consider it that big a deal at all. The only thing that needed modification was the app I was writing that needed federated access to.

If the company is using a recent Active Directory, it's a snap to set up OpenSSO within their environment to consume Kerberos tokens to authenticate the user (in a browser) via passwordless login.

From there, you can configure OpenSSO to federate authentication by providing your site a SAML token, which, when consumed for authentication, means that the only thing you really have to worry about is authorization -- e.g., what a given user can do from within your application.

One of my best friends is a developer who often cries 'impossible', only to brilliantly solve whatever problem a week later, usually with some fairly creative thinking, but I've always considered that his one biggest downfall -- crying wolf.

That said, I certainly get that if you're an app developer for a given product, the work that was sold was well out of scope.

Hilarious, and yet, sadly, this must be true. I've been asked countless times by end users why they must login to applications. I think the general population of business (read: average) computer users honestly thinks that passwords should not be required for accessing any information. These are the same type of users that have post-it notes with passwords attached to their monitors and probably write their ATM PIN# on the back of their debit cards.

This is a perfect example of why it's important to understand not just what your client is asking for, but why they think they need it.

The same lesson goes at least as much, imho, for negotiation - I used to see this all the time at my last job. We'd be negotiating a deal with some counterparty, and they would ask for something completely unnecessary and completely unpleasant (for our side). Sometimes it was just a negotiating ploy so they would have an ask to drop in exchange for something they wanted more, but often as not they just hadn't thought about whether or not they really needed Onerous Provision X. And if instead of fighting over Onerous Provision X you tried to figure out why the other side thought they needed it, and then tried to address that need in some other way, the whole thing went a lot more smoothly, you usually didn't need to give them Onerous Provision X, and everybody walked away feeling like they got what they wanted.

The point of which rambling story, I guess, is that in spite of the linked piece being presented as Idiot Client Asking for Dumb Things, the real lesson is that half the time a ridiculous request is actually just an opportunity to meet the underlying need in a better way.

actually, it is a pretty standard solution to these types of problems - it's called Federated Identity Management.

There are a number of standards in place all supported by a number of different vendors that provides this type of functionality. SAML and WS-Security are two that come to mind.

But I'm in perfect agreement on the punchline, that was awesome.

Great article, and I'm also not surprised, I had to work with a doctor once and basically took care of all her IT tasks because she was COMPLETELY technology averse and also forgot her logins all the time. I wasn't sure if this was normal of medical professionals, but this article just further reinforced that image.