32 min read

The Journey to Atlassian SSO, Part III: 6 essential questions that will define the scope of your Atlassian SSO implementation

By resolution on Feb 17, 2021 9:07:08 PM

Blogpost-display-image_Blog Series-Pt3Praecipio 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? 

blog_sso-pt3We 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 AccessThe 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 2Will 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: 

what-can-data-center-saml-do

  • 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 powerfulHowever, 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 3Do 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. naming-convention-saml-1

But if the answer is yesit 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. naming-convention-saml-2

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.  naming-convention-saml-3

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.  options-for-saml-resolution

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) multiple-identities-saml-1

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. multiple-identities-saml-2

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 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. deactivate-users

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 answersblog_sso-pt3-2

As you can see, there are three main possibilities: 

  • If you don’t have any of the requirements listed in questions 3 thru 6then 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. blog_sso-pt3-3

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

spot-the-difference-resolution

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! 

Topics: blog saas security support collaboration data-center resolution
4 min read

How is Confluence Cloud different from Server/Datacenter?

By Morgan Folsom on Dec 18, 2020 1:06:00 PM

Blogpost-display-image_How is Confluence Cloud different from Server-Datacenter-

If you've recently moved from a Confluence instance that was hosted by your organization to one on Atlassian's cloud, you may be noticing some differences in how the tools work! The experience is quite different, and we know that can be a bit overwhelming if you've spent a lot of time getting used to the server UI. The change will require some adjustments, so we've provided a quick overview of things to keep an eye out for so you can get back to expertly collaborating with your team.

Navigation

Let's start with getting to Confluence! You can of course access your instance via the new link provided by your IT team https://yourcompany.atlassian.net. But, if you're looking to get to Confluence from your linked Jira instance, the application switcher looks a little different. The application switcher now lives in the grid icon(Screen Shot 2020-04-17 at 11.09.36 AM). Select that and you can navigate to any linked applications, including Confluence. 

Creating pages

Page creation looks different in the new view - you'll notice that there is now only one option to create pages, the Create button. This functionality has made it a lot more intuitive to create pages from templates! In Server, users need to consciously make the decision to create from a template (selecting the '...') or a blank page. Now when creating pages available templates will appear on the right, allowing you to filter and search through templates. With this new navigation you can even see previews of the templates before you select them. 

Keyboard shortcuts

This is the change that threw me off the most when switching between the products, because I rely very heavily on shortcuts! Here are three that I use a lot that have changed:

Action
Server/Datacenter
Cloud
Insert a Macro { /
Start an ordered list 1. 
Change header level Cmd/Ctrl + 1/2/3... # / ## / ###

 

To see a full list of shortcuts, you can select Cmd/Ctrl + Space while editing a page and a dialog will appear and display all of your options. 

Page layouts

The experience in Confluence Cloud is more mobile friendly, so pages are more narrow by default than previously. However, you can still expand your pages to span full screen if you've got a lot of content. Opening the page layout options hasn't changed - you select the icon in the editor. However, the page layout editing experience has changed so you can work on it within the body of the page, instead of at the top.

Screen Shot 2020-04-17 at 11.24.48 AM

You'll notice the arrows pointing out - those allow you to span full screen for either the entire page (top) or the specific section (bottom). The same options to edit layouts are available but you can see them in-line instead, which makes for easier navigation while working them into your pages. 

Panels

The Panel macro is one of my favorites - I like the ability to break the page up visually, and they are a great way to do that. Atlassian has revamped how panels work in Cloud so that instead of having separate macros for different types of panels: Panel, Info, Warning, Note, Success, etc. they are all just one macro, and you can switch the coloring as needed by selecting different icons. 

Screen Shot 2020-04-17 at 11.28.05 AM

Macros while viewing a page

The last change I want to highlight is perhaps my favorite. When editing Confluence previously, you might've noticed that when you insert macros, many of them appear different while editing vs. viewing the page. In cloud, we now see that macros like the Jira Issues macro pictured below actually shows the content while editing now. 

Screen Shot 2020-04-17 at 11.31.30 AM

Switching between tools or views can be tough, but with Atlassian's cloud platform you'll see a lot of changes that make the user experience run more smoothly. Now you've seen some of the changes, you're ready to hit the ground running!

Thinking about switching to Cloud? Contact us to talk about how we can help!

Topics: jira atlassian migrations server cloud data-center confluence-cloud
5 min read

Q/A: Best Atlassian Deployment Options for Your ROI

By Kristopher Hall on Feb 1, 2017 11:00:00 AM

In two recent studies*, 86% of IT organizations are concerned about delivering value to their organization and 80% of an IT department's budget is used in Keeping the Lights On (KTLO). As such, IT organizations are focusing more on the right ways to keep their applications happy and healthy. One of the most important decisions an IT organization can face is how to host their Atlassian applications. Depending on resources, experience, and budget, the best choice may not be obvious at first glance. There are pros and cons of each hosting method. The question to ask is where do you find the most value when considering each option? Maybe the IT organization is new (or the company is new) and is looking for a hosting option that will take little-to-nothing to spin up and maintain. In this case, Atlassian Cloud may be the perfect fit. But what if you have a large employee headcount and access to experienced IT resources and increased funding? Maybe it makes sense to host internally to maintain complete control or, for a more hands off approach, off-loading the maintenance and performance responsibilities to someone else. That's where Praecipio Consulting can assist by offering Cumulus, our Managed Hosting platform. As Atlassian Platinum Solution Partners, we take on the responsibility of maintaining your system and are on call for your Atlassian needs. Where do you find the most value in your particular case?

What is the best return on investment for hosting?

The answer is: it depends.

 

1. What are the hosting methods and what are the pros and cons of each?

 

Atlassian Cloud

Pros:
  • You let Atlassian manage your system as SaaS (Software as a Service).
  • No upfront hardware costs.
Cons:
  • No access to database or operating system.
  • Some features that are present in Atlassian server products may not be available in Atlassian Cloud.


Internally Hosted (Server)

Pros:
  • Full range-of-motion on the entire application and operating system. You are the admin.
  • Personally dive into the application and get to know its inner workings.
Cons:
  • Whether you’re building on top of a virtualized or physical system, you’re going to run into hardware costs and the maintenance fees that hardware brings with it.
  • Time away from your team to keep that system up, running, and configuration changes when needed.
  • Performance tuning can be a daunting task.

Praecipio Consulting Managed Hosting

Pros:
  • More customization than Atlassian Cloud allows.
  • Atlassian Platinum Solution Partners manage your instance and performance tune for you.
Cons:
  • Some features will be present to Cloud first before they are released to Server.
  • No control over file or database structure.

2. What does it take to migrate to a different hosting method?

Each hosted method is little different to migrate to. If you’re migrating to cloud, it’s preferred to migrate via export (if it’s not a huge instance). If you’re migrating to a server you could migrate with the above method or you can take a backup of your database and move over your data (attachments, logos, etc) to the new server. Praecipio can help you out if you’re looking for a seamless transition.

3. What kind of database should I use?

Although you can use MSSQL or MySQL, it's PostgresSQL that Atlassian deems as its preferred database. PostgreSQL also allows for an easy move to datacenter Atlassian products as PostgreSQL is able to be turned into a database cluster, a functionality that MySQL is not capable of. You can make a MSSQL cluster too, but it comes with high licensing costs.

4. What is the trickiest migration Praecipio Consulting has taken on? What made it tricky?

We had a client that needed to migrate various applications. During this migration they needed to conform to a new username and email standard associated with the parent company. What made this tricky was you couldn't manually change this easily since there were thousands of users; you'd waste a lot of man hours and downtime making a change like that. The change had to be automated to modify each user in each application with various different places in the databases being updated with the new user values. This was to ensure that you kept all the users historical data intact and the user could come back into work after the migration, use his new account to log in like nothing happened.

5. What is the cloud user license limit?

Atlassian Cloud's user limit is 2000 for licenses. If you have a 2000 plus user count your options could be multiple Atlassian Cloud accounts or the Atlassian Server products that you'd manage internally or through managed hosting.

6. What is the storage limitation on cloud?

Atlassian Cloud has another limitation that you should be aware of. Cloud has a storage limitation. If you have a user count below 500 users you're looking at a overall storage limit (across all applications on your account) of 25GB. If you're over the 500 user count, you've expanded that limit to 100GB.

7. Between Jira and Confluence, which is more difficult to migrate from Server to Cloud? 

When performing a straight migration, Jira and Confluence are just about on equal footing on complexity to move to Cloud. Now, if you are merging two applications, that is a different story. Jira is a lot more complex to merge than Confluence due to the amount of variables that Jira has to have in place, like workflows, issue types, fields, notifications, etc. The list is long and you have to make sure the structure is there before you can merge your data. Additionally, merging data must be done from server to server. So if your end goal is to be in the Cloud, you have to merge all your instances to a single server and migrate that up to the Cloud.

8. Why should I consider Data Center if I don't have a performance problem?

One of the main reasons to consider Data Center is uptime. Data Center has multiple application nodes that you connect to through a proxy. If a node goes down due to a hardware issue, guess what? The proxy connects you to the next available node so that you don't even realize there has been an outage. To take complete advantage of the high availability perks of Data Center, you would also incorporate a database cluster. The same rule as before comes into play. If you lose a database server in the cluster, you're still up and running. You could even lose database servers and applications nodes at the same time and still have your environment up and all users working. Granted, there are at least one application node and database node up at the same time.

9. When doing a migration or merge - do you recommend having a staging environment to cutover from (as opposed to going straight from production to production)?

Usually it's not that necessary to have a staging environment to cutover from. Actually it's preferred to do the entire migration while the current production instance is off so that no one can update it to avoid anything becoming out of sync. What should be done is preform the entire migration/merge in a test environment and list out the steps that a needed to perform that migration. As long as any extensive configuration changes are not being made those steps are going to pan out the same no matter what data is actually included into the application.

10. How difficult is it to change the OS? For example, Windows to Linux?

Surprisingly, it is not as difficult as you might think. Most of the time it acts as any other migration. The thing that will usually cause problems is if you have something tied into you Atlassian application that is dependent on Windows or Linux to run correctly, a plugin for instance. The application itself can be installed and the data moved over without much of a headache.

 

*Source: HDI, “Service Management, Not Just for IT Anymore”, 2014
*Source: Gartner, “Eight of Ten Dollars Enterprises Spend on IT is “Dead Money”, 2015

Topics: atlassian blog managed-services migrations cloud data-center hosting
2 min read

Big News From Atlassian

By Praecipio Consulting on Sep 25, 2015 11:00:00 AM

Atlassian Reaches 50K Customers

Since their founding in 2002, Atlassian has disrupted the tech industry with their innovative products. Focusing on collaboration, integration, scalability and efficiency, Atlassian continues to change the way companies do business as we move more and more towards a global business model. Because of Atlassian, teams across the world can work seamlessly and in real-time on projects no matter where people are located. They've build products that not only keep up with the needs of today's industry leaders, but they are themselves industry leaders (reflected in their ever-growing Gartner rating). It's with that forward-thinking and must-have product suite that Atlassian has reached 50,000 customers! As Atlassian Solution Partners, we at Praecipio Consulting love nothing more than introducing these products and their capabilities to clients who enthusiastically adopt them with great success. We've seen first-hand how Atlassian brings the best in IT and business process solutions to companies of all sizes and industry, from the dev teams to the marketing teams, and could not be more excited to see what they will come up with by the 100,000 customer mark. 

 
Image courtesy of Atlassian

Meet The Newest Bitbucket Addition

One great example of Atlassian's cutting-edge innovation? Bitbucket! The Git repository that 1 in 3 Fortune 500 choose to help build and ship software is getting even better with the addition of Stash (now Bitbucket Server) to the product family. Now, dev teams have their choice of Bitbucket Cloud, Bitbucket Server (formerly Stash) and- for those with loads of code- Bitbucket Data Center. As more companies switch from Subversion to Git for their source code needs, Atlassian has developed the Bitbucket line of offerings to bring the most desired features a dev team could want: Git mirroring, large file storage, organization ability by project and more CI capabilities. Development teams love how Bitbucket helps them up their game and work smarter and faster, releasing better products with even greater ease. Among the biggest fans of Bitbucket is Splunk, an industry-leading operational intelligence company with a huge need for code storage and scalability. Check out what the folks at Splunk have to say about Bitbucket and how it's changed their way of doing business (for the better)!

Video courtesy of Atlassian

Get Some Atlassian in Your Life

Companies are moving to Atlassian everyday for a way of doing better business. Will you be Customer #50,001 (or #50,002, #50,0003...)? Praecipio Consulting can help! Contact us to learn how we can deliver custom solutions fit for your company with Atlassian and see why it's the top software choice of major companies worldwide. 

Topics: atlassian blog bitbucket continuous-integration data-center
1 min read

Stash in the Enterprise: Meet Stash Data Center

By Christopher Pepe on Sep 17, 2014 11:00:00 AM

Atlassian shot into the Enterprise with the release of their revolutionary JIRA Data Center in July, followed by Confluence Data Center in August. Major companies worldwide relying on Enterprise-level, mission-critical processes rejoiced- and now, they have even more reason to celebrate! Now Stash, the popular source code management for Git, is the newest Data Center offering from Atlassian. Currently in its beta version, the first and only platform of its kind to provide a highly available, scalable solution to collaborative Git teams of unlimited sizes with countless products and processes, Stash Data Center brings optimal uptime, the utmost reliability and unlimited scalability. It's only been a week since Scott Farquhar and Mike Cannon-Brookes introduced us to Stash Data Center in the Opening Keynote of Summit, but the IT community is already buzzing over the newest addition to the Atlassian Enterprise family!

Let's meet Stash Data Center!

AVAILABILITY

Using active-active node clustering, your Stash instance is always up and running! Should a node go down, the load balancer distributes the processes of the failed component to keep your workflow moving and kick off node repair. Once the node is fixed, Stash Data Center automatically updates your data with rapid re-indexing so you never miss a beat.

SCALABILITY

Whatever size your instance, Stash Data Center scales to your needs. The platform ensures your Git repository can be accessed quickly, efficiently and at all times- no matter how many users and functions are running concurrently. Have more data than you can handle? Just add another node to your instance to help share the load

SECURITY

Control who has access and permissions within your Git repository with Stash Data Center's robust security options, as well as customizable workflows to get the right code to the right people. Operating on premise and behind the firewall and using global, project, repository and branch level permissions, Stash Data Center provides the safest way yet to run mission-critical Git processes.

Atlassian thrilled new and existing users across the world with their six big product announcements and Enterprise teams everywhere cheered over Stash Data Center! 

Topics: atlassian blog atlassian-summit best-practices bitbucket enterprise reliability repositories scalability uptime data-center git high-availability atlassian-products

Praecipio Consulting is an Atlassian Platinum Partner

This means that we have the most experience working with Atlassian tools and have insight into new products, features, and beta testing. Through our profound knowledge of Atlassian environments and their intricacies, we can guide your organization as you navigate these important changes.

Atlassian-Platinum-Solution-Partner

In need of professional assistance?

WE'VE GOT YOUR BACK

Contact Us