Enterprise User Management for the Atlassian Ecosystem
Last updated 06/01/2020
Is there an enterprise solution for the endless forgotten passwords? This white paper extends industry best practices to Atlassian applications.
Summary
This white paper firstly explores how the speedy adoption of business technologies is placing unprecedented pressure on user-driven security threats; how the use of passwords is the weakest link in the security chain; and what are the most important recommendations to mitigate risk, with SAML Single Sign-On as the main solution.
Secondly, it explains how these industry trends impact Atlassian applications, what are the defects in the out-of-the box Atlassian single sign on capabilities, and how the advanced features required by most Enterprise User Management Strategies can be found in resolution’s low-cost/high value plugins (or, as we say in the ecosystem, Atlassian Marketplace apps).
The resulting framework, illustrated with four case studies, will generate sustainable and widespread business efficiencies while diminishing risk in the Atlassian suite.
1. Overview
Managing Users in the Atlassian Context
Depending on the specifics of a given environment and the architecture that sustains it, Atlassian User Management often involves a lot of manual effort across a multitude of systems.
Removing a user can’t be that hard, right?
Well, it is a bit of an effort when a multitude of systems are involved and there is no centralized user management. Imagine removing a software developer who has quit the company from Jira Software, Confluence and Bitbucket. For each Atlassian application, the administrator must:- enter each application
- reach the admin section
- navigate to the user management options
- find the user
- remove the user
- If the user had a responsibility role, like a project lead in Jira software, they must also be replaced.
In addition to this, the employees will also have to be removed from any non-Atlassian systems that are involved in software development like AWS, code review software, etc.
The growing number of systems and users in enterprise deployments of Atlassian tools together with the sheer amount of interactions between software systems require an aligned strategy to handle existing and upcoming workload.
- Employees reuse and share passwords
- Admins struggle to manage dozens of user databases across a multitude of products
- complexity keeps accelerating in a hyperconnected business landscape.
- Third-party integration and automation platforms such as IFTTT, Zapier, or automate.io, are being adopted to accelerate processes and multiply business opportunities.
Because they often need to integrate into Atlassian products and act on behalf of human users, their decentralized usage can result in unacceptable vulnerabilities. All of these factors lead to constant distractions for administrators, with 10 to 30% percent of the capacity of Help Desks occupied only with requests for password recoveries. Effective and easily adaptable user management processes are necessary to help mitigate this “productivity blackhole” and secure the corporate stack against cyber risks.
2. Industry Trends & Challenges
2.1 Industry Challenges
Employees need to manage too many passwords; 191 on average. And the proliferation is exponential, with the number of accounts doubling every five years. Many of those passwords are insecure because they are simple, shared with other people, noted without *encryption or reused for multiple accounts –up to 13 times in average. Users that create passwords following best practices have a difficult time managing them because of the sheer amount of app accounts used.
Are employees solely responsible for poor password hygiene?
Nobody can handle 191 unique proper passwords. Consequently, password resets create stress and waste time for both employees and the IT support teams involved. Most companies try to solve this stream of non-valuable work with employee education; however, efforts based on training are unlikely to prevent damages. In 2019, 81% of confirmed data breaches occurred because of password weaknesses.
The widespread use of cloud apps makes the password issue even more critical because many employees use their credentials to create unauthorized connections between corporate & third-party applications with the objective of automating tasks, creating custom notifications, or optimizing workflows. Although they derive from good intentions and usually increase business productivity, these connections represent the most extended case of *shadow IT and a permanent security threat, as credentials are regularly transmitted to external parties.
Warning
In many cases, connections made by unqualified users can go entirely unnoticed to IT departments. Sometimes, they only become apparent when they cause entire corporate databases to sync with external applications – an event that can be identified in real time by monitoring or in hindsight by audits.
While the technological state of the art may be years away from making passwords obsolete, this is a mature problem with many industry standard solutions like Multi-Factor Authentication (MFA), single sign-on (SSO) and API tokens, which can mitigate the password strain and the security risks.
Jump to Section 4 for a comprehensive overview of how to implement these best practices across your Atlassian stack.
2.2 The Impact of Digital Acceleration
With the commoditization of enterprise software, virtually any technological business need has been turned into a product, exponentially multiplying the number of accounts and SaaS products employees have access to. But will the path of growth continue to accelerate?
If we look at the growth rate in the last five years, we can see that the curve is nowhere near its peak. Below are just some of the main drivers for digital acceleration expected to keep pushing the slope at the start of this new decade.
Drivers for digital acceleration
- Growing Customer Demand – Classic product and service lifecycles are disappearing. They are overwhelmed by the expectation to consume new products faster, all the time and together with the accumulated pressure of omnichannel services, saturated markets, and shrinking customer loyalty.
- Extended Enterprise – Corporations are creating new, comprehensive and faster value chains across company and country borders that are enabled by digital processes.
- Big Data, Analytics, IoT and the Era of Contexts – Data is the new oil: it generates insights on usage, durability and customer behavior. When the potential of the explosion in data sources is properly harnessed, processes can be optimized, new products can be more efficiently developed, managed and monitored.
- Hybrid Cloud IT Solutions and Infrastructure – Hybrid systems or multi-cloud solutions can avoid the disadvantages of siloed solutions and instead combine their networked advantages in modularly architected solutions. Special web applications & mobile usage increase the need for flexible, always available services.
- Mobile Technologies & a New Generation – The technically savvy employees of today and tomorrow can no longer be squeezed into classic work models. All industries are adapting to the changing needs of workers and offer new opportunities with the help of digital tools, pushing forward the reality of a global pool of talent.
The Growth of the Cloud Market Keeps Rising
Every major global industry is becoming software driven.
Companies are increasing the usage of additional applications installed on-premise, in private or on public clouds with impressive benefits in terms of personal productivity, increased effectiveness of existing processes or the launch of completely new business models. The growing cloud market and annually increasing IT budgets are only two indicators of these trends.
With more enterprise applications, there are more vendors, more external suppliers, more employee accounts and more data processors handling sensitive information for every company. Furthermore, the pace at which new software solutions and platforms are onboarded has grown exponentially over the last decade and will continue the same trajectory for the foreseeable future.
2.3 The Growth of Shadow IT
In this context, every employee is a potential system administrator that can empower her small team while expanding the bad habit of shadow IT. This creates new challenges for CIOs, IT departments and security experts: the company-wide or personal benefit of additional tools is often contrary to security manageability and proper risk assessment. As a simple example, a large percentage of the 70 million logins hacked from Dropbox in 2012, when the cloud-first paradigm was just starting, corresponded to corporate accounts.
3. The Password Problem
3.1 The Risks of Passwords
Passwords gate access to all these new systems, but they have become very impractical.
Warning
When every employee manages an average of 191 accounts, unique passwords tend to disappear, giving place to reused, recycled and simplistic passwords —a problem that can be particularly aggravating in the absence of password management tools.
Warning
An additional risk is posed by the *privileged accounts that many companies and users create to handle advanced administration tasks like integrations with third-party apps, domain creation and disaster recovery. These accounts have important peculiarities:
- They can be found on network devices, databases, on-premise & cloud services, applications, workstations, servers, and social media accounts.
- Full rights are often associated to them, including access to sensitive data and systems.
- Shared usage among multiple administrators or team members effectively creates an anonymous or difficult-to-identify user.
- Activities performed by these accounts are seldom monitored, logged or audited.
*Privileged accounts have so much power that they attract attackers like crown jewels: once a hacker gains access to one application or computer, they can move onto additional resources and sensitive data that can cause significant business damage. This problem multiplies when *privileged accounts are used for external services to create integrations, and credentials are stored in the third-party database, sometimes without *hashing (*cleartext).
3.2 Mitigation Recommendations
555,278,657 real-world passwords have been exposed in data breaches
We recommend
While the human factor should not be downplayed, the password problem can be addressed by following 4 main mitigation recommendations:
- Have fewer, but stronger passwords
- Combine SAML Single Sign-On with Multi-Factor Authentication (MFA)
- Create a proper and up to date user directory (onboarding, changes, offboarding processes)
- Limit privileges for administrative resources like API connections to 3rd Party apps
3.2a Single Sign-On as Enterprise Wide Single Identity
Federal authorities like the US National Institute of Standards and Technology and the German Bundesamt für Sicherheit in der Informationstechnik have removed the recommendation for the classic 90-day change interval. Microsoft has also removed password-expiration policies in their Security Baseline. The main reason is to recognize the human factor and the sheer number of passwords.
If the objective is to have fewer passwords, the ideal scenario is one in which every employee only has one extremely secure password. But how can that be achieved without reusing the password everywhere and exposing it to potential leaks?
The answer is single sign-on.
The 3 reasons why you should have fewer, but stronger passwords
- The more passwords users have to remember, the more often they will reuse and share the same weak password for different services.
- Passwords are sometimes sent over insecure networks or third-party applications, which makes them easy to steal.
- The more passwords (accounts) that exist across different applications, the less likely they will be removed by IT Admins when employees leave the company.
- The use of unlimited apps is enabled with a single password
- Employees don’t experience the friction of having to authenticate to each account individually
- The password is only known to the user and the IdP, and remains unknow to third parties.
SAML SSO in the Atlassian On-Prem Ecosystem
- 2 Factor Authentication
- Audit logs
- *Active Directory Sync
- Authentication Tokens
Unfortunately, there is no comparable subscription to Access for Data Center applications, which are limited to basic authentication and provisioning. Go to section 4.2 for more details
3.2b Combine SSO with Multi-Factor Authentication (MFA)
Multi-Factor Authentication (MFA) or two-factor authentication (2FA) is a great way to ensure that your account is as difficult to compromise as possible.
Over 99% of data breaches can be avoided with 2FA or MFA authentication
It is important to implement an MFA solution which is practical for employees. Imagine deploying an MFA for each of the 191 passwords users have to manage: security would certainly increase, but so would frustration, productivity loss and the time spent logging into services, while the use of non-critical applications would plummet. This siloed approach is clearly counterproductive.
The combination of MFA and SSO is an excellent solution that minimizes the usability vs security trade-off: while MFA secures access ensuring that hacking a password is insufficient in order to authenticate, SSO keeps the password within the walls of the Identity Provider and extends the safety net of a single high-end MFA login to all services and apps linked to the IdP.
In the Atlassian Ecosystem, a typical deployment of MFA combined with SSO would consist of an IdP that supports MFA or 2FA, like Okta, + resolution’s SAML Single Sign-On to collect Atlassian applications under the hood of the IdP.
3.2c Centralize Identity & Access Management (IAM)
The growing number of internet-accessible services & apps is too large to manage user accounts in silos: what’s needed is a centralized, well-maintained and accurate user directory. An *Identity & Access Management framework (IdAM or IAM) can solve this limitation with a combination of policies and technologies, including Identity Providers.
A comprehensive IdAM framework must ensure that:
- The digital identity of employees is managed considering all steps of the lifecycle, including creation and deletion;
- Users can log in based on their digital identity;
- Resources are accessed only by the users that need them, so that critical information is not generally accessible;
- User identity is federated, so that services can authenticate users without their password.
Some identity and access management products provide role-based access control, allowing system managers to regulate access to systems and/or networks based on the roles of individual users within the enterprise.
The primary reasons to implement IAM solutions are business facilitation, cost containment, operational efficiency, IT risk management and regulatory compliance. IAM also ensures a secure access control infrastructure.
- Extend single sign-on to business applications;
- Create, edit and deactivate users in a single source of truth;
- Create application users with the specific access for the role;
- Run user licensing efficiently, as accounts of former employees won’t consume active licenses.
Identity providers are quintessential to enforce IAM frameworks while minimizing the manual operations of adding, moving or changing users. All these effects need to be included in the business case for user directory management systems.
IAM in the employee journey of Jira
A powerful illustration of the benefits of centralizing IAM is to imagine the journey of an employee: in absence of a centralized framework, administrators must create one user account for each service, for a total of hundreds of repetitive tasks. Since errors happen and administrators are busy, the employee may not be able to access Jira immediately, request support and delaying the onboarding time.
If Jira had been connected to an IdP, the creation of the new employee’s user identity would have immediately propagated to it, granting access to all needed groups – and to no more. With User and Group Sync, every change in the employee’s situation will be immediately reflected in Jira. It might also be that in the new position the employee will not be a heavy user of Jira anymore, in which case User Deactivator can deactivate the employee account, thereby removing access to work she no longer owns.
3.2d Gatekeep API Connectivity
By 2022, the largest source of data breaches will arise from APIs. APIs are the new Shadow IT because developers are exposing APIs without alerting their IT teams of the risks and vulnerabilities, creating security hazards faster than IT and security teams can identify.
Very often regular employees can use their accounts and passwords to create API connections to external services, scripts and applications to read and write information, while creating on the fly integrations.
Warning
While the advantage of API connectivity is to obtain business results faster, the disadvantages are numerous: security risks, vulnerating data processing policies and laws like GDPR, but also potential inefficiencies due to faulty, uncoordinated or redundant execution.
These risks are particularly salient in automation services like IFTTT, Zapier, automate.io and many more that specialize in offering easy to build, no-code platforms to create integration workflows between corporate applications, like for example a CRM like Salesforce and a marketing automation tool like Hubspot.
Atlassian products are very often involved in this type of connections (see for an illustration the Case Study on section 5.3). Very commonly, the connection is authorized with the user credentials, which are then stored in clear text (that is, unencrypted) in the cloud database of the automation platform. This is a security issue for your company.
But the problem has already been solved for some Atlassian products: thousands of developers using Bitbucket Server for git operations substitute their password with personal access tokens, which “are a secure way to use scripts and integrate external applications.”
Although Atlassian doesn’t provide personal authentication tokens for Jira and Confluence, these can easily be added with the resolution suite even in the absence of a single sign on solution. See section 4.4 for more details.
We recommend
API connections need to be centrally controlled by roles who can track every relevant aspect, including the following:
- Data Security
- Database Security
- Operating-System Security
- User *Provisioning
- Identity Administration & Security
- Legal obligations
- Audit Trails
4. IdP & SSO in the Atlassian Environment
Identity Providers (IdPs) are pivotal in single sign-on solutions: they create, maintain, and manage identity information while providing authentication to relying applications and services. Most companies already use an Identity Provider like Microsoft Azure AD for Office 365.
This section will focus on the major identity providers and single sign on solutions as well as on the preparation required to properly select an Identity Provider, plan its implementation, and supplement it with the additional SSO products required to effectively connect your Atlassian tools.
4.1 The SSO implementation Checklist
Single sign-on technology has a solid position in the future of the cyber age because of its balance between security and usability. Follow these steps to select a single sign-on solution with the greatest benefits for your Atlassian environment.A. Indicators that your Enterprise Needs a Single Sign-On Solution
Whether your enterprise is completely lacking SSO capabilities or already has some in place that don’t extend to Atlassian applications, the following are clear warnings that you should break with the status quo and move forward to solve the problem.
B. Inventory Your Identity Resources
Enterprise User Management is all about centralizing resources and processes. Follow these steps to get a full picture of your current resources that will inform the scope of your project:- Step 1: Create a complete catalog of web applications
- Step 2: Audit your current source of users
- Step 3: Assess the Identity Provider
C. Research the Initial Scope of Your Project
Once you know all your current resources, you are ready to start researching exactly what capabilities you need to cover and how much of the SAML standard you want to implement. Try to answer at least all the following aspects, and you’ll have a comprehensive scope of your project:- Basic user access scenarios
- Is the device login connected to SSO?
- Native SSO support of applications
- Username transformations
- Multiple Identity Providers
- User *Provisioning
- Additional Challenges
D. On Premises vs. Cloud Solution
The choice of on premises server installations versus cloud deployments has numerous ramifications. Make sure to include budgeting, maintenance, compliance and compatibility considerations in your choice.
4.2 Atlassian SSO across hosting options
Atlassian applications’ single sign-on functionality is dependent on their hosting:
- Server is the traditional, on-premise packaging of Atlassian products, and does not have any SSO capabilities natively. However, this can easily be added with resolution’s SAML SSO Marketplace app
- Newer Cloud applications were developed in an API-first technological environment, and support SSO via SAML or *OAuth through *Atlassian Access.
- Data Center has basic SAML SSO authentication with the inclusion of the free DC SAML SSO app in the Atlassian Marketplace. However, application access and any required *authorizations, such as ensuring that users belong to the appropriate groups/roles and have the necessary permissions, must be configured in the user directory and/or the application itself.
4.3 Atlassian Data Center: SAML SSO deficiencies and how to supplement them
While some corporations with a clear cloud approach have embarked on Atlassian’s cloud offering, Atlassian leadership has pointed at Data Center as the promised land for enterprises with a need for performance at scale. Unfortunately, the SAML SSO capabilities of Data Center are limited.
Keep in mind
All of the following 4 criteria must match for Atlassian’s native Data Center SAML SSO to cover the requirements of your Enterprise User Management Strategy:
- Only one identity provider exists;
- Users can be synchronized via *LDAP;
- usernames are identical at e.g. Jira & identity provider;
- no advanced features like *encryption, *single logout, or attribute mapping are needed.
resolution’s SAML Single Sign-On delivers a single sign-on solution for Atlassian apps with your existing identity sources. In addition to being extremely easy to install, deploy and manage, resolution provides outstanding technical support (4.9 / 5.0) and ordinarily walks Atlassian administrators through the initial configuration process. As a result, the product solves virtually any SSO scenario with Atlassian tools in Server or Data Center deployments. SAML Single Sign-On is a robust and comprehensive solution that works not only in the Atlassian SSO scenarios above, but many more.
The table below summarizes some of the most important enterprise needs, and the features that address them.
Enterprises who have solved their SSO authentication thanks to the Data Center SAML capabilities can still benefit from User and Group Sync capabilities in its packaging as a separate app to create users in the Atlassian application through the API and even before those users log in for the first time.
An Evaluation from a Real Customer
What criteria do customers consider when evaluating alternative solutions to connect their Identity Provider with their Atlassian tools?
Keep in mind
The table below presents the results of an evaluation conducted by a real customer. While price was pulled into the equation, it had a secondary weight: compliance requirements, support, and the knowledge base were more important.
This customer evaluated resolution’s SAML SSO for Jira; two competing Marketplace apps, which scored lower for both internal support and the required features; and Microsoft’s free Azure AD SSO for Jira, which is unsupported and only provides the most basic SSO features.
resolution came on top despite its higher price point thanks to the combination of its rich features, which will cover virtually any enterprise use case, and its legendary support, which regularly helps customers set up their SSO environments, eliminating blockers to get the system up and running.
4.4 Industry Leading Identity Providers
Below is a feature comparison of the leaders in the Identity and Access Management space. We have chosen to exclude G Suite and JumpCloud from the comparison as they are both lacking in many of the major features, although they are growing quickly and have a promising outlook.
To evaluate alternative Identity Providers, consider first how each of them covers the specific requirements of your existing infrastructure. The connectivity to your Atlassian applications is granted for all of them through resolution’s SAML SSO.
Below is a more detailed evaluation of the strengths and weaknesses of the major Identity Providers.
Disclaimer
resolution is in no form affiliated with any of the brands evaluated in this section. The reviews that follow are fair and accurate from our perspective, which derives from our own experience as SSO solution providers and from interactions with our customer base. The ease of configuration rating regards only our specific use cases.
Okta
| Pros | Support for mobile device management (MDM) and geographic zones make this a solid offering. Reporting functionality is much improved, particularly on a geographic basis. The ability to manage the flow of identity and attribute information between multiple identity providers is among the best in the category. Okta had various core acquisitions and announcements of improvements made, like Okta Access Gateway for hybrid deployments and Okta Hooks to add custom logic. |
|---|---|
| Cons | Consumer identity provider features are still in their infancy and authentication to on-premises apps requires expensive hardware. |
| Bottom Line | It is no surprise that Okta Identity Management is so well-respected in the identity provider arena: besides the fact that the feature list includes security policies that support mobile device management, geolocation, and the ability to integrate multiple sources of identity data, its user-friendliness makes Okta one of the top IdP solutions on the market. |
| Ease of configuration |  5/5 for the great documentation, clean UI and nice customer support. |
Microsoft’s Azure Active Directory
| Pros | Contextual and flexible authentication through conditional access rules, best-in-class integration with Windows Server *Active Directory. Airtight integration with Microsoft’s array of cloud services. Identity Protection allows for security policies based on big data and machine learning. |
|---|---|
| Cons | Some competitors are better integrated with third-party directories and SaaS platforms. Advanced reporting capabilities are only available in expensive premium pricing tiers. |
| Bottom Line | Microsoft’s Azure *Active Directory (AD) gets a leg up on its Identity-Management-as-a-Service (*IDaaS) competition due to its tight integration with Windows Server *Active Directory and Office 365. Azure AD also offers the lowest entry-level pricing for handling Multi-Factor Authentication, as well as advanced toolsets for managing both user identities and cloud services. |
| Ease of Configuration | 3.5/5 because, despite the great product, the UI can be confusing and support is virtually non-existent. |
Ping Identity
| Pros | Setup is relatively easy regardless of the type of connector used. API-oriented and developer-friendly platform, with a comprehensive app catalog for SSO purposes. Making app assignments to groups takes minutes at most. |
|---|---|
| Cons | SaaS *provisioning support does not even extend to Microsoft Office 365. Reporting capabilities are limited at best. |
| Bottom Line | Ping Identity has been a major name in the Identity-Management-as-a-Service (*IDaaS) arena for several years, but its PingOne solution is sorely behind the curve in some key categories. User *provisioning into SaaS apps is the most glaring weak spot, though not a complete absence. |
| Ease of Configuration | 4/5, missing a point for the poor quality of their documentation |
OneLogin
| Pros | Ease of usage, integration and implementation. *Provisioning into AD from HR services is the ideal scenario. Mappings help streamline user and role management. Proxy agents offer easy support for on-premises applications. Configuring email notifications is straightforward. |
|---|---|
| Cons | AD Groups are not synchronized. *Provisioning is limited to the highest pricing tier. No API protection abilities are included in the product. |
| Bottom Line | OneLogin sports a nice feature set, including risk-based authentication policies, integration with HR apps, and event monitoring platforms. It’s a well-rounded IdAM approach where the only real complaint concerns the management of groups. |
| Ease of Configuration | 4/5 for its ease of use and quality developer documentation |
G Suite
| Pros | Has strong role-based access control and role assignment policy definitions for administrators, extensive attribute-based *provisioning, delayed, activity-based deprovisioning as well as broad API and SDK support for inbound and outbound integration. Its user self-service is very user friendly. |
|---|---|
| Cons | Full AD synchronization requires two separate components: directory and password sync. Multi-Factor Authentication setup is less versatile and there is no meta or virtual directory. |
| Bottom Line | A solid and easy to deploy solution for small companies. Its integration to Google Suite apps makes it an ideal solution, however it lacks many of the advanced features of the other identity providers. |
| Ease of Configuration |  2.5/5 for the screenshot-less documentation, the confusing UI, and how often configurations can fail for no apparent reason |
JumpCloud
| Pros | Directory-as-a-Service that securely manages and connects users to their systems, applications, files and networks, it’s cloud-based and does not require on-premises hardware or software. JumpCloud is platform-independent (works on Windows, Mac and Linux) as well as hosting-independent (cloud-based, on premises, or remote), and supports a variety of protocols: *LDAP, SAML, RADIUS, SAMBA. |
|---|---|
| Cons | Unfortunately, no customer service is offered to free licenses, and there can be some hiccups along the way: function setups are not that user-friendly, the configuration of policies can be a headache… Additionally, access to logs is via API only, and while the service is platform-independent, it does lack substantial Mac and Linux policy configuration. |
| Bottom Line | All things considered, JumpCloud is an outstanding service. They have an incredibly fair pricing structure, excellent on-boarding technical support, and a great back-end management portal for Managed Service Providers (MSPs). Cloud-based directory services can be sort of intimidating, but JumpCloud has extensive wiki documentation to make it a fairly easy jump. With its flexibility, it still lacks scenario-specific features. |
| Ease of Configuration | 4/5 for its straightforward configuration |
4.5 resolution Enterprise User Management Apps
Led by SAML Single Sign-On (SAML SSO) apps, resolution has developed a suite of user management apps that keep your company secure while streamlining the user identification process in the Atlassian ecosystem.
This is a brief overview of the apps, the real customer demands behind them, and the different combinations of apps that are adding value to our existing customers.
SAML Single Sign-On
Compatible with Microsoft ADFS, Azure AD, Offices365, G Suite, OKTA, Salesforce, Centrify, OneLogin & more.
If a user logs in to one of its enterprise applications linked to your identity source, the user is automatically logged into Atlassian apps and vice versa. This creates a password-less user experience, improves IT security & IT administration efficiency.
| Hosting | Server and Data Center |
|---|---|
| Atlassian products | Jira, Confluence, Bitbucket, Bamboo, Fisheye |
| Features | Powerful enterprise features:
|
User and Groups Sync
User and Group Sync connects Identity Providers and Atlassian applications via Rest API, enabling proactive *provisioning and de-provisioning of users and groups on regular intervals (sync).
| Hosting | Server and Data Center |
|---|---|
| Atlassian products | Jira, Confluence, Bitbucket, Bamboo |
| Features |
|
| Standalone | The standalone app provides additional functionalities to both non-SSO or SSO solutions:
|
| with SAML Single Sign On | User and Group Sync is a built-in application for customers of resolution’s SAML Single Sign-On. In addition to the SAML *Just-in-Time Provisioning, User and Group Sync synchronizes users & groups from Microsoft Azure AD, Okta or G Suite automatically via API. Complex SSO requirements can be solved with the built in User and Group Sync features. A classic scenario is frictionless user adoption: New user logins to Jira happen automatically for the first time via SAML & iDP, while his profile data is synced automatically from the IdP via attribution mapping. |
API Token Authentication
API Token Authentication allows 3rd Party apps and services to be authenticated with tokens instead of username and password. You can optionally choose to disable Jira or Confluence built-in basic authentication with username & password for REST API connections to decrease shadow IT connections.
| Hosting | Server and Data Center |
|---|---|
| Atlassian Products | Jira, Confluence |
| Features |
|
| Standalone | API Token Authentication enables users & admins to better control and secure connections to other services & applications via the Jira/Confluence REST API. Each single token is used to authorize only one connection to an external service, so that it can be revoked (for example, if there are signs that the token has been compromised) without affecting any other connections. |
| with SAML Single Sign On | In SSO environments, normal users lose the power to set up useful integrations with other business applications on the cloud because they don’t have a password anymore. API Token Authentication allows administrators or users to set API Tokens per user and service to connect via API to external, on premise, and cloud services. |
User Deactivator
User Deactivator keeps your user directory clean of leavers and inactive users. Free up your inactive licenses with a complete set of features:
| Hosting | Server and Data Center |
|---|---|
| Atlassian Products | Jira, Confluence, Bitbucket |
| Features |
|
| Standalone | In no-SSO environments or whenever users are not deprovisioned into the Atlassian application in harmonization with the central user directory, User Deactivator can be a powerful tool to periodically clean the instance of inactive users and save users towards the license count. |
| with SAML Single Sign On | Our powerful SAML SSO features provide an enterprise experience and can create & update users. To complete the user lifecycle we provide a deactivation function with User Deactivator. This combination keeps your user directory automated and clean of leavers and inactive users. In comparison with User and Group Sync, which connects to the Identity Provider as the single source of truth, User Deactivator allows to maintain a lower number of users and clean those for example who might still be at the company but don’t use the Atlassian tools. In SAML SSO environments, deactivated employee accounts can be automatically reactivated when they try to login again, e.g. after parental leave. This removes much of the manual effort. |
5. Case Studies
5.1 University of Vienna (I): 50 Identity Providers for Confluence
Industry:
Higher Education & Research
resolution deployment:
SAML Single Sign-On Server with Just–In–Time Provisioning
Key benefits/features used:
Multiple IdP support and weighting.
Overview:
The University of Vienna operates a wiki platform based on Atlassian’s Confluence for a total staff of around 9,500 employees, including academic and non-academic roles. To encourage collaboration with other Austrian educational facilities, members of more than 50 affiliated institutions can use the Wiki platform.
The Challenge:
Grant access to the University of Vienna’s Confluence from over 50 affiliate institutions, each of them with a separate Identity Provider, without generating requests to create new users at the central resource.
The Solution:
resolution’s SAML Single Sign-On for Confluence connects the University of Vienna’s Confluence instance to Shibboleth Identity Solutions, their free, open-source Identity Provider. Users are provisioned on the fly using SAML-*attributes during login, while the authentication is handled via Shibboleth. To recognize user identities sourced at affiliate institutions, resolution rapidly developed a custom feature to import aggregated metadata containing all federated IdPs and creating and updating all IdP configurations simultaneously
The Results:
Users from all affiliate universities are granted access to the University of Vienna’s wiki without the need to request it, by simply using their existing credentials on the login page: new Confluence affiliate users are created just in time on the first session.
5.2 University of Vienna (II): User Provisioning in Jira Service Desk with Custom Sync Connector
Industry:
Higher Education & Research
resolution deployment:
SAML Single Sign-On Server + User and Group Sync + Custom Connector to Shibboleth
Key benefits/features used:
Automatic synchronization of user email accounts
Overview:
Vienna University’s Central IT Service (Zentraler Informatikdienst: ZID) rolled out Jira Service Desk as the central Help Center, with a special focus on handling new user and password requests and a general approach to solving any specific IT incident or problem.
The Challenge:
The email address of many Help Center requestors would eventually change from an external account to the university’s domain, and this had to be automatically reflected in the service desk so the communication with the customer could continue seamlessly.
The Solution:
resolution provided a custom developed version of its latest SAML Single Sign-On release that allowed to automatically acquire additional information about the requestor.
Specifically, the solution combined SAML SSO for Jira + User and Group Sync for Jira, which was used to effortlessly update user *attributes in Jira Service Desk with the most current information stored in Shibboleth during the SAML login process. A custom connector was developed in resolution’s plugin to connect directly to the University´s central database.
The University of Vienna provided a REST interface to fetch user data, so that the connector could retrieve the following user *attributes as a JSON file:
- Username
- Name (display name)
- E-mail address
The Results:
The custom connector for User and Group Sync enables transfer of user data from the central user administration (DB) of the University of Vienna, eliminating manual work related to account maintenance and accelerating response rates to users.
5.3 Global Insurance Firm: Employee Onboarding w/ SAML Single Sign-On & User and Group Sync
Industry:
Global 500 Insurance Firm
resolution deployment:
SAML Single Sign-On Server + User and Group Sync + Custom Connector
Key benefits/features used:
Automated *provisioning via API with added onboarding workflow for new users.
Overview:
All 20k employees must use the HR portal, powered on Jira Service Desk, for tasks like booking vacations, logging expenses, etc. However, the frequency is often so low that users keep forgetting their passwords, adding unnecessary stress on IT support staff while struggling to complete what should be a simple action.
The Challenge:
All existing and new employees are managed in AD FS, an identity provider that integrates with SAML SSO. However, Jira Service Desk and all other Atlassian applications on Server lack SAML capabilities.
The challenge faced by the company consisted of:
- seamlessly connecting the company’s *Active Directory to Atlassian applications
- *provisioning users for newly hired employees, independent contractors, as well as external contractors, since all of them are required to complete global compliance onboarding as well as department/role specific onboarding.
The Solution:
resolution’s SAML Single Sign-On allows Atlassian applications to function as *service providers that authenticate users via AD FS. The User and Group Sync shipped with the SAML SSO app provisioned users automatically via the API, even before any new hires or contractors log in to Jira. In addition to this, a custom connector was developed to build an onboarding journey for new users.
The Results:
When authenticated in AD FS, users can seamlessly enter the HR Portal in Jira Service Desk without logging in. Thanks to User and Group Sync, a Jira task is automatically assigned to new users –On the first login, new employees will see this initial task and be guided through a list of related tasks until they have completed the most essential onboarding activities.
At the same time, a secure and compliant security standard with centralized user management has also optimized IT resources and minimized password recovery calls.
5.4 Bank from the Netherlands: Business Teams using API Tokens for Enhanced Integration security
Industry:
Finance
resolution deployment:
SAML Single Sign-On for Jira & Confluence + API Token Authentication for Jira & Confluence
Key benefits/features used:
Creation of different authentication tokens for each API connection
Overview:
A Bank from the Netherlands has more than 10k users in Jira and Confluence, which are used on a daily basis for product planning, design, and documentation purposes. This financial institution was already using resolution’s SAML Single Sign-On apps to improve user experience and application security.
The IT team often received requests from business teams to integrate external applications with Jira or Confluence, for example to have an overview of all the Jira records in another application. Previously, these integrations were enabled with a generic account with high admin privileges. As soon as the username and password was provided to the application owners, it became their responsibility to keep it safe – the first measure being to use it exclusively for the purpose of using the REST API, avoiding any usage as a real login to Jira itself.
Challenge:
The generic account was seen as a concerning short-term solution, as the IT team couldn’t properly monitor that the application owner was effectively safeguarding the credentials and there was a permanent risk that privileged credentials could be used to login to Jira, exposing the password to potential attacks that would rapidly expand to all their other SSO enabled applications. If the threat were to materialize, the damage would be very substantial.
For that reason, the bank was interested in finding a way to secure information exchanges across systems while maintaining the ease of use for setting up the new API integrations business teams expected.
Solution:
With resolution’s API Token Authentication, IT teams can distribute API Tokens instead of username and passwords to integrate generic accounts. Since they are made up of 30+ securely generated characters, API Tokens are much more difficult to compromise. Moreover, they can be created per application, renewed from time to time or even restricted by IP-address.
Results:
What happens now if a token is compromised? Since tokens are generated per account and application, one token can be easily revoked without affecting any other integrations. In comparison, changing the catch-all *privileged account that was being used would have created general errors in all integrations.
6. Conclusion
We recommend
Four key mitigation recommendations can flip the password problem and avoid security breaches while increasing usability for onsite and remote Users:
- fewer but stronger passwords
- Single sign-on & Multi-Factor Authentication (MFA)
- established processes for User Add / Move / Changes
- limit privileges to use administrative resources like API connections to 3rd Party apps
Their implementation will typically combine several solutions with the challenge of creating a stable, permanent, and flexible system. Important aspects to be considered during the evaluation of alternatives include matching requirements, optimal fit between solution components, and being future-proof.
Resolution’s unique suite of Centralized User Management apps addresses every aspect of Atlassian enterprise configurations, being applicable to virtually any complex scenario thanks to a combination of feature-rich, easily extendable solutions and a team of excellent customer success professionals that guide customers through their implementation journey.
Thousands of IT-Administrators, IT-Security Officers, IT Directors, as well as CIOs and CTOs have already implemented their security strategy combining resolution’s SAML Single Sign-On, User and Group Sync, API Token Authentication and User Deactivator with their existing Identity Providers.
Parallel benefits like time-saving, fewer password resets on internal service Desks and an Access Management that reflects your company situation are strong arguments to start today.
Contact us to optimize your Enterprise User Management for Atlassian today.
About resolution
resolution is an Atlassian Marketplace Platinum Top Vendor based in Germany with 21 years of experience in network security and software development. As the leader for user management and password security in the Atlassian ecosystem, our apps keep your company secure while streamlining the user identification process.
With over 7 million users from 58 countries across the globe, the pioneer family of apps for SAML Single Sign-On have been joined by a suite of apps based on the requirements of our customers to upgrade their network security in addition to SSO. User and Group Sync, User Deactivator and API Token Authentication are but the latest additions to the family.
What’s behind our 4.9 satisfaction score?
We create software with enterprise quality that is easy to install – but that’s not enough for us. We have a commitment to excellent support, providing customers with expert guidance through the setup process, even during the evaluation period.
Some of our customers
Leading technology corporations, higher education institutions, as well as government agencies are among the many organizations that have adopted our solutions to maximize collaboration in their Atlassian stack while eliminating security risks.
7. Glossary
| Active Directory | First released with Windows 2000 Server edition, Microsoft’s directory services can be used to manage many different types of assets, including users and devices within a corporate domain. Using the Active Directory Federation Services (AD FS), that directory can be used as an identity provider for SAML 2.0 and other *SSO protocols. |
|---|---|
| API Token | Also called app-specific passwords, or personal access tokens in Atlassian Cloud, these long strings of random characters can be used to replace user credentials in basic authentication when connecting to a 3rd party application via API. The basic best practice is to use one token per 3rd party connection or script so that the token can be revoked in case of a security breach without affecting other applications. An additional security measure is to have granular permission schemes for the tokens so that attackers cannot escalate their access beyond the privileges of a particular token. |
| Atlassian Access | Atlassian provides its cloud customers with SSO capabilities with a software subscription that includes many advanced features, including *MFA, user *provisioning, audit logs, *API token control, threat monitoring, and more. |
| Authentication | Authentication is the way to identify someone or something. It uses various factors to check whether the identity is correct. Authentication technology provides access control for systems by checking the user’s login details for matching the login details in a data authentication server or in a database of authorized users. How authentication is used and works: User authentication take place within most human-to-computer interactions outside of automatically logged-in accounts and guest accounts. Authentication factors
Multi-factor Authentication Multi-factor authentication (MFA) is a security system. It uses several methods of authentication to verify the identity of the user for a logon or other transaction. It requires authentication from independent categories of credentials. It combines two or more independent credentials: what the user has (security token), what the user knows (password) and what the user is (biometric verification). Background: One of the biggest problems with traditional user ID and password login is the need to maintain a password database. Whether encrypted or not, if the database is captured it provides an attacker with a source to verify his guesses at speeds limited only by his hardware resources. Given enough time, a captured password database will fall. Adaptive Multi-factor Authentication MFA & Adaptive Authentication: What’s the difference? Adaptive Authentication is an advanced form of MFA. It uses the principles of MFA, but instead of issuing blanket procedures for everyone to follow under all circumstances, it issues challenges intelligently, instead according to a predetermined risk model. This allows an organization to apply exactly the right level of gateway security to each and every login request. What are the benefits of Adaptive Authentication? There are a variety of significant benefits that set Adaptive Authentication apart from traditional Multi-factor Authentication:
|
| Authorization | While authentication is about knowing who a user is, authorization is about checking what a user is entitled to do – and granting access and powers as a consequence of this. |
| Cleartext | In security jargon, a message that is not encrypted and therefore can be immediately understood by a human reader. See *encryption |
| Encryption | The transformation of a text that is transparent to a human reader into ciphertext with an encryption key. The aim is protecting the confidential information contained from unauthorized viewers that may intercept the message. See *hashing |
| Federated Identity Management | Strictly speaking, it is the arrangement that allows to link user identities across different organizations, establishing SSO capabilities for users belonging to any partner organizations for access to shared services. A more common usage of the term is to refer to organizations with multiple domains and identity management systems, where user identities must be linked in absence of a single source of truth. |
| Hashing | Differently to standard encryptions, a cryptographic hash function is not keyed and cannot be reversed. It converts any messages to a value called its hash. If the message is modified even just a little bit, the hash changes completely. Hash functions are always used in signatures. A digital signature is a value, usually attached to its message, that can be used by third parties to verify that that message comes from a certain person (the signer). |
| Identity and Access Management (IAM or IdAM) | A framework combining policies, processes and technologies with the aim of managing the entire lifecycle of user identities and their interaction with enterprise IT services, ensuring that every employee has timely access to the digital resources they are entitled to. IAMs are implemented to strike the right balance between adoption of mandated solutions and security of enterprise assets. |
| Identity as a Service (IDaaS) | A subscription-based cloud service that offers capabilities in the context of *Identity and Access Management (IAM), such as being as *Identity Provider for *SSO. |
| Identity Provider | In *SSO, a service that provides the centralized digital identity management. *Service providers delegate authentication to the identity provider so that users can experience a single login flow. |
| JSON Web Token (JWT) | Although JSON Web Tokens have numerous applications, some *Identity Providers use *OIDC and can issue them to users so they can prove to apps that their identity has been verified. An important benefit is that apps can check the *IdP verification key to verify whether the JWT is valid without contacting the *IdP directly. |
| Just-In-Time Provisioning (JiT) | A method for creating or updating users from the user directory of an application during the *SSO login process. When a user doesn’t exist in the service provider, just-in-time provisioning allows to create the user account at login; when user attributes have changed since the last login, they will be updated. However, Just-in-Time cannot de-provision users, as it only updates the directory when the user successfully logs in. |
| LDAP | Acronym for Lightweight Directory Access Protocol, an open protocol used to accessing and maintaining user directories in a client/server network over IP. LDAP is widely adopted to *provision and deprovision users, and although it can share passwords between applications, this use case does not amount to a centralized sign on, as the *service providers would be able to read the credentials. |
| Kerberos | Kerberos is an *encryption protocol employed in LAN enterprise networks to provide single sign on capabilities. Kerberos protects the authentication from insider listeners but doesn’t allow to connect to any local application via the internet or from other domains. |
| OAuth | OAuth is a delegated authorization framework designed with mobile applications and API connections in mind. The more complicated version 1.x is still used in Atlassian App Links. Version 2 is the gold standard in consumer-facing single sign-on technologies such as “Login with Facebook” and builds the basis for OIDC. |
| OIDC | Stands for Open ID Connect, an identity layer on top of the *OAuth framework combined with *JWTs to create a *SSO protocol. |
| Password fatigue | The cognitive overload resulting from the creation, usage, and maintenance of hundreds of different passwords in order to access digital services. The major moment of fatigue happens each time a user fails to authenticate and has to replace the forgotten password, frequently replacing the old combination for another that is easier to remember. This moment of fatigue alone is responsible for repeating the same password in different services, for maintaining the same password overtime, and for diminishing the average complexity and security of credentials. |
| Password Psychology | A sub-discipline of cryptography, password psychology looks at real user behavior to identify and understand what makes passwords memorable, with the final goal of increasing security by instructing users with mnemonic techniques to recall more complex passwords with less effort. |
| Privileged account | User account with higher privileges than an ordinary user, typically including access to confidential areas or to administration tasks. Privileged accounts may be generic and shared by a number of users with administrative roles. The discipline that enforces strict monitoring and control practices over privileged accounts is called Privilege Access Management (PAM), and is a sub-discipline of *Identity and Access Management. |
| Provisioning | The second capability provided by *SSO in addition to authentication, it consists in maintaining and updating the application directories of *service providers by referencing the information contained in the *Identity Provider. |
| SCIM | The System for Cross-domain Identity Management (SCIM) is a specification created in 2011 by the Open Web Fundation to exchange identity information between cloud applications via REST API. SCIM is designed to be compatible with the existing user management technologies, providing a common and easily extendable user schema. |
| Service Provider | In the context of *SSO, any third party that grants users with access to an application, and authenticates those users via the *Identity Provider. |
| Shadow IT | IT applications and infrastructure adopted at organizations without the approval and involvement of the IT Department. Shadow IT tends to be out of sight, difficult to identify, audit, and monitor, and therefore posing unknown threats and risks. |
| Single Logout | In the context of *single sign-on, the action of signing out that terminates the session in all open systems authenticated through the same *Identity Provider. |
| Single Sign-Off | See *Single Logout |
| Single sign-on | Single sign-on (SSO) is a user and session authentication service that authorizes a user to use one set of login credentials (e.g., name and password) to access numerous applications. SSO can be used by smaller organizations, enterprises, and individuals to mitigate the management of several usernames and passwords. How single sign-on works: Single sign-On is a *Federated Identity Management (FIM) arrangement and the use of such a system is sometimes called identity federation. *OAuth, the framework, enables an end user’s account information to be used by 3rd Party services, such as LinkedIn, without uncovering the user’s password. Some *SSO services use protocols such as the Security Assertion Markup Language (SAML) and *Kerberos. |
| User attributes | In a loose meaning, any values that are stored tied to the digital identity of a user. In a strict *SSO sense, any of the parameters about the user that an *Identity Provider shares with a *Service Provider using a SAML assertion. Typical examples are name-related attributes (first name, family name, username) contact details (phone, email address), or groups. |
| User Management | User Management describes the capability for administrators to organize user access to various IT resources like applications, devices, storage systems, SaaS services, systems, networks, and more. It is a key part to any directory service and is a basic security essential for any organization. User Management authorizes admins to monitor user access and on-board and off-board users to and from IT resources. Afterwards, a directory service will authorize, audit and authenticate user access to IT resources based on what the IT admin had dictated. |
| User Synchronization | As opposed to *Just-in-Time Provisioning (JiT), user synchronization is a method for provisioning users that creates new user accounts or modifies the attributes of existing ones independently of whether the user authenticates with the application. Its advantage over JiT is that it allows efficient deprovisioning, thereby removing users who no longer are granted access. Also, users can be mentioned and assigned tickets before they’ve logged in for the first time. A synonym for user synchronization is *Ahead-of-Time provisioning. |
