nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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 ?

Accepted answers

nicolas.gavard

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 ?

All comments

KAGITHALA BABU ANVESH_z1zl10

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_z1zl10

Sorry,

I thought its a Jira server.

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?

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

nicolas.gavard

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

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

atl-gruland

identity-manager