It's Labor Day in the US, which means we're taking a break from the usual grind. Enjoy this classic story about the challenges of providing users with the authentication system they desire- one with no passwords or usernames. Original -- Remy

“It’s impossible,” Gerald said in a matter-of-fact tone, “simply impossible.”

“Now just so we’re clear,” Craig responded, “by ‘impossible’, you actually mean ‘a big pain in the ass’, but you’re a smart guy who can make it happen, right?” That drew a few chuckles from the handful of other coworkers who joined them in the conference room, but Gerald just sighed. “No, Craig, by impossible, I mean impossible. Not doable. Can’t be done. Im-poss-i-ble. Well I mean, unless you can somehow change the underlying structure of the way everyone communicates on the Internet.”

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

The situation at hand was not an uncommon one. Craig, one of the company’s top producing sales reps, had once again sold a client on a feature they did not have. He certainly didn’t lie about having the feature, but instead proposed an offer the client couldn’t refuse: if you buy it, we’ll build it.

Management, not being the type to turn down booked sales, couldn’t refuse the offer either. And thus, they sided with Craig on what ‘impossible’ actually meant. They also assigned Gerald and team to develop the much-needed feature: an IP-based authentication system that would allow users of their Software-as-a-Service product to access the system without ever needing to log in.

Gerald’s main objection with IP authentication was that the majority of users – and in fact, all of the users at the client site – were behind a router. Though they’d certainly each have an internal IP address assigned, they would all share the same public IP, making one computer indistinguishable from the next.

To make matters even more tricky, their application was used by hospitals to track certain kinds of patient data, which meant that HIPAA – the regulatory framework that defines how patient data must be stored and accessed – needed to be followed. And not just followed, but followed, tested, certified, re-certified, and double-tested. Any change to the HIPAA-related functions – authorization included – would need to go through a painful internal and external QA process.

Given the impossibility of getting the end-users internal IP address from the outside, Gerald figured that using cookies would be the next best thing. Have the user log-in once, and then store an authentication cookie on the computer for as long as possible. Sure, that meant clearing cookies would trigger a new login, but it seemed to be a fair and easy work-around. Well, not so much: the client vehemently rejected the idea, saying that their employees couldn’t be bothered with having to remember yet another login, even if only temporarily.

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.

Gerald’s third proposal to the client involved a site-to-site VPN connection. The application server would be exposed access via the client’s internal network, which would not only allow them to use IP authentication, but Windows-integrated authentication as well. It was his best idea yet, and made things that much easier, as the client would be able to configure which username has access instead of which IP address. Unfortunately, the IT folks at the client weren’t a big fan of the approach, as “a VPN connection is inherently insecure.”

At wits end, Gerald came up with yet another idea: a “Single Sign On” approach of sorts. When the end-user would access their application, the system would look for an “authentication ticket” cookie. When not present, the user would be redirected to another server – which lived inside the network – whose sole purpose was to generate a secure authentication ticket that included the private IP address. The ticketing server would then redirect to hosted application, which would then verify the authenticity of the ticket and give the user access.

The client absolutely loved the idea. “This is exactly what we’re looking for,” the client’s project manager said, “no need to remember logins, plus solid security.” The sales contract was signed, and the project was officially a go.

And finally, three months later, the new feature was finished. It took three solid weeks of development time, two weeks of QA testing, several thousand dollars in new hardware, and tens of thousands of dollars for an external HIPAA assessment, but the sales rep and the client’s project manager said it’d be worth it: no more remembering logins. Now, all that was needed for implementation was a list of IP addresses that were allowed to use the computer.

“Hi Gerald,” the client’s project manager wrote in an email, “please provide the following IP with access to the system: 10.1.23.97.”

Gerald confirmed, and reconfirmed: only one user needed access to the system. And apparently, she really hated remembering logins.

[Advertisement] ProGet’s got you covered with security and access controls on your NuGet feeds. Learn more.