Purpose

Organization Admins that have subscribed to Atlassian Access would like to have their Internal Customers/Users authenticate through SAML Single Sign-on and/or provision Customer Accounts in their Jira Service Management Cloud Sites

There are two types of Customer Accounts in Jira Service Management: 

1. Portal-only Customers
   1. These are Customers that you strictly view as a client and will only have access to login through the Portal URL: https://INSTANCE.atlassian.net/servicedesk/customer/ using their Email Address and 'local' password
   2. Portal-only accounts cannot utilize SAML Single Sign-on to login unless they're migrated to an Atlassian account Customer account and any/all Product Access removed so that they are not licensed in your Cloud Site - migration steps below
2. Atlassian account Customers
   1. These are customers that you may provide more licensed access to in the future
   2. These Customers are added to your Cloud Site like a Regular User but has no Product Access and then are granted Permissions to your Service Management Project(s)
   3. These customers can use SAML Single Sign-on to authenticate by logging in at https://INSTANCE.atlassian.net/ (like your regular users)
   4. If an Atlassian account Customer attempts to login through the Customer Portal, they'll be prompted to login through the Atlassian ID (https://id.atlassian.com) login
   5. Atlassian account Customers can be created with User Provisioning 

Solution

Allow a Customer to Just-in-Time create an Account in your Cloud Site and use SAML Single Sign-on for Authentication 

1. Navigate to your Cloud Site's User Management, update the Product Access settings and disable the New Users have Access to this Product options: 
   
   1. This will ensure that accounts that Self Sign-up in your Cloud Site are not automatically licensed and are treated as a Customer account
   2. If a New User needs Product Access, a Site-Admin will need to enable the Products for that individual User and/or Add them to the appropriate Group(s)
2. Go to the Site Access settings and Add Domains that are Approved to join without an invitation: 
   
3. Check your Jira Service Management Project's Customer Permission Settings and Verify if a Customer will have access to your Projects:
   
   
   1. If your Jira Service Management Projects are configured configured so that Service Project Access is Customers added by Agents and Admins
      1. An Agent or Admin will need to invite the Customer to the specific Project
         
      2. If you are using a modified Project Permission Scheme for your Jira Service Management Project(s), you may need to manage additional Project Permissions in order to grant access 
   2. If your Jira Service Management Projects are configured with Anyone with an account on https://INSTANCE.atlassian.net or Anyone on the Web  
      1. No additional changes are necessary; Customers will have access to these Projects as the Customer will have an account in your Cloud Site 
      2. The text of this option will vary based on your Jira Service Management Global Customer Permissions
         
4. Once these settings have been confirmed, a New Customer (belonging to your Verified and Approved Domain) will need to go to your Cloud Site Base URL (https://INSTANCE.atlassian.net) to Just-in-Time Provision an account; their login experience will be:
   1. User navigates to https://INSTANCE.atlassian.net and is redirected to the Atlassian ID login screen 
   2. The User inputs their Email Address and clicks the Blue Continue Button and is redirected to their Identity Provider 
   3. If the User successfully authenticates against the IdP (or has a cached session), they're redirected back to the Atlassian Website that initiated the login 

Create Customer Accounts via Atlassian Access User Provisioning

We recommend pushing a "Customers" Group from your Identity Provider into Atlassian; this will help with separating your Licensed Jira/Confluence Users from your Unlicensed Customers once they are pushed into your Cloud Site and help with updating permissions within your Jira Service Management Projects to grant Customers access 

By Default, Groups pushed into your Cloud Site via User Provisioning do not have Product Access; as long as your Customers are only members of unlicensed "Customers" Group (eg a Group that does not grant Jira or Confluence Product Access), they will remain a free Customer account in your Cloud Site:

Once your Identity Provider has pushed Groups and Members into your Cloud Site, check your Jira Service Management Project's Customer Permissions:

• If your Jira Service Management Projects are configured configured so that Service Project Access is Customers added by Agents and Admins

  • You'll need to update the Project's People/Role settings so that the Members of the Pushed Group (eg "Customers") have access to the Project as a Customer:

    

• • If you are using a modified Project Permission Scheme for your Jira Service Management Project(s), you may need to manage additional Project Permissions in order to grant access 

• If your Jira Service Management Projects are configured with Anyone with an account on https://INSTANCE.atlassian.net or Anyone on the Web 

  • No additional changes are necessary; Customers will have access to these Projects as their Atlassian accounts are created in your Cloud Site via User Provisioning

  • The text of this option vary based on your Jira Service Management Global Customer Permissions

Edge-case Scenario for JSM

There is a specific edge-case scenario in Jira Service Management (JSM) involving Single Sign-On (SSO) configurations between two organizations. This is expected behavior.

Scenario: Let's consider two organizations, Organization A and Organization B.

Organization A:

• Has SSO configured

• Does not have JSM SSO configured

• Allows external/non-managed users to log into the portal

Organization B:

• Has SSO configured

Expected Behavior: If at any point, the user's account changes from a Customer Account to an Atlassian Account, the user will be required to log in using Organization B's SSO. This is expected behavior since the user now belongs to an Atlassian Account that is managed by Organization B.

On the other hand, if the user remains a customer account in Organization A, they will not be required to log in through SSO. Instead, they can use local authentication methods provided by Organization A.

This means that depending upon the account type in Organization A, users from Organization B might either need to log in using SSO or use local authentication methods.

Analysis: In this edge-case scenario, the type of user account in Organization A directly impacts the login method required for users from Organization B. Even though both organizations have SSO configured, users from Organization B may not always be required to use SSO for login. The necessity for SSO or local authentication is determined by whether users from Organization B have a Customer Account or an Atlassian Account in Organization A and if SSO is configured for JSM.

Troubleshooting: