Cloud-based ITSM use is rapidly becoming prevalent across several different industries. The global cloud ITSM market is expected to increase with an annual growth rate of 22.3 percent between 2022 and 2030.

Why is this?

Choosing a cloud-based solution for your ITSM strategy can significantly increase the speed of your IT service delivery and save you money by reducing admin costs. But what works for a small organization can quickly fall apart when presented with the challenges of big-scale growth and the impact scaling has on your resources. 

To help you scale successfully, Atlassian Cloud offers features that enable you to extend your ITSM practices across different teams in your enterprise. 

Scaling ITSM with Atlassian Cloud

Atlassian Cloud allows you to scale IT Service Management (ITSM) seamlessly with features that help your organization overcome the barriers and difficulties of introducing new tools, services, and processes.

Uptime 

With ITSM, your entire planning, development, and release processes are grounded in customer satisfaction. If you experience an outage or other downtime, the ITSM goal of serving your customers well isn’t met. Not only is this disappointing and frustrating to your end-user, but it can result in poor business reviews, a loss of customers, and high costs.

As your business grows, your ITSM processes will need to grow with you. Changing your process and the tools can cause downtime. Atlassian Cloud adheres to strict Service Level Agreements (99.90 percent uptime for Premium products and 99.95 percent for Enterprise), which means that your systems will be available nearly 24/7, helping prevent any negative impact on your user experience. 

Security 

Scaling your ITSM practices enables you to consistently — and satisfactorily — meet your customers’ needs. However, rapidly expanding your services and ITSM can have some security risks.

Maintaining secure data access is one challenge your organization can face while scaling. Some strict security measures can be neglected during this transition, making your network vulnerable.

How do you stay on top of these security challenges while scaling your ITSM? 

Atlassian Cloud handles compliance on your behalf, minimizing internal resources spent planning and executing compliance roadmaps and working with auditors. Atlassian Cloud also offers data residency, which enables you to choose where your in-scope product data resides for Jira, JSM, and Confluence. You can choose whether you’d like to host your data in a defined geographic location or globally. Data residency allows you to keep your data secure and meet compliance requirements that accompany highly-regulated industries.

Additionally, Atlassian Cloud provides user provisioning and de-provisioning, reducing the risk of information breaches. Based on the principle of least privilege (PoLP), user provisioning and de-provisioning allow you to control user access to your resources tightly. Additionally, de-provisioning automatically removes user access for users that leave the company, eliminating the security risks that former employees — especially disgruntled ones — can pose.

Finally, Atlassian Cloud implements thorough security measures and constantly monitors for issues related to your cloud infrastructure. If any issues are detected, Atlassian handles these potential threats before they cause damage to your cloud resources and app functionality.

And, because Atlassian Cloud is backed by multi-level redundancy, your system won’t go down while Atlassian handles any unexpected issues.

Flexibility 

As your business grows, you’ll adopt new features, tools, and perhaps more Atlassian products to your stack. With this growth, you’ll also need to extend your ITSM principles across different teams without worrying about hardware-related complications. 

Atlassian Cloud provides a comprehensive stack of Atlassian products that you can implement in ways that align with the capabilities and needs of your organization.

Furthermore, with Jira, you have access to flexible application and project types so you can manage projects in the best way for your teams. Additionally, Atlassian Cloud allows you to upgrade and downgrade resources depending on your business needs. 

Atlassian Cloud Suite of ITSM Tools and Your ESM Strategy 

Atlassian Cloud’s suite of ITSM tools helps your organization improve your Enterprise Service Management (ESM) strategy by supporting core ITSM principles. Some of its features include the following.

Incident Management 

In developing your ESM strategy, your organization must include plans or processes for responding to service disruption resulting from unplanned events and restoring the services to normal. To do this, ITSM teams rely on multiple applications and tools to track, monitor, resolve and even anticipate incidents. 

To keep up with the velocity of today’s incident management, the Cloud versions of Jira Service Management (JSM) and Jira Service Desk place all these functions in one place, enabling your ITSM team to have a transparent and collaborative response to incidents. With this, you can track and manage incidents from the incident report to its resolution in real-time and resume normal operation with the least possible hindrance.

Asset Management and Configuration

One key aspect you need to consider in your ESM strategy is Asset Management and Configuration. You can store hardware assets, software licenses, facility assets, and more using JSM’s cloud-based asset management and configuration services.

Jira Service Management Cloud provides a centralized asset database, making searching for asset and resource information less stressful.

Multiple members of your ITSM team can access assets and asset information from any device with an Internet connection — and in any location — without error or conflicting information. It also synchronizes your asset database across all your organization’s branch offices in real-time, reducing or eliminating asset loss.   

Service Delivery 

To provide an effective service to your end-user, you need to identify customers’ needs and any issues that arise. A quality ticketing/response system improves your service delivery through increased awareness and ability to triage, enhancing visibility into potential issues.

With JSM, your teams can receive incoming issues and requests from customers and team members. This enables you to better prioritize and understand the scope of issues and service requests so you can first address time-sensitive requests.  

Additionally, you can configure JSM to direct tickets to the appropriate ITSM team automatically. With this, the appropriate team can address the customer’s request and escalate issues if further assistance is required to address customer requests — while skipping the process of determining who should handle the ticket.

