Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Next challenges

Recent achievements

  • Global
  • Personal

Recognition

  • Give kudos
  • Received
  • Given

Leaderboard

  • Global

Trophy case

Kudos (beta program)

Kudos logo

You've been invited into the Kudos (beta program) private group. Chat with others in the program, or give feedback to Atlassian.

View group

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Access jira from another company

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 ?

 

4 answers

1 accepted

0 votes
Answer accepted

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 Atlassian Team Dec 22, 2020

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.

Thank you @Dave Meyer  for your clear and complete answer

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 Atlassian Team Dec 23, 2020

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:

I hope this is helpful.

Regards,

Dave

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 Atlassian Team Jan 07, 2021

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).

Screen Shot 2021-01-07 at 10.05.43 AM.png

0 votes

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

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.

Like Kagithala Babu Anvesh likes this

Sorry,

I thought its a Jira server.

0 votes
Dave Meyer Atlassian Team Dec 21, 2020

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?

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

Suggest an answer

Log in or Sign up to answer
TAGS
Community showcase
Published in Atlassian Access

We're launching improved navigation for admins

Hi Atlassian Community, My name is Avni Barman and I am a Product Manager on the Atlassian Access team! One of my top priorities is to help make the administrator's life easier through improved pro...

931 views 1 10
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you