Access jira from another company

[nicolas.gavard]

Hi all,

We are using atlassian access to enable SSO authentication in order to acess confluence.

It works as expected.

Unfortunatly, some of our users used to connect to a jira from another company (a subcontractant) with their professional email adress.

They are not able to do it:

They are now redirected to our IDP which don't know anything about the subcontractant's jira and, thus, reject the authentication request.

Is there any way to fix this and to permit those users to connect to an external jira with their professionnal email adress ?

[nicolas.gavard · Accepted solution]

Hi @Dave Meyer 

Thank you for your answer.

You're right, I didn't mention that the affected users are not declared in  atlassian access (because they are not using our confuence).

They are just declared in the subcontractor's jira. But, as they are declared with their professional email adress, Jira cloud ask them to be authenticated using our atlassian access.

Thus,  do we have to add those users to atlassian access ?

And, those accesses to an external (from a subcontractor) jira will be counted in our atlassian access licenses ?

[Dave Meyer]

Hi @nicolas.gavard ,

Atlassian's SSO offering with Atlassian Access is tied to your company's email domain, so when you set up SSO, it will be applied to all users that are using their professional email (that your company manages). SSO is enforced on the account, so it will be applied whether the user is using your company's Confluence or another company's Jira, or another tenant entirely.

For example, if your company is Acme and you have verified the acme.com domain, your SSO configuration will be applied to any user with an account that has an @acme.com email address, even if the account is being used to access a Jira or Confluence instance that is not owned by Acme.

The opposite is also true: it's not possible to enforce SSO for external accounts that use email domains that are not managed by your company. If you have a Confluence instance for Acme, you can invite and collaborate with users that have  accounts using their @megacorp.com email addresses, but you cannot enforce SSO on these users. If MegaCorp also has Atlassian Access, they can enforce SSO for all @megacorp.com users even if they are using Acme's Confluence instance.

@jbartlett86 I think this would be sufficient for your use case.

[nicolas.gavard]

Thank you @Dave Meyer  for your clear and complete answer

[jbartlett86]

Hi @Dave Meyer thanks for the answer just a few questions for clarification.

1) What does it mean to provide an external user (different domain not managed by my company) access to my confluence but not enforce SSO? Is just using built in confluence users?

2) So your saying that the only way for us to enforce SSO for our customers (for there managed domains) is for them to sign up and pay for atlassian access? Can we sign up on there behalf?

3) I assume this means you do not suppose AzureAD Guests where a customer will login using there corporate email through our companies AzureAD.

Do you and your team not see it as a backward step that you cannot simply support connecting to third party IDPs as you would do using any number of plugins against either Jira server or data center versions?

Thanks,

John

[Dave Meyer]

Hi @jbartlett86 ,

A key difference between our on-premises products and our cloud products is that in the cloud, each user has a single Atlassian account tied to their email address that is used for all products and all tenants. The benefits for users are significant:

• You have a single username/password (or SSO provider) that work for any Jira, Confluence, Bitbucket, Trello, or other Atlassian product you might use
• You only have to log in once, and then you can move between products without having to reauthenticate
• You have a single profile and set of personal details to control, which is valuable for privacy

So applied to your questions:

>What does it mean to provide an external user (different domain not managed by my company) access to my confluence but not enforce SSO? Is just using built in confluence users?

Yes, you can directly grant access to your Confluence for any user. But it's important to understand that you are not creating users for your specific Confluence instance. You're granting access to users who may also use that same account with their professional email address for other instances that you're not involved with.

>So your saying that the only way for us to enforce SSO for our customers (for there managed domains) is for them to sign up and pay for atlassian access? Can we sign up on there behalf?

No, because SSO is bound to the organization that owns the accounts. So enforcing your own SSO on those accounts, even if it were possible, wouldn't be an ideal experience because they could be using the same account to access Atlassian products that are not related to your company.

>I assume this means you do not suppose AzureAD Guests where a customer will login using there corporate email through our companies AzureAD.

No. Again, accounts are bound to a specific SSO configuration based on the company that owns the domain of the email address on the account.

Do you and your team not see it as a backward step that you cannot simply support connecting to third party IDPs as you would do using any number of plugins against either Jira server or data center versions?

I would say that generally our cloud offerings have better support for moving between multiple products and instances and there are a number of use cases that we are still working on supporting:

• Multiple IdPs for an organization
• Enforcing security measures on external users
• User provisioning / IdP syncing for external users

I hope this is helpful.

Regards,

Dave

[jbartlett86]

Hi @Dave Meyer ,

Thanks for the information.

Ok so it boils down to the following:

1. We are acme.com and members of our staff (using @acme.com) are configured to use our AzureAD via our Atlassian Access configuration
   
   
2. If we work with a third party say betacorp.com, we would manually add to confluence a given set of users with that domain that could then access our confluence.
   
   When those betacorp.com users then logged in they would see our confluence instance as something they could then access and there experience of logging in would be either:
   
   
   1. SSO assuming betacorp.com has configured Atlassian Access with there IDP
   2. Standard Atlassian username / password if either no SSO has been configured or more likely betacorp.com do not manage any Atlassian products/services.

Is that summation correct?

The problem we are going to have is that our core customers simply do not manage Atlassian products and they simply rely on us being able to either hit there IDP (via the OIDC plugin) for there domain or utilising guest access via our AzureAD. 

Guesting is a massive part of reducing complexity in delegated authentication and I can't see why that wouldn't 

Thanks,

John

[Dave Meyer]

Hey @jbartlett86 , yep confirming your summary is correct. Definitely understand that the design is not ideal for use cases like the one you described. One mitigating factor is that for situation #2, where the betacorp.com users are logging in with Atlassian accounts and don't have SSO enforced, is that we do support social login with Microsoft, Google, and Apple. So even without SSO configured by Betacorp, if those users have a Microsoft / Office 365 account tied to their email address, they can use it to log in (which means they won't have to remember an Atlassian-specific password).

[jbartlett86]

Hi,

I've also got the same problem - we want to trial Jira Cloud but we cannot get Atlassian Connect to work as we require for the same reason mentioned above.

We provide access into our existing JIRA Server instance to customers and subcontractors working using their own email domains (owned by their companies) this is then managed using SSO hitting different IDP's (managed the customer) or using guest access via our AzureAD tenant depending on the domain being used (we are using the miniorange OIDC plugin to achieve this with multiple oidc issuers).

We need to re-create this behaviour but cannot see how this is possible using Atlassian Connect. Any help here would be greatly appreciated as we can't move to the cloud without being able to allow our customers and third parties to login using there own email via there own IDP.

Thanks,

John

[Dave Meyer]

Hi @nicolas.gavard ,

The behavior you're describing is a little bit surprising. When you set up SSO with Atlassian Access, the authentication is for the users' accounts themeselves. The individual Jira instance that your employees are using with the subcontractant should not know that they are authenticating with SSO at all.

Authentication is done for the user's account, not tied to any individual tenant. For example, if they are logged in and go to https://start.atlassian.com/ they should be able to see all cloud Jira instances they have access to.

Can you describe the error they're seeing in more detail?

[KAGITHALA BABU ANVESH]

Hi,

Please check "Delegated LDAP Authentication".

Where you can crate a new user directory with Second organization's users. with their professional email id's and Authentication from Active Directory.

https://confluence.atlassian.com/adminjiraserver073/connecting-to-an-internal-directory-with-ldap-authentication-861253203.html 

Please check the above link, This may helpful.

Thanks,

Anvesh

[nicolas.gavard]

Thanks Anvesh for your answer,

I don't see how ldap integration can help.

If I understood, ldap integration is not for cloud.

Notice that the subcontractant's jira is in the cloud.

[KAGITHALA BABU ANVESH]

Sorry,

I thought its a Jira server.