Conclusion 

Operating in Atlassian Cloud enables your organization to expand ITSM capabilities throughout your entire organization. 

While scaling your ITSM practices may seem daunting, it doesn’t have to be with proper guidance and support. Praecipio Consulting, an Atlassian Platinum Solution Partner, can help you take the guesswork out of scaling ITSM. From developing a solid ESM strategy to tips on how to increase efficiency and eliminate downtime, Praecipio Consulting is here to help. Contact Praecipio Consulting today to start scaling your ITSM practices with Atlassian Cloud.

Atlassian offers many products to help you increase your productivity, including Atlassian Cloud and Atlassian Data Center. Though both Atlassian Cloud and Atlassian Data Center give you access to a full stack of Atlassian tools, they serve different purposes depending on the needs of your organization.

 Atlassian Cloud is a managed and hosted solution, meaning Atlassian handles all required infrastructure and hardware for you. By maintaining and hosting your infrastructure for you, Atlassian Cloud helps you innovate faster with less management required.

Atlassian Data Center, in contrast, requires a self-hosted environment, meaning you have an on-premise center that you maintain, upgrade, and secure. Although you have to perform these management tasks yourself, Atlassian Data Center promotes flexibility and enables you to build a custom-tailored solution.

Both versions of the Atlassian suite include core applications like Jira Software, Jira Service Management, Confluence, and Bitbucket. However, some applications like Trello and Opsgenie are available with Atlassian Cloud only, while others, like Bamboo and Crowd, are only available in Atlassian Data Center.  

Whether Atlassian Cloud or Atlassian Data Center is the best choice for your organization depends on your use case. This article highlights use cases where Atlassian Cloud or Atlassian Data Center would serve you better, helping you decide between Atlassian Cloud and Atlassian Data Center.

Atlassian Cloud Versus Atlassian Data Center: Use Cases

To understand the differences between Atlassian Cloud and Atlassian Data Center, you can compare the features, accompanying stack of Atlassian tools, and infrastructure management requirements for each solution. However, it’s also helpful to compare the use cases for each solution and understand how their capabilities and limitations match up to your organization’s business goals. 

Atlassian Cloud

Global Product Teams

Globally-distributed product teams need tools that enable collaboration without adding friction. Atlassian Cloud tools like Jira and Confluence let remote teams brainstorm, plan, and track the development of new product features from anywhere, on any device, without requiring anyone to sign into a company VPN to use on-premises tools.  

Security and Governance

Integration with Atlassian Access means Atlassian Cloud apps work seamlessly with your existing single sign-on (SSO) and identity management infrastructure. Atlassian Cloud is compliant with strict regulations like PCI DSS, SOC 3, and GDPR, so you can spend more time being productive and less time worrying about compliance and governance.

Reliability

Global enterprises need tools that work 24 hours a day because downtime is expensive. Atlassian Cloud offers service level agreements (SLAs) up to 99.95 percent — meaning your productivity apps are always available when needed. 

Looking to Leverage Cloud-Only Atlassian Tools

Some Atlassian tools are only available in Atlassian Cloud, such as: 

• Trello for lightweight project planning and collaboration
• Opsgenie for IT incident response and on-call management

If applications like these are essential parts of your organization’s workflows, Atlassian Cloud is an ideal choice.

Atlassian Data Center

Requiring More Infrastructure and Environment Control

Large, established teams that require more control over their infrastructure than Cloud offers can use Atlassian Data Center. While Atlassian Cloud offers excellent flexibility, Atlassian Data Center lets you control how and where you run your applications. Atlassian Data Center is the ideal choice if you require a traditional on-premises deployment or want to deploy to a private cloud. 

Additionally, if you’re working in an industry that requires a high level of control and security, like a government agency or financial institution, using Atlassian Data Center would be an ideal solution because it gives you tighter environmental control and customizability to maintain security and meet regulatory conditions.  

Retaining Customizations Over Time

Atlassian Data Center is the best choice if your teams are moving from previous versions of Jira Software or Confluence and you want to retain customizations built into your products over time. Many long-time users of Atlassian applications have built deep integrations between these apps and internal line-of-business systems. Making those integrations work with Atlassian Cloud may range from difficult to impossible.

Adding New Customizations

Organizations looking for more customization options to meet their exact business needs without sacrificing performance or security are better-suited to Atlassian Data Center. Although Atlassian Cloud offers many integration points via APIs, on-premises Atlassian deployments are easier to integrate deeply with the rest of your enterprise’s applications. 

Needing to Meet Compliance Criteria

Organizations with strict compliance and regulatory requirements may not be met by Atlassian Cloud’s capabilities (though note that Cloud does support SOC2, SOC3, and PCI DSS). 

With Atlassian Data Center, you are fully responsible for managing your system’s security and ensuring it stays compliant with industry regulations. This means additional work for your organization, but that application security and compliance are as strict as you need.

Thinking Long-Term About a Cloud-first Future

Migrating to the cloud offers notable long-term benefits, including server savings of 30 percent, which is due to right-sizing servers, IT cost savings of 20 percent, and giving your organization a competitive edge by enabling staff to spend more time on strategic, business development tasks and less time on infrastructure maintenance and planning. These benefits have led to widespread cloud adoption, with Gartner predicting that more than 50 percent of IT spending will shift to the cloud by 2025.

Although you can use Atlassian tools in your data center, migrating to Atlassian Cloud offers additional benefits that help future-proof your business and enable you to get the most out of Atlassian tools, including: 

• Improved team collaboration and easier access to Atlassian experts if you need support, training, or mentoring.
• Reduced IT resource costs associated with maintaining your in-house infrastructure.
• Better scalability to meet peak demands without downtime; data centers cannot be easily scaled vertically like SaaS.
• Get faster time to value with Atlassian’s latest apps, features, and integrations. You can use the newest apps and features as soon as they are available rather than waiting for an upgrade cycle.
• Moving your Data Center products to Cloud means you can take advantage of Atlassian’s SaaS-only tools.  

Conclusion

Choosing between Atlassian Cloud and Atlassian Data Center is not always a clear-cut decision. It’s important to fully understand what you’re looking to achieve by using an on-premise or Cloud-based solution and what tools each solution offers to help you meet your goal.

Migrating to Atlassian Cloud reduces costs, minimizes maintenance times, and enables you to develop faster. However, performing a migration can be challenging, especially if you’re not starting with a fresh instance. You must migrate your users, apps, and data, meaning the chances of downtime and overall complexity are high. Similarly, when working with Atlassian Data Center, you take on significant maintenance, security, and configuration responsibilities. Though this independence provides you with more control over your instance, it also means you don’t have direct support from Atlassian if there are any problems with your infrastructure.

Fortunately, you’re not alone. Praecipio is an Atlassian Platinum Solution Partner, and we’re ready to help you select — and implement — the best Atlassian solution for your enterprise. Contact Praecipio to help guide you through the journey of a successful migration to Atlassian Cloud or Atlassian Data Center.

Praecipio Consulting has partnered with our friends at resolution, an Atlassian Gold Marketplace Partner based in Germany that specializes in software development and network security, to bring you a series of blog posts about how to successfully implement single sign-on (SSO) with Atlassian tools. With more than 7 million users from 58 countries, resolution is the market leader for Atlassian Enterprise User Management Apps.

In the last article of these series on the journey to Atlassian SSO, we followed the steps of ACME, a company with large instances of Jira and Confluence on prem, planning a migration from AD FS to Azure AD.  

In particular, we had a detailed look at: 

• How users from the Atlassian directories can be seamlessly migrated into Azure AD building a no code integration with User Sync 
• How users can be mapped between Azure AD and the Atlassian applications even if usernames don’t match 
• How to connect users from different organizations (ACME and CU.com, a consultancy firm) each with its own Identity Providers, both for authentication and provisioning purposes. 

In order to complete the setup, however, ACME needs to add some restrictions to CU.com users to answer the following questions:  

• Who at CU.com must have accounts in ACME’s Jira and Confluence? 
• How long should access be retained? 
• How should access be revoked? 

Let’s look at how to automate the process for onboarding and offboarding consultants so that these are the answers: 

• Who should have accounts? Only contractors assigned to active projects. 
• How long should access be retained? Only for as long as the project is active. 
• How should access be revoked? Automatically, as soon as the project concludes. 

How to provision only contractors assigned to active projects 

Let’s quickly recap what ACME needs to set up: 

Challenges 

• Access to ACME’s Atlassian tools should only be granted to consultants who have been assigned to specific projects.  
• Consultants have a quick turnaround. It’s important to give them access quickly and deactivate them as soon as their assignments conclude. 
• It’s also vital to ensure that consultants only occupy licenses of the Atlassian products while they´re on an active assignment. 

Implementation steps 

The approach has four steps:  

1. The group that gives consultants access will be operated from Contractor’s Okta and filtered in ACME’s User Sync connector. 
2. Specific project permissions and roles in the Atlassian applications will be managed locally.  This has important implications, as the Okta and local group settings must coexist and not overwrite each other. 
3. The synchronization between Okta and ACME will be scheduled to run every night (but users will also be updated when they login, eliminating waiting times entirely). 
4. As a result of the synchronization, consultants who no longer are on active assignments will have both their access and their licenses revoked. 

Here’s the walkthrough: 

• Go to User Sync > Azure AD Connector > Edit > Advanced Settings 
• In Groups mandatory to sync a user, create a new entry 
• Add the group active-acme-jira-project 

It's extremely important to add this information! Failing to do so results in removing access  to Jira projects:  

•  every time the contractor logs in 
•  with each user sync. 

However, we can protect groups in both contexts from the User Sync connector,  

• To protect the groups in the connector, we go back to the Advanced Settings and add all the groups used to give permission to Contractor Unlimited consultants in the Keep these Groups field. Note that you can either include every group, or regular expressions, if there are any patterns.  

*

• In the cleanup behavior dropdown, select disable users. 

What does this last step mean? Consultants will be automatically deactivated in Jira and Confluence following this process: 

• When an assignment concludes, the consultant is removed from the active-acme-jira-project group 
• At 3am, the user sync connector runs 
• The user is removed from the active-acme-jira-project group in Jira, together with any other changes. 
• As a consequence, the user is deactivated in Jira. 

Bonus trick: With the right SAML setting, if the consultant logs into Jira after they have already been removed from the active group, the login will succeed but will also result in the deactivation. 

We reached our destination! 

Congratulations! You have finished the journey to Atlassian Single Sign-On! Hopefully by this time you are on your way to an implementation that will last for many years to come. 

The sample implementation in the last two articles has offered a selection of very popular options among Atlassian on prem customers. As you have seen, User Synchronization is very often a cornerstone of the implementation, since it permits to use the Identity Provider as a single source of truth to automate user on- and offboarding. At the same time, it’s compatible with multi-IdP setups and access provision to partner organizations. 

However, the example is just that – an example. And it might be very different to what you need to solve. 

How can we help you? 

If you have any doubts or need help with advanced technical issues, there are several next steps. 

• Our friends at Praecipio Consulting will be happy to help you get up and running. We go way back with a long history of shared implementations.  
• If you need help configuring the resolution SAML SSO application or the User Sync standalone that can be combined with the Data Center SAML, we provide free screenshare sessions every day. 

Excited to see you there, very soon! 

Congratulations on reaching the final destination in our very special journey to combine frictionless Atlassian applications with enterprise security! If you haven’t yet, you can have a look at the first article on the symptoms that your company needs a single sign-on solution and the second part on the existing opportunities to implement Identity Providers with your current infrastructure. 

With the goal of identifying realistic solutions, in the third article we reviewed the top SSO requirements for Atlassian Data Center applications:  

• Are usernames consistent across user directories? 
• Are there multiple sources of identity? 
• Do you need to centralize user management on your Identity Provider? 
• Is there a need to automate user activation and deactivation? 

Then, we mapped possible responses to competing alternatives so that you could tell when Data Center SAML could do the job, and when it would be better to look for an alternative in the Marketplace. Go back to our detailed comparison if you want to dive into the enterprise customization options! 

In the following two articles we will see the four requirements come together in a killer implementation of resolution’s SAML SSO. Let’s follow the steps of ACME Services Ltd! 

ACME is (obviously) an imaginary company based on the hundreds of customer implementations that our support team has guided to completion. 

The starting point  

1. As part of a larger effort to centralize user management in a central team, the company ACME Services has decided to migrate their Jira and Confluence users from a local Active Directory where users login locally with username and password to Azure AD.  SAML SSO will be used to connect with the Atlassian applications. 
2. ACME works for specific technology projects with Contractor Unlimited, a large consulting firm. Consultants will need access to ACME’s Jira and Confluence applications with their existing Contractor accounts, hosted in Okta. 
3. Obviously, only the contractors assigned to projects can have access, which should be revoked as soon as their assignment concludes. This step will be shown in an upcoming article. 

Note: While the scenario includes both Jira and Confluence, we will only cover the implementation in Jira as an example. Keep in mind that the steps are virtually identical for both applications! 

1. The migration from the local AD to Azure AD 

Challenges 

1. Usernames sent from Azure AD are different to the local Atlassian usernames:  first.lastname@acme.com versus first.lastname 
2. ACME has a central IT department separated from the team of Atlassian admins, and collaboration between both teams usually takes time. To increase the speed of the implementation, it has been decided to transform usernames on the Atlassian application. 
3. Users from Jira must be first migrated to Azure AD, since it’s a historic instance with thousands of existing tickets. 

Prerequisites 

In this guide we will focus on the critical tips and tricks, but will assume that you already have a basic working configuration that includes: 

1. Creating a User Sync connector for Azure AD following the Configuration Guide for Azure AD. Do not sync yet! It's best to wait until the implementation is complete. 
2. SAML SSO configured with your Azure AD. Here is the guide 
3. Having read, understood and followed our guide on how to migrate the Jira/Confluence internal directory to User Sync to retain user history, groups, etc. 

It’s convenient to configure User Sync and SAML SSO in this order so that you can select an existing User Sync connector to provision your users during the SAML SSO setup. 

Important note: Migrations can be messy, so it’s fine to recognize it if you have trouble solving the 3 prerequisites above. Don’t be afraid to ask for help either Praecipio or resolution –we regularly host free screenshare sessions with our customers to get their SAML SSO implementation ready for production! 

Implementation steps 

In this walkthrough, we’ll implement username transformations on both the SAML SSO login process and the User Synchronizations via API. You may we wondering why the transformation must be completed on both sides. We asked one of our engineers, and here's what he said: 

"What happens when the SAML SSO app searches for a user during login and the user is not found? That the login will fail. That's why you need to keep the transformations consistent on both sides. If User Sync creates a username “example” stripping the email domain that is stored in Azure AD, and then SAML SSO searches for a user called example@domain.com without stripping the domain before looking it up, it will fail to find the user. 

1. First, let’s instruct the User Sync Connector to copy user attributes from the local directory into Azure AD whenever a user is created. You can find this in the advanced settings of the Azure AD connector you have just created. 
2. Now we need to configure how usernames will be transformed as they are synchronized into Jira/Confluence from Azure AD
   • Go to Attribute Mapping in the advanced User Sync settings, and click on Edit for the username row 

