Here at Atlassian, we recently went through an exercise to consolidate the authentication and identity management of our key support systems. As we have grown, we have seen a number of account silos materialize across our system landscape. This required customers to have separate logins for support, forums, account management, etc., resulting in a frustrating experience for our customers, and a tough situation for Atlassian staff. The problem of multiple account silos is common across the technology domain, yet is a surprisingly difficult one to resolve. It starts with a simple requirement: “We want to use the same login for multiple systems.” But what sounds easy on the surface can quickly evolve into a complex blend of concerns across technology, data migration and separate functional teams. As a project manager for Atlassian’s Internal Systeam team, I learned this the hard way. So I am pleased to be able to outline the process and technology solution we used as part of this project, in the hopes that it will mitigate some of the headaches in delivering similar initiatives. Welcome to a Behind the Scenes look at the creation of Atlassian ID. Challenges and Learnings Before diving into the solution and design process, I will comment on some of the key challenges (both technical and non-) and learnings. Our biggest challenges were: Multiple teams. By its nature the project required engagement across a number of functional groups within Atlassian. This was made somewhat easier than in most organisations due to Atlassian’s fast moving pace and can-do-it culture, but it was also a double-edged sword. Once we had agreement with the teams, it was necessary to keep up with them as they powered ahead providing new services and capabilities on their system. Availability. Having one user base for all your applications can be effectively like putting all your eggs in one basket. You don’t want that basket to break. Availability was a significant challenge to tackle throughout the solution. Customer migration. This was a big one. We had seven systems and a large user base that had been diverging for over 10 years. You name the scenario… we had it. What did we learn from the process? What stood out were: Data migration is hard. I have learnt this a couple of times previously in my experience but I was once again reminded. Data migration is hard and always takes more effort than you think. Plan it out…then double. SSO is important. From a technical perspective there is an urge to dismiss this as unimportant. The reality is that SSO is hard. It raises a number of security and distributed ‘state’ concerns that need to be dealt with. The alternate argument is that all browsers remember usernames and passwords, meaning only one additional click for users. Surely a single username and password rather than SSO is ‘good enough?’ More often than not the answer is ‘no.’ By giving away SSO you are sacrificing the ability to really provide a seamless customer experience. In addition, you are losing additional technical capabilities that can be extremely useful. The primary [...]
Previous Topic
