BACKGROUND IMAGE: iSTOCK/GETTY IMAGES
While working for two different companies, software engineers Alex Salazar and Les Hazlewood found themselves reinventing authentication and access controls for each application built. Seeing the shortage of reusable, flexible enterprise and cloud application development tools for security spurred them to quit their jobs and build reusable, open source and commercial security tools for developers and architects.
The security issues enterprise and cloud app developers face, ways to handle them and avoiding common mistakes are all revealed in Salazar and Hazlewood's road to building Apache Shiro. The duo created Stormpath application program interface (API) for enterprise and cloud application authentication, password storage, user management, access control and common security workflows.
During their college years at Georgia Tech, Salazar and Hazlewood worked as the founding engineering team for a Software as a Service (SaaS) startup back in 1999. "But it was called an 'application service provider' back then," Salazar said. "We built a multi-tenant system … before Marc Benioff had made it the standard, because we didn't know any better. It worked well and we fell in love with the SaaS model."
The cloud is becoming an increasingly hostile place to have an application.
Alex Salazar, Stormpath
Throughout their careers, both constantly dealt with inadequate security tools and the need to DIY security in every project. Developers typically had to write user management code from scratch.
"All of this work was done as a security necessity, but it wasn't core to the application's functionality," Hazlewood said. "Also, because this custom code was never designed to be robust and work for multiple applications, developers usually rewrite this same code for every application they build, exacerbating development costs further." Once implemented, this written-from-scratch code is often ignored and rarely updated, potentially exposing security vulnerabilities over time.
"Shiro took off," Salazar said. Even so, Hazlewood still saw a problem: Security frameworks only solved part of the authentication access control issue, because frameworks still had to talk to back-end systems, such as Active Directory or LDAP, in order to do their jobs. When building cloud-based applications, however, there is no Active Directory or LDAP, so he still had to reinvent that piece repeatedly.
In the public cloud, legacy network security policies do not apply, and any security holes can be quickly exploited, Hazlewood said. This flaw was made obvious by costly attacks against Sony PlayStation Network, LinkedIn, Last.FM, Yahoo and -- most recently -- Twitter.
"Most development teams don't have adequate security expertise on staff, so they are at much higher risk when deploying their application to the public cloud," Hazlewood said. Salazar agreed: "The cloud is becoming an increasingly hostile place to have an application."
Hazlewood didn't know that Salazar was grappling with the same issue in the area of cloud middleware, where existing tools had single sign-on features that weren't adequate for building new applications in the cloud. "Single sign-on is great when integrating Salesforce to something else, but not for your own custom apps," Salazar said. "I saw that the pain experienced by everyone building custom apps in the cloud and its very specific externally facing applications, mobile apps, customer apps, partner apps, etc."
Stumped, Salazar called Hazlewood to get his technical validation of the problem. "He started laughing, because he was working on the same thing," Salazar said. "I said, 'Great, let's talk some customers. Let's quit our jobs and start a company.'"
Being open source software proponents, the duo first planned to distribute their tool set as an open source product, using the typical open source business model. In exploratory research, they found that open source delivery worked well for very large companies with in-house security and development teams, and not so well with small and midsized businesses (SMBs) that didn't. The large companies had the pain and the ability to DIY if necessary, but they welcomed a reusable, in-house solution. Most SMBs didn't have security teams or in-house expertise to DIY. "Cloud delivery was the obvious SMB delivery route," said Salazar. "The midtier didn't want to do the security management, worrying about patching the database servers and running the latest copy. They just wanted an on-demand API."
For developers building new applications, Stormpath provides a service that automates security workflows, enabling authentication, access control and more, "so the developer can get back to writing code," Hazlewood said. Jobs such as authentication, password resets and email account verification each require a single REST call. "There's no data modeling, no code, no UIs, none of that," Salazar said. Language libraries relieve Java, PHP and Ruby developers from having to know REST and JSON.
"Nobody likes building security over and over again," Salazar said. "It's critical to the application, but it's not core; building up business logic is core."
Continuing their quest for reusable app security solutions, the next steps for Salazar and Hazlewood are building more Stormpath software developer kits and extending development language and platform support.