• Now it’s time to add the transformation. Here’s the regex example that would do the job of transforming elon.musk@acme.com into elon.musk: 

Regular expression: ^(.*)@.*$ 

Replacement: $1 

• As in the example above, you should test with a real user whether the transformation works. 
  
  3. Now we need to configure the same transformation in SAML too. 

• Go to Identity Providers > User Creation and Update > Attribute mapping and click on Edit for the Name ID / username row 

• Use the template from the dropdown to strip the email domain 

• Click apply and save your SAML configuration. 

Note: The no-code option to strip the email domain from a dropdown will be included in the upcoming release of User Sync, both as a standalone and as a feature of the SAML SSO apps. 

e top.

1. Connecting users from multiple organizations into the same Jira

After the initial setup, Contractor Unlimited (CU.com) need access to Jira/Confluence. Since they also want to use SSO connected to their Okta, a new UserSync connector is configured for Okta. 

Challenges 

• Implementing the most appropriate method of combining both Identity Providers (IdPs).  

The final decision is that Okta should be triggered based on the Contractor Unlimited email domain. An alternative would be to show an IdP selection page where users can select whether to log in with Azure AD or with Okta. However, the central identity team at ACME prefers the ACME login to be a more branded experience without a reference to Contractor Unlimited’s Okta. 

Prerequisites 

• Setup Acme's SAML SSO, now with the Contractor Unlimited's Okta instance. Follow this guide. 
• Configure a User Sync connector with their Okta. Follow this guide. 

If you want to know more about the different IdP selection methods, you can watch this video tutorial. 

Implementation steps 

1. Go to SAML SSO > IdP Selection 
    
2. In the dropdown, choose select IdP by Email Address     
3. Now, let’s create a new rule item so that CU.com emails are routed to Okta for authentication 
4. In the rule, we’ll add the domain in the corresponding field. In this case, cu.com becomes cu\.com
5. Now, let’s test the email of any contractor to check whether the rule is triggered.  
6. Let’s now repeat steps 3-5 for acme employees and Azure AD. The result should look something like this: 
7. Finally, ACME decides to tweak the selection page a little bit so that it has the right look and feel. 
   To do that, they go to the page templates section of the SAML SSO configuration
    
   and navigate to the IdP Selection By Email Page Template (2nd template) 
8. And that’s how it looks like for them by simply changing the font and adding their logo! 

To be continued: Setting up an automated process to provision and deprovision consultants. 

At this point, CU employees have access to ACME's Atlassian tools. The door is open. But ACME still has to make sure that it the door can be closes so that only CU.com contractors who are actually needed can get in. 

In the next and final article of the series, we’ll look at how to set up an automated process for onboarding and offboarding contractors so that they always have access when they need it, and they immediately lose it when their project is over. Without manual work, and without any bottlenecks. 

Stay tuned!

Praecipio Consulting has partnered with our friends at resolution, an Atlassian Gold Marketplace Partner based in Germany that specializes in software development and network security, to bring you a series of blog posts about how to successfully implement single sign-on (SSO) with Atlassian tools. With more than 7 million users from 58 countries, resolution is the market leader for Atlassian Enterprise User Management Apps. 

In Part 1 and Part 2 of this blog post series, we saw the main symptoms of a password disease that can be healed when applications are secured with single sign-on. We have also taken inventory of the core identity assets involved in an SSO implementation -- including web applications, SSO connectivity, user directories, and opportunities to deploy identity providers. 

In other words, we’ve looked at where you are. It’s now time to look at where you want to go.  

A part of that journey involves making a final decision about what will be the home for your user accounts once you move away from Active Directory. Will it be Okta? Azure AD? Or some other vendor? 

Another part of that journey relates to extremely specific requirements that you will need to analyze to make sure that the implementation of single sign-on in Atlassian applications makes all stakeholders happy.  

In this article, we'll spell those requirements out. 

Write them down. These are the most important questions that you will need to answer in full detail before evaluating specific SSO solutions for your Atlassian applications. 

Question 1: Do your Atlassian applications support SSO out of the box? 

We saw this already in the last article, but it’s worth revisiting. 

Your options depend entirely on the type of hosting of your Atlassian products, as you can see in the summary table. If you are on Server, you will plan a migration to either cloud or Data Center in the next couple of years, so that's where you should look. We won't consider SSO solutions for Server applications in this article, although the answer is easy: go to the Atlassian Marketplace. 

If you are on the Atlassian Cloud, your options can also be spelled out with 2 words: Atlassian Access. The good thing is that you need to search no more. The downside is that Access can be quite expensive, and there is no competition. 

In terms of functionality, Access has everything you can ask for. In fact, it does much more than just SSO, making it a high standard against which other solutions can be measured.  

Audit log, directory syncs, and lifecycle management are components that go beyond the basic SAML SSO functionality and towards a comprehensive Identity and Access Management framework on the Atlassian stack. 

If you're already on a Data Center license or planning a migration in the next couple of years and before the Server End of Life in 2024, then you do have (or will have) SAML SSO out of the box. But the Data Center SSO offering is far away from Access. Which takes us to the next question.  

Question 2: Will Native Data Center SAML SSO be enough for you? 

