Rackspace customers use several different control panels to manage their content. Often, customers use more than one control panel on a regular basis. One of the most common use cases is a customer using both the MyRackspace (MyRack) control panel for managing their dedicated infrastructure, and the MyCloud control panel for managing their cloud infrastructure. This means that customers need to log into two separate control panels with unique sets of credentials to manage all of their infrastructure.
With the intent of one day having a single Rackspace login across all of our properties, we set out to implement single sign-on between MyRack and MyCloud. Single sign-on enables customers to securely and seamlessly navigate between the two control panels, using one set of credentials. This was seen as the highest customer impacting place to start consolidating log-ins. To accomplish this, the teams decided on using SAML.
Security Assertion Markup Language
At its core, SAML is a standardized way to exchange information through XML. The standardization is important because it enables teams to individually implement solutions that work well together. This was especially helpful for us at Rackspace because the two control panels operate out of different offices, in different time zones.
The first step in implementing SAML was to decide on which roles the properties would play. Each property in the SAML specification acts as either an Identity Provider (IdP) or a Service Provider (SP). Because there is only one log-in page, only one of the properties needs to act as the IdP, while the rest act as SP’s. The IdP is responsible for logging the user in, maintaining their session, and informing all SP’s about changes in the user’s state. Because customers who use both contol panels use MyRack more often, it was selected as the IdP.
SAML works by exchanging signed XML documents between the providers. Customers log in once, maintain a shared session, and can log out from either location.
Navigating Between Providers
Rackspace customers can link their cloud accounts (from MyCloud) to their dedicated accounts (in MyRack). MyRack users are given the option to enter MyCloud as any one of these cloud accounts. The SAML flow might look something like this:
While the flow contains several steps, the user experience is extremely simple. As far as the user is concerned, they’ve logged into one control panel, and clicked on a link to another. There was no need to log-in to the second control panel or take any additional actions. The redirects are automatic, seamless, and fast.
Deep Linking
Another common use case for control panel users is to share links to cloud or dedicated infrastructure management pages. One customer can send another a link to a cloud server, after having logged into MyCloud through MyRack. This link will contain enough information for MyCloud to determine that this customer came from MyRack. This deep linking allows users to share links and bookmark pages, all while using a single log-in. The SAML flow in this case would like something like this:
Again, this seems like a long process, but from the user’s perspective, its fairly seamless. The user has clicked on a link from a colleague, logged into the control panel they are familiar with, and then been taken to the page they expected. And, had the user already been authenticated with MyRack before clicking the MyCloud link, they would have been taken through the flow and ended up directly on the expected page, without seeing any log-in pages.
Logouts
The SAML specification details log-outs in a similar fashion to log-ins. Browser redirects are used to send signed XML documents between the providers. This allows users to log out from any provider, and have their sessions terminated across all the others. If, for example, the user has already gone through the SSO process to MyCloud, and was ready to logout, the flow would look something like this:
Sessions
Session handling is not technically a part of the SAML specification, but is fairly straight-forward to orchestrate. It is generally the SP’s responsibility to inform the IdP that the session should be kept alive. Similarly, the SP is responsible for checking with the IdP on a regular basis to verify that the session is still active.
Conclusion
We are always looking for ways to better the user experience within our control panels. Implementing SSO gives our customers a more streamlined workflow, especially when combined with our role-based access control. Its a long road to consolidating the various control panels and services within Rackspace, but its our hope that the practices and patterns set here will pave the way.
