With computers, the answer is always yes, but you might not always like the bill at the end.
The Single Sign On
51–60 of 73 posts
Re: The Single Sign On
#52This 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…
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
#53OK, 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…
Unless the hospital provides wifi for guests and visitors.
Re: The Single Sign On
#54Hilarious, 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…
Re: The Single Sign On
#55(assumes over https, which for HIPAA stuff should be a given)
Re: The Single Sign On
#56Oddly 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, 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
#57Earlier 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.
“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
#58Re: The Single Sign On
#59Earlier 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!”
Re: The Single Sign On
#60Earlier 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?
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.