Here are some facts:  

• Atlassian started providing native SSO capabilities with the SAML protocol in 2019. Originally as a free app, it’s now a preinstalled app for any Data Center customer. 
• While more functionalities are being added to the SAML based authentication, the app is still behind. You can check their roadmap here. 

What this means is that if you have a simple need and a simple infrastructure, Data Center SAML SSO may work for you. Otherwise, you should look for a commercial alternative. In this article we will look at how common additional requirements are covered by resolution’s SAML SSO apps, with over 7 million users in 58 countries. 

Let’s have a quick overview of what the Data Center SAML SSO can do before we look at how additional requirements can be solved with resolution’s SAML SSO. 

A quick overview of Data Center SAML SSO: 

First, we'll cover the main functional requirements that Data Center will solve. 

At a high level, the Data Center SAML SSO app can: 

• Authenticate users into Jira, Confluence, and Bitbucket Data Center on behalf of an Identity Provider. Spoiler alert: you will need exact username matches on both sides (see question 3). 

• Create users into the Atlassian applications during their first login, without the user being prompted to enter their Atlassian password. This is commonly called Just-in-time provisioning and happens with the information that the Identity Provider sends in the SAML response. 
  
• Update the information stored in the local Atlassian directory. This also happens during login exclusively and applies to the group memberships that define user permissions and access. 

There’s no question that these three functions alone are powerful. However, a more detailed examination is needed to ensure that you can effectively implement Data Center SSO with your current infrastructure. 

The following two questions are aimed at clearing that part of the dilemma, before we embark on additional functional requirements. 

Question 3: Do you have different naming conventions on the Identity Provider and in the local Atlassian directories? 

If the answer is no, then Data Center SAML SSO will accommodate you right away. You can skip to the next question. 

For example, if you are implementing Azure AD the UserPrincipalName attribute will be populated with user emails. If you also have email addresses in the Atlassian username, the match will be perfect. 

But if the answer is yes, it will not work. When the usernames don’t match immediately on either side, it will be impossible for the Data Center SAML SSO to identify which user in the Atlassian database is trying to log in. 

This will happen, for example, if instead of the example above, there are full names in the Atlassian usernames. 

This will give you two workarounds: 

• Modifying all the usernames in your Atlassian applications to align them to the naming conventions in the IdP (Identity Provider). 
• Modifying usernames on the IdP side to align them with Atlassian (but potentially disrupting the rest of your connected applications). 

But if you want a more elegant solution, you can use the user-mapping and transformation features in resolution’s SAML SSO.  

In our example, there are two different strategies to create a match with resolution's SAML SSO: 

1. The UserPrincipalName is mapped with the e-mail attribute, which can be then selected as the attribute that is looked up in the Atlassian database for authenticating users. 
2. The UserPrincipalName is transformed into the username by simply stripping the email domain.  

Note: No-code transformation options are quite varied. 

Question 4: Do you have to connect Atlassian applications to multiple identity sources? 

Enterprises rarely have a single, monolithic user directory. For historic and legacy reasons, but also because IT governance models give a lot of autonomy to geographic regions, it is most common to have a few user directories, even from different vendors. 

But even in more centralized approaches, large organizations tend to have separate user directories for different types of users, even if those directories are provided by the same cloud vendor. For example, Jira users and Jira Service Management agents could be stored in different instances of Okta. And it's even more common to separate customers and employees. 

If that is your case, then you won’t be able to use the Data Center SAML SSO app. 

On the contrary, in resolution’s apps, you can setup multiple IdPs and decide when each of them is triggered based on multiple methods: 

• The user’s decision on a selection page 
• The user’s email domain 
• Specific information included in the http request headers 
• Priority scores (by weight) 

Note: Atlassian has put this feature on their short-term roadmap, but it’s unknown what will be possible with it and whether the setup will support dynamic IdP selections. 

Question 5: Do you want to centralize user management from your Identity Provider? 

In an enterprise setting, there is not a right or wrong answer to this question. It can make sense to manage users in every application locally. This usually happens when the IT team has the right expertise, and the company is small enough that change requests don't swamp the workload. 

But on a larger scale, a decentralized user management framework can become a major issue.  

What happens when user management is centralized? As employees are promoted, change department, or are assigned to a new project, permissions can be changed directly from the Identity Provider alone. Then, they propagate immediately to all connected applications. 

The technology behind this benefit is a one-way synchronization from the IdP to the connected apps via API. Once set up, the sync will update users’ group membership at regular intervals and therefore automatically modify their access rights. 

Data Center SAML doesn’t have the ability to sync with IdPs, which exists both in Atlassian Access for cloud applications and in resolution’s SAML SSO apps. 

As you can see in the image, resolution’s User Sync functionality provides connectors with most commercial IdPs. Connectors can then be configured so that they align to your group management practices and nomenclature. We will show a practical example of this in the next article. 

Question 6: Do you want to automate user on- and offboarding? 

User syncs are vital if you want to automate user management throughout the entire lifecycle.  

Besides the satisfaction of having the power to control every detail, few administrators enjoy onboarding new users into every application. They understand it’s a job that needs to be done. They also grasp the urgency of removing access to applications when an employee leaves the company. But sometimes they might be too busy to put that task at the top of their list or to double check that every access was effectively disconnected. 

