
The Single Sign On - billpg
http://thedailywtf.com/Articles/The-Single-Sign-On.aspx
======
patio11
This situation is virtually made for client-side certificates:

1) You won't need passwords beyond whatever it takes to log in locally.

2) You can assume the hospital computers are physically secured. (Well, I
wouldn't, but apparently they do.)

3) The hospital changes machines very infrequently and probably _wants_ a
human in the loop every time a machine changes.

4) You can have certificate generation and registration get handled by the on-
site IT staff. It is once in a blue moon, and makes them feel like they're not
getting paid 6 figures to clear paper jams and reboot Windows.

5) You can mumble any sort of cryptographic magic to scare away people who
know just enough about security to be dangerous.

~~~
blantonl
There is one problem with this - now that you've deployed client side certs
you now have to implement a software distribution product just to deploy certs
to the 100's of computer that require them... or, in this article case, the
_single_ computer) :)

Systems Management vendors love to sell software distribution products to help
reduce the distribution requirements for client side certs, but in the end
most folks will balk at the price and end up resorting to the sneaker-net
approach.

~~~
easyfrag
Wouldn't you be able to do this via Active Directory group policy?

~~~
dschobel
That's the route I would have gone, just write some tiny local web app which
authenticates against AD and then redirects to the external service.

I don't know why they wanted to go ip-based or even bother with cookies since
AD queries are practically free.

In ASP.net with all the builtin integrations for AD that's a one day project.

------
jaredhansen
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.

------
orangecat
_“But we don’t need to change it for everyone,” Craig jumped in, “just one
client. Surely, you can do that!”_

That's probably the most frustrating thing I hear from non-technical people,
because they really think they're making it easier. Sadly Kolmogorov
complexity is not yet a required course in schools.

~~~
nopassrecover
Can you elaborate on Kolmogorov complexity and its relevance to someone who
has not encountered the term before? (I have wikied it:
<http://en.wikipedia.org/wiki/Kolmogorov_complexity> but sleep deprivation may
be hindering my ability to spot the link)

~~~
gjm11
To someone who doesn't understand what's going on, it may seem simpler to make
something work for one person than to make it work for lots of people; but in
fact the version that works for lots of people may be no less simple. (It may
even be simpler, if it's necessary to put in special-case testing to make sure
that only one person can use it.)

From an implementer's perspective, the right measure of the complexity of a
system is "how much code does it take to implement?" (which is more or less
Kolmogorov complexity) rather than "how many things can it do?" or "how wide
is its range of possible behaviours?".

A few other remarks on Kolmogorov complexity:

