Login and authentication are fundamentally important aspects of any web service that you just can’t cut corners on, so when we set out to consolidate ObjectRocket logins last year, I knew we had a long path ahead of us. So long, in fact, that members of the development team here have likened it to the Neverending Story. I’m going to the Tolkien route and think about one login to rule them all. I know that metaphor doesn’t really end that well either, but I’ll forge ahead nonetheless.
In the Beginning, There was app.objectrocket.com
For quite a while the ObjectRocket service has hosted our User Interface (UI) on app.objectrocket.com. Our login system was pretty simple and mainly consisted of native users of our service directly logging in.
However, not long after ObjectRocket was acquired by Rackspace, we added the ability to log into our UI with Rackspace Cloud credentials. Given that our initial UI didn’t have Role-Based Access Control (RBAC), we limited the Rackspace logins to those with specific Rackspace permissions and called it a day.
It all looked something like this:
Then, last year, we had the rare opportunity to build a brand new platform that allowed us to expand our hosting footprint into AWS, GCP, and beyond. Rather than shoehorn all of the new capabilities we needed into the existing UI (and login system), we instead launched a new user interface and login system, with the long-term goal of getting everyone to the new platform over time. And so, https://app.objectrocket.cloud was born.
It’s time for a quick sidebar. For the rest of the story, rather than use new/old, new/existing, etc. let me define for you the two UI’s that I’ll talk about for the rest of this piece:
- Cloud Platform: This is the new hosting platform we built to run instances in public clouds (AWS, GCP, Azure, etc.). You can find this UI at https://app.objectrocket.cloud
- Dedicated Platform: This is our existing platform that runs instances on our dedicated hardware. You can find this UI at https://app.objectrocket.com
I’ve written at length about all of the good things that our cloud platform brings to the table, but the first challenge we had to solve was how to manage the cloud and dedicated UIs. During our open beta we simply launched both side-by-side and had two separate logins. We learned pretty quickly that was not the cleanest path and that it was just too confusing for some of our users.
Instead, we set forth with the strategy of using the cloud UI and auth system as the single login source and using it as a jumping off point with Single Sign-On (SSO) to the dedicated UI for current users. Though it added an extra hop through the cloud UI for some users, it did enable some new features for our existing users (like RBAC and MFA) that we’ve gotten regular requests for. To smooth out that process, we were able to provide an automated migration path and we’ve also added the ability to view databases on both platforms on one screen in the cloud UI.
At this point our login experience looked something like this:
ObjectRocket, a Rackspace Technology Company
As you know from the tagline on our logo, we are indeed part of Rackspace Technology and Rackspace itself has a number of user portals that are used for managing dedicated and cloud resources. Our next challenge was to make the login process smooth for all Rackspace users as well; if we’re all the same company, we should be able to handle our users’ logins consistently.
It required some cross-company collaboration, but this integration was a fairly straightforward project and resulted in the nice, shiny “Log in with Rackspace” button on our cloud login screen. Though our original UI only allowed SSO for Rackspace Cloud users, we expanded our capabilities and enabled SSO for Rackspace Dedicated users.
One wrinkle we encountered is the second step allowing users to use SSO from our cloud UI to the dedicated UI. We wanted to make sure that:
- Rackspace Cloud users were able to get to their accounts in the dedicated system whether they logged into the dedicated app or the cloud app and used SSO.
- Rackspace Dedicated users were also able to SSO into the dedicated UI and create new accounts if needed.
That brings us to today and the various login methods for our product.
We set out on this project in order to create maximum flexibility while allowing our users to use the patterns they’re used to for an extended period of time. However, the number of scenarios to manage has gotten a bit complex and we still see a lot of opportunity to improve the user experience.
The last few phases of this have all focused on adding additional capabilities to cover more user scenarios, but now we need to optimize. We need to start simplifying and making the flow consistent for everyone. Therefore, we will be moving to simplify in the future. Our goals are:
- One Single Auth System: Today, our cloud dashboard accepts the most login options and also provides the ability to move between the cloud and dedicated dashboards. The next step will be to remove the ability to login directly to the app.objectrocket.com dashboard.
- One Dashboard: For managed database instances that run in Rackspace data centers we still use the dashboard at https://app.objectrocket.com. In the future, we will be working to consolidate instances management for all instances into our cloud dashboard.
- Further Rackspace Portal Integration: For our users that use other Rackspace services, we will continue to add more integration points and make the experience even more consistent across products.
Lessons Learned
As we wrap up the first major phase of this project, I look back at the things we learned and the tenets we followed and think there are a few key takeaways:
Tread Carefully
The decisions you make on authentication last a long time and can be complex to change/undo.
Old Habits Die Hard
Plan for a long tail of supporting the “old way” of doing things. Some of our users really only hit the dashboards when they need something immediately, so putting any surprise blockers or additional steps in their path could have caused some bad experiences. We have definitely seen this in practice and have seen users continue to use the original UI despite the ability to migrate.
Continuing to support the original login experience for an extended period has helped a number of those users transition more smoothly without impacting their regular operations.
Buy vs. Build
I’ve written before about how we use Auth0 and there have been a number of scenarios where the tooling built into Auth0 has not only made our lives easier but has accomplished things that would have been a nightmare to implement directly. Their robust support of multiple federation standards, built in support for things like MFA (Multi-Factor Authentication), and included migration tooling all helped us get to where we are today.