Enterprise User Management for the Atlassian Ecosystem
Is there an enterprise solution for the endless forgotten passwords?
This white paper extends industry best practices to Atlassian applications.
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.
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.
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.
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.
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.
2.2.1 The Growth of the Cloud Market Keeps Rising
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.
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.
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
3.2a Single Sign-On as Enterprise Wide Single Identity
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.
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.
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.
- 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
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.
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.
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
Multiple Identity Providers
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.
4.3a 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.
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.
|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.
|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
|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
|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
|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
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|
Powerful enterprise features:
User and Groups Sync
API Token Authentication
|Hosting||Server and Data Center|
|Atlassian Products||Jira, Confluence, Bitbucket|
|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
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.
resolution provided a custom developed version of its latest SAML Single Sign-On release that allowed to automatically acquire additional information about the requestor.
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
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.
|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 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.
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.|
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 (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.|
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.