1\. "Random" is often best understood as "of high Kolmogorov complexity": a
sequence of numbers is random if there's no way to generate it that really
saves anything over listing all the numbers; no pattern that makes it
predictable. (In practice, what you usually care about is that certain
restricted kinds of pattern don't occur, which is kinda like a version of
Kolmogorov complexity where you're limited to using programs in a language
that isn't Turing-complete.)

2\. If you apply Ockham's razor in the form "prefer hypotheses with lower
Kolmogorov complexity" together with Bayes' theorem, you get something that in
a certain (rather artificial) sense is as effective a problem solver as
anything mechanized can be. Unfortunately it's unimplementable in practice,
because ...

3\. It's more or less always impossible to determine for sure what the
Kolmogorov complexity of anything is. (Because to be able to do that you'd
need to be able to answer the question "do these two programs do the same
thing or not?", and that's equivalent to the halting problem.)

4\. (This is controversial, but it's my opinion and that of at least some
other contributors here.) When assessing (e.g.) scientific hypotheses for
"simplicity" or "parsimony", something like Kolmogorov complexity is the Right
Way to understand (un)simplicity; failure to appreciate this is, e.g., what
makes some people dislike the "many worlds" interpretation of quantum
mechanics on the grounds of extravagance, or think that "God did it" is a
useful explanation for otherwise-surprising features of the universe.

~~~
nostrademons
3\. It's quite possible to determine what the Kolmogorov complexity of
_something_ is, it's only impossible to determine what the Kolmogorov
complexity of _everything_ is. The halting problem only states that it's
impossible to prove whether an _arbitrary_ Turing machine halts. There're many
Turing machines that can be proved to halt, some quite easily. For example,

    
    
      int main(int argc, char** argv) {
        return 1;
      }
    

can be proved to halt pretty easily, just looking at the CFG for the program.

~~~
gjm11
I think that even in practice being able to determine the Kolmogorov
complexity exactly is very decidedly not the usual case; you need to know that
_every_ program shorter than your candidate fails to do the right thing.

Your general point is very much correct, though. A clearer-cut application: In
general, one cannot prove that a program does what it's supposed to; but if
doing that is important, "all" you have to do is _write_ it in a way that
makes a correctness proof possible.

------
GavinB
Is it just me, or did was the annoying sales guy completely right about the
technology being possible, able to satisfy the client, and successful in
closing a profitable deal for the company?

What weird dailywtf parallel universe is this?

~~~
wheaties
The WTF is the fact that a single employee would cost a company several tens
of thousands of dollars plus several weeks of development time all because
that employee didn't want to remember a password.

~~~
run4yourlives
Actually, the WTF is that nobody bothered to mention (or ask) that only a
single employee used the system.

~~~
gridspy
The salesperson did say that there was only a single client...

“But we don’t need to change it for everyone,” Craig jumped in, “just one
client. Surely, you can do that!”

~~~
kgermino
He would have meant one client as in one company, not one user.

~~~
chops
Perhaps the salesperson meant "one client machine" and the programmer assumed
that, given the context, meant "one client company." Client can be a rather
ambiguous term.

~~~
sjs
You're giving the sales guy far too much credit.

------
kemiller
That was actually a pretty clever solution he came up with. I didn't see the
punchline coming.

~~~
frankus
I only caught the double-entendre in the title after reading the article.

~~~
imp
I only caught the double-entendre after reading your comment.

------
fnid2
I don't think it's funny and I don't think either the hospital or the
consultants/contractors/employees who built this system are worth their weight
in salt.

It was a horribly expensive move and had very little benefit to the system or
the patients or the hospital. It was a huge waste of money and it is decisions
like this that are sending health care costs through the roof.

How incompetent must you be to go through all that and find out after months
of work and thousands, perhaps tens of thousands, of dollars spent that what
you were doing benefited only _one_ person for less than 1 minute a day?

It's a really sad state of affairs that this scenario exists. Pathetic really.
If I was the hospital, I'd fire the contractors and the stupid person running
the system who can't remember a password. These kinds of people end up costing
you more and more and more in the long run.

~~~
isleyaardvark
It's unfair to blame the consultants when it was entirely the client's project
manager's fault. It's the PM's responsibility to figure out how many of her
company's employees will use it and whether or not it's worth the cost.
There's not a whole lot the consultants could have done, even if they had had
the foresight to ask "By the way, is this only going to be for one user?" or
"Are you really sure you want to do this?"

------
illumin8
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.

~~~
imgabe
I think people get the need for a password, it's just that for the average
office job, you have something like at least half a dozen different passwords,
with different complexity requirements and different reset schedules. At work
I have different passwords for:

Windows login

Expense report system

Timesheet system

Employee information system (where I can view my pay stub, w2, etc)

401(k) provider

Insurance provider

Various ftp or other file sharing services for shuttling data back and forth
with clients.

And that's in addition to the all the normal passwords I have for personal
stuff. What's worse is most of that is used infrequently so the login process
never has a chance to sink into muscle memory. The login process is pretty
much forgot/reset password every time I use it.

~~~
ghfdrvtsyup
If you have that many passwords, why not make some sort of base password and
then riff off of the base password for everything that needs access (and have
a mental sequence for when an item needs a reset)? If your base password is at
the highest complexity requirement, the only thing you need to remember is the
individual sequences.

I do this for my passwords and it's been working for me for years ...

~~~
imgabe
That's more or less what I do. Not everyone cottons on to this scheme though.
With the logins I might use once every 6 months or so, it can still be hard to
remember which variation I'm on, especially if it's a "three tries then you're
locked out" system.

------
bmelton
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.

~~~
pyre
_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._

You're forgetting that the client's IT people thought that VPN was 'inherently
insecure.' What makes you think that they would install this when they would
not install a VPN?

~~~
bmelton
Honestly, it sounds like the software they custom-developed to act in that
role was a knockoff of the basic functionality. The flip side is that OpenSSO
uses in-built Kerberos encryption, and generates token-based session headers
that contain zero sensitive information.

Honestly, you may well have a point, in that the customer may well have only
been receptive to the chosen solution because it was custom-developed, but I
was mostly balking at the developer's initial reaction of 'impossible'. Not
only is it not impossible, it isn't hard to do, and certainly didn't require
reinventing the wheel when a perfectly adequate solution exists that would not
only have worked well, but worked for de-passwordifying OTHER web services as
well (potentially).

------
ShabbyDoo
"And not just followed, but followed, tested, certified, re-certified, and
double-tested."

HIPAA doesn't prescribe specific technological mechanisms or official
certifications. IIRC, a username and password assigned to an individual user
is sufficient. I believe there are some audit-ability (who saw/wrote what)
requirements as well, but it's been a few years since I dealt with HIPAA.

As a user of a system for which inappropriate data access can get you fired,
you should be concerned if it does not have strict authentication mechanisms.
Sally can blame Bill for having looked at some famous person's medical record.

Such snooping is actually is a recurring real problem at major hospitals which
treat famous people. The Cleveland Clinic sort of solved it by assigning
people like Drew Carey (widely known to be a Clinic patient) a pseudonym. All
electronic records are under that name, so most people looking wouldn't
realize who the patient was. A VIP office handled billing reconciliation. It's
a cute security through obscurity mechanism although it's probably well known
on which dates Drew visited the Clinc and which physicians likely saw him.

------
polymath21
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.

------
HeyLaughingBoy
OK, I'm not a web developer: I do embedded systems and hardware interfacing,
so go easy on me :-)

Assuming that the hospital network was secure, then why couldn't the system,
when receiving a request from that single IP, request a cookie? If the cookie
doesn't exist, then that user has never logged in and is then given an
identifying, non expiring cookie and from then on is allowed access and is
identified? Knowing the hospital's external IP would serve as authentication.

I know just enough about web apps to be dangerous, so someone please tell me
what's wrong with this idea?

~~~
cookiecaper
That's not a problem if you know the end game, which is that only one person
in the hospital will ever know about it, but if you assume more than one
person in the hospital will need access, you need to provide user-level
permissions to prevent patient records from falling into the wrong hands; if
you just give everyone in the hospital the exact same level of access, you're
exposing a lot of things to a lot of people that shouldn't know about them.

------
nathanh
Those of you with sales teams, what guidance do you have about sales people
promising features that don't exist without getting input from the rest of
your team?

~~~
jonknee
Fine as long as it's for a lot of cash. If the customer is willing to pay for
it, I'm happy to jump through crazy hoops.

~~~
cookiecaper
Really? What if the client demands that your application is in "3D holograph"
and won't accept anything that doesn't pop out of the monitor without any
special assistance from the user? You're OK with selling that even though, no
matter how much money they produce, it would take years and years of
development, and may not even be possible until some other foundational
technical breakthroughs occur?

Please don't take this too literally and tell me all the reasons why 3D
holograph is feasible, you get the point.

~~~
ryanelkins
For enough money upfront I'll get started today. For something really out of
the norm a good salesperson should have gotten the customer to agree to an
amount of money that would make it well worth it, whatever the task may be. I
think for any outrageous example you come up with the cost will bring the
customer back to reality.

~~~
cookiecaper
It's dishonest to pitch it as a product you're selling when the technology to
build it doesn't even exist yet. You can't say "Sure, we can do that for xxx
million dollars and ten years", because you don't know if you'll have it all
figured out even after xxx million and ten years, because nobody knows what
would actually be required to produce that product. There may be some theory,
but if that theory is erroneous for your application and you placed bets on
it, you're screwed.

You have to pitch as a research investment. If a company wants to give you
money for that kind of research, that's great, but you really need to make
clear that it's not something you can just go and implement even if you have
an infinite supply of money.

------
noonespecial
One lesson (relearned) is to never say anything is impossible to do with a
general purpose computer unless it actually violates a law of physics. (Even
then, have a think about if you can achieve the same goal without said
violation)

With computers, the answer is always yes, but you might not always like the
bill at the end.

------
bricestacey
"After going back to the drawing board, Gerald came up with another idea:
configure the firewall proxy server on the client’s side to add a custom HTTP
header (X-Forwarded-For) that included the original IP address. That idea went
over just about as well: HTTP headers could be forged, and a malicious
employee inside of the company could hack in too easily."

I believe this is a perfectly acceptable solution, except they should strip
any existing X-Forwarded-For headers sent by a client and only auto-login
users originating from the NAT.

Problem solved... I think?

------
cliveholloway
1) add a cert signing server that you control to the client's browser, 2)
install a self signed SSL cert in the client's browser, 3) done.

(assumes over https, which for HIPAA stuff should be a given)

------
Jim72
One for all and all for one!

I don't know, maybe I would have opted for a enterprise level account with
Roboform?

------
olegk
Couldn't they just let the browser remember the password?

~~~
pavel_lishin
Yeah, but then the user would have to type the password in once. Apparently,
even this was too much.