User syncs can automate the three key on- and offboarding jobs: 

• When a new employee joins the company, they have immediate access to every application without even having to login for the first time. 
• When an account is deactivated on the IdP, all accesses are immediately blocked. 
• Deactivate users temporarily when they don’t access an application like Confluence for a specific time (for example, 3 months)  

For the third job, it’s even possible to create a specific connector that takes care of the automatic deactivations. 

How to evaluate your answers 

Until now we have looked at the main requirements that you must consider for your SSO implementation. It's vital to have a clear answer to all these questions before making a final decision.  

But now that you have your answers, let’s translate them into realistic options. 

 The table below summarizes your options, mapping combinations of answers with the most suitable SSO solution.  

To find which product we recommend for your use case, simply find the row that contains your answers. 

As you can see, there are three main possibilities: 

• If you don’t have any of the requirements listed in questions 3 thru 6, then Data Center SAML SSO might do the job.  
• If you answered yes to question 3, question 4, or both, then it seems like resolution’s SAML SSO will be your best shot. 
• If you answered no to 3 and 4 and you still want to automate user management, then you have two alternatives:   
• The simple alternative is to go for a complete product like resolution’s SAML SSO. This will simplify your implementation and the number of touchpoints with support experts. 
• The cheap alternative is to implement the existing functionality in Data Center for the basic SAML, and resolution's Users and Groups Sync to automate user management. This will make you the advanced features you need to manage users and groups, but at half of the prize of the SAML SSO app. 

Now you know what’s your basic fit.  

Make sure to complete your evaluation going over all your additional requirements as instructed in the next paragraph. 

Continuing your evaluation  

We hope that our attempt at boiling down your implementation project to its essentials was successful and your scenario is realistically captured in the options above.  

But beware! These six questions leave out many details. To quickly cross-reference your feature wish list, we have published a full tour of customization options and how they compare to the Data Center defaults.  

Here’s a high-level preview. 

But if you want to learn how it works, have a look at the in-depth comparison we have prepared for you. 

What’s Next 

In this article we have reviewed the native SSO capabilities of Atlassian products depending on their hosting type and doubled down on what Data Center SAML SSO can do. We have then focused on three major requirements that cannot be solved with it: username mapping and transformations, multi-IdP setups, and user management automations. Finally, we have taken stock of the combined requirements and presented the best solutions for each of them. 

The next article will conclude the journey to your Atlassian SSO, going even deeper into how to address these requirements with resolution’s SAML Single Sign-On. We will go over the implementation project of an imaginary company that has decided to migrate out of their Active Directory into a cloud Identity Provider. We will identify their challenges, understand the value that the implementation will create for the business, and offer reproducible how-to steps to solve their case. 

We've got you covered with more tips on advancing your journey towards a successful single sign-on for your Atlassian tools with the last installment of our blog series. Stay tuned! 

Praecipio Consulting has partnered with our friends at resolution, an Atlassian Gold Marketplace Partner based in Germany that specializes in software development and network security, to bring you a series of blog posts about how to successfully implement single sign-on (SSO) with Atlassian tools. With more than 7 million users from 58 countries, resolution is the market leader for Atlassian Enterprise User Management Apps.

In the last article, we offered an overview of the most common pain points that can be felt across an enterprise when no single sign-on (SSO) solution has been implemented – or when it doesn’t extend to important corporate software like Atlassian tools. 

Now you understand that without SSO, end users will stick to bad passwords habits.  

Your Help Center will be flooded with password recovery requests.  

And, to the despair of your security experts, your admins will keep forgetting to deactivate former employees from Jira’s internal directory. 

So, what are you going to do about it? 

Luckily for you, we are laying the grand journey to SSO before your eyes. In this, article we’ll show you the exact steps to take inventory of your existing identity resources. Once the inventory is completed, outlining the implementation project and choosing the SSO vendors should be straightforward. 

Step 1: Take inventory of web applications 

What software do your employees use? Completing an inventory of all the B2B apps used in your organization is easier said than done.  

By some accounts, employees used an average of 191 accounts in 2017; but about half of the workforce uses software that was not distributed to them by their IT department. 

When setting out to complete the list, try a good cop approach. Interview colleagues at different departments and explain the benefits of bringing every possible application under the roof of a unique, centralized login. 

A percentage of these applications will be small SaaS vendors where the head of the department paid with a corporate credit card without requesting a budget approval for it. This type of products have all the chances of becoming Shadow IT: unaccounted for and unknown to the IT department until there’s a problem. 

However, for the purpose of single sign-on you should only be concerned about the apps that are relevant: 

• They’re used everyday by some roles 
• They are essential to completing the employee’s job description 
• They have individual user accounts 
• They contain sensitive data about the company that you shouldn’t be disclosed 

Atlassian tools like Jira, Confluence or Bitbucket meet all items on the above checklist.   

In case of doubt, a quick scan of data sensitivity should be enough to convince you. Bitbucket is the repository for the company’s software, Jira Software has all the plans about the product’s future features, Jira Service Management contains hundreds of customer conversations, and finally, Confluence is used to organize and disseminate documentation, strategic business plans, and links to confidential assets. 

