Live data from Hacker News

The Single Sign On

thedailywtf.com

51–60 of 73 posts

Re: The Single Sign On

#51
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.

Re: The Single Sign On

#52
post #7

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…

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…

Ahh yes, the expensive deployment options. Too true. You can use Admin Arsenal. (www.AdminArsenal.com). It has a 30-day fully functional trial so as a one-time option you can do the cert deployment at no cost. Plus, Admin Arsenal doesn't use agents and is installed on your workstation, so it doesn't require its own server.

If you want to keep it the licensing is simple - per administrator, regardless of the number of systems that you manage.

Check it out.

Re: The Single Sign On

#53

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 t…

Knowing the hospital's external IP would serve as authentication.

Unless the hospital provides wifi for guests and visitors.

Re: The Single Sign On

#54
post #19
post #4

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#…

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…

I run into this a lot and it's quite frustrating, so I just gave up and started keeping everything in a Keepass database. Works well enough.

Re: The Single Sign On

#55
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)

Re: The Single Sign On

#56
post #9
post #2

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. Fro…

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…

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

Re: The Single Sign On

#57

Earlier quoted context omitted.

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.

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

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!”

Re: The Single Sign On

#58
post #38
post #5

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

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

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

Re: The Single Sign On

#59
post #57

Earlier quoted context omitted.

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

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!”

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

Re: The Single Sign On

#60

Earlier quoted context omitted.

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…

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

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.

Post reply on HN