Federated cloud identity and authentication is coming to OpenStack.
The OpenStack open source cloud platform started out with only two components: Nova Compute and Swift Storage. Nova originally came from NASA and Swift came from Rackspace.
Over the course of the last two years, OpenStack has expanded beyond NASA and Rackspace and has been embraced by many large tech vendors, including IBM, HP, Dell, AT&T, Cisco and Intel among others. As OpenStack participation has grown, new capabilities have been added, including most recently the Cinder block storage project and the Quantum networking project. Cinder and Quantum both debuted in the recent Folsom release.
For the next major release of OpenStack, codenamed Grizzly, Federated Authentication is likely to be the next key component that will come to the open source cloud platform.
“Everyone wants hybrid clouds,” Joshua McKenty, founder of Piston Cloud and OpenStack Board member told Datamation. “There are a couple of stumbling blocks on the road to hybrid clouds that OpenStack needs to address seriously, the biggest one being federated authentication.”
McKenty explained that for federated authentication, OpenStack will be taking the same approach to development as the project took for the Quantum networking component. For Quantum, networking and Software Defined Networking (SDN) vendors were assembled to figure out was needed and to actually develop the technology.
“I’m taking the same approach with authentication and identity now, rounding up the identity management vendors and getting them to chime in,” McKenty said.
Identity is not an entirely new capability for OpenStack. The Essex release that debuted in April of 2012 introduced the Keystone Identity Service. The idea behind Keystone is to provide authentication across all of the core OpenStack components.
“Keystone is really a middleware framework in the same way that OpenStack is middleware framework for building clouds,” McKenty explained. “Keystone is a middleware framework for connecting to authentication systems.”
According to McKenty the real challenge with Keystone is that the logic does not deal with federation very well. So, for example, an enterprise that has a private cloud that wants to burst workloads to a public cloud vendor would likely require a separate account for employees with the public vendor. That situation can create challenges for chargeback and usage metering, among other issues.
“What I really need is my internal authentication system bridged out to the public cloud and also connected internally to my private cloud environment,” McKenty said.
He added that there have been some pieces, including (Security Assertion Markup Language) support for Single SignOn, that have been built for Keystone, though he noted that it’s still immature. Work still needs to be done on ActiveDirectory integration as well as Kerboros oAuth and ACLs that span both public and private networks.
“There is a bunch of work that needs to be done, in the same way that Quantum was definitional as well as then aspirational,” McKenty said. “The strategy is to get the people that understand authentication involved and then work with them to define what the future of virtualized authentication looks like.”