Step 2: Check which applications support SSO  

Once you know which web applications you need to connect to your SSO solution, you should perform a quick due diligence:  

• Does the application support SSO natively?  
• If yes, what protocols can be used to connect it? SAML, OAuth/OIDC, SSH, or even older ones? 
• If no, are commercial connectors available that you can rely on to do the job? 

Atlassian on-premise applications, for example, do not support SSO natively. However, there are plenty of alternatives in the Atlassian Marketplace that allow them to connect to IdPs, mainly via SAML. Resolution’s SAML SSO is the most important example. 

In the case of Data Center, there is also a free SAML SSO app by Atlassian that covers a part of the SSO specifications, including authentication and some other aspects of user management. We will go into more details in the following article of this series. 

For each of the applications in your inventory, you will have to ask yourself: Where are the application’s users? Are they stored internally in the application, or are they drawn from a corporate user directory? 

In the case of Atlassian users, there are three main non-SSO options: 

Option 1. Users are stored in Microsoft’s Active Directory 

Active Directory (AD) is starting to be a legacy technology from the time of Windows 2000, but it’s still the most common starting point for a lot of companies using Windows Servers.  

When your users are stored in AD, they can be synchronized with Atlassian applications using LDAP – then they will be able to use their AD credentials for the Atlassian login. 

Pros: It’s a well-tested option that is natively supported by Atlassian applications. Besides, many customers are already using the AD FS role to integrate with cloud services like Office 365 or Salesforce via SAML. And if they haven’t yet, they can do it for free. 

Cons: LDAP is a very poor choice in remote-first approaches: it usually requires firewalls and VPNs, it scales poorly in terms of performance, and it’s not supported by many cloud Identity Providers.  

Option 2. Users are stored in Jira’s internal directory 

Jira’s internal directory can also be connected to other Atlassian products like Confluence to be used as the source of users. 

Pros: Users don’t have to be managed in other Atlassian applications. They can be centrally run from Jira’s internal directory. 

Cons: The most important disadvantage is that Atlassian applications will still be siloed against the rest of your tools. Every time you adjust access and permissions for an employee, you will at least have to do it twice: once for Atlassian apps, another for your other directories. 
Additionally, when Jira is down, your entire Atlassian stack will be unavailable. 

Option 3. Users are stored in multiple directories, but centralized with Crowd 

Many enterprises have multiple on-premises historic instances, each of them with their quirks and their settings. Often times some are Data Center, other are Server. Rather than merging everything, standardizing and consolidating in a mega instance, it’s simpler to just accept the complexity and add Crowd into the mix to centralize user management. 

Pros: Federating multiple Atlassian instances with Crowd is fairly simple, and you can manage users and their permissions across different directories. 

Cons: Crowd is sold as an SSO solution, but that is only true for Atlassian products. If a user logged to Crowd tries to access any non-Atlassian tool where he doesn’t have an open session, he will be prompted to login. Also, Crowd cannot handle SAML responses from an IdP. 

Step 4. Analyze IdP opportunities 

You will need an Identity Provider that can serve as the single source of truth for user identities in all your applications. 

A new IdP can be a significant financial commitment. However, sometimes you can get a top IdP vendor for free because you are already using their technology for other purposes. Let’s have a quick look at the most common scenarios. 

Have a look at resolution’s independent evaluation of the most important IdPs for more details. 

Scenario 1: Microsoft Active Directory 

Second time we encounter AD in this article, and it’s no coincidence.  

If your administrators are already using Active Directory to manage employee access and permissions to your networks' resources, then you can have SAML-based SSO for free. Simply make use of the AD Federation Services role and start using AD FS as your Identity Provider. 

Scenario 2: Office 365 

A similar scenario to the above, but with cloud pieces of Microsoft’s game. If your company is on Office 365, then you can get Azure Active Directory for no additional cost.  

If you do so, keep in mind that the free version of AD FS has some important limitations:

• You can only use applications in the Azure app catalog (don’t worry too much, we are in the catalog) 
• Some advanced features like user assignments will only be available on a per user basis 
• Conditional access policies, including MFA, will not be available at all. 

Scenario 3: GSuite 

Everyone has a Gmail account, and thousands of companies, particularly in the US, have adopted Google Workspace (formerly G Suite) for their office applications. If that is your case, then choosing Google’s Cloud Identity is a natural option. 

Cloud Identity Premium is included in the premium tier of Google Workspace with a cost of $25 per user, per month. 

Next Steps 

In this article we have seen how to build a comprehensive inventory of your identity assets that includes sensitive B2B applications, the user directories for your Atlassian users, and common opportunities for adding an IdP vendor from your existing stack. 

For the next article of the series, we will go over the most vital questions that will help you define the scope of your SSO implementation. 

Will a simple setup be enough? Will you connect users coming from different directories? Will you automate user creation and deactivation? These are some of the considerations that will impact your project and what a successful solution will look like.

In the fourth and last article, we’ll inspire SSO project leaders with walkthroughs and actionable examples of advanced implementations.

Stay tuned to for more tips and insights on advancing your journey towards a successful single sign-on for your Atlassian tools!