Current situation: We are using the following cloud products: Confluence, Jira Software and Bitbucket. We distinguish two types of users in these products: 1) workers from our own company (registered with a company email addresses) and 2) external users, such as business partners/suppliers (who are registered with their external business email address). What we hope to achieve: We would like to use AA to enable SSO, automated user (de)provisioning, and more advanced security policies. We want this two work for all our current users (internal and external). * We will use our Azure AD tenant as IDP * We will invite/register the external users currently in our Atlassian products as B2B Guest users in our Azure AD tenant. (More info on B2B Guest users: https://docs.microsoft.com/en-us/azure/active-directory/external-identities/what-is-b2b) * We will have a single Organization for our company which will provide access to Jira Software and Confluence Questions: * Will user provisioning and SSO authentication also work for the B2B Guest users in our IDP? Since:* The UPN of a B2B Guest users does not contain our company domain. Instead the UPN will end on "@ .onmicrosoft.com", which is a domain we obviously cannot verify. * The B2B Guest user can still be identified based on their external business email address, since it is registered as the email address in their Azure AD record. However, we cannot verify the company domain of our business partners/suppliers on which their email address is based. * If yes, will AA recognise the existing external users in our cloud products based on their external email address? * Any other recommendations or considerations from community members who have set this up successfully? * Slightly off-topic: Is it possible to have a subset of users login with SSO, while another group of users still uses their local user credentials (application-side). Thanks for your help.

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; } } }

Will Atlassian Access work for B2B Guest users in our Azure AD tenant?

Koen Bins

Current situation:

We are using the following cloud products: Confluence, Jira Software and Bitbucket. We distinguish two types of users in these products: 1) workers from our own company (registered with a company email addresses) and 2) external users, such as business partners/suppliers (who are registered with their external business email address).

What we hope to achieve:

We would like to use AA to enable SSO, automated user (de)provisioning, and more advanced security policies. We want this two work for all our current users (internal and external).

We will use our Azure AD tenant as IDP
We will invite/register the external users currently in our Atlassian products as B2B Guest users in our Azure AD tenant. (More info on B2B Guest users: https://docs.microsoft.com/en-us/azure/active-directory/external-identities/what-is-b2b)
We will have a single Organization for our company which will provide access to Jira Software and Confluence

Questions:

Will user provisioning and SSO authentication also work for the B2B Guest users in our IDP? Since:
- The UPN of a B2B Guest users does not contain our company domain. Instead the UPN will end on "@<companydomain>.onmicrosoft.com", which is a domain we obviously cannot verify.
- The B2B Guest user can still be identified based on their external business email address, since it is registered as the email address in their Azure AD record. However, we cannot verify the company domain of our business partners/suppliers on which their email address is based.
If yes, will AA recognise the existing external users in our cloud products based on their external email address?
Any other recommendations or considerations from community members who have set this up successfully?
Slightly off-topic: Is it possible to have a subset of users login with SSO, while another group of users still uses their local user credentials (application-side).

Thanks for your help.

Accepted answers

Lise Wåsjø

Hi @Dave Meyer,

Is this available now? I saw the single sign-on for external users update, does this also work for guest users in Entra ID?

All comments

Dave Meyer

Hi @Koen Bins ,

Unfortunately this will not work. We don't currently support SSO for users with Atlassian account email addresses on domains that you cannot verify.

We recognize users based on the email address of their Atlassian account. If that email address has a domain that has been claimed by an organization, then we apply the SSO configuration for that user based on the organization.

Improvements to security for external users is something we're actively working on.

> Is it possible to have a subset of users login with SSO, while another group of users still uses their local user credentials (application-side)

Yes, you can set this up with authentication policies for your organization.

Koen Bins

Hi @Dave Meyer thanks for your reply.

A follow-up question to my 2nd question: If we configure one group of users with SSO, is it possible to enforce SSO for that group (not allowing application-side logins), while still allowing application-side logins for the other group (primarily consisting of external users)?

Dave Meyer

Hey @Koen Bins

Yes, you can set up different authentication policies for internal users (i.e. "managed accounts" or accounts with an email address on a domain you have claimed). External users (users with accounts with an email address on a domain you cannot claim) can still be granted access to your Jira/Confluence instance, but you won't be able to set any kind of login requirements for them.

You can't quite assume that they are purely using an email/password login from Atlassian, because there is the potential scenario that another organization has claimed their domain and enforces its own SSO when they log into their account (for example, if you have consultants working with you. They might have access to your Jira under their @consultant.com email address, but the consulting company enforces SSO on all @consultant.com accounts)

So a scenario you could have is:

1. Authentication Policy A (SSO enforced) for most of your internal users

2. Authentication Policy B (no SSO enabled) for low risk internal users or bots

3. External users that have been invited to your Jira/Confluence but do not fall under your authentication policies.

Hopefully that makes sense.

Dave

Michael.Barriere

The guest users in our Azure are given a new email, like the example below.

first.last@gmail.com -> first.last_gmail.com#EXT#@blank.onmicrosoft.com

Is there a way to claim that blank.onmicrosoft.com since it is appended by our azure? Then any and all guests in our azure organization would be eligible?

Koen Bins

Unfortunately not. Since you do not own blank.onmicrosoft.com (Microsoft does) you cannot claim it.

Darryl Lee

I realize this is an old topic, but this is precisely what we would like to do as well.

A few years back @Radoslaw Cichocki {Deviniti} made this video with Tomasz Onyszko from Predica that talks about doing this with on-prem Jira:

https://www.youtube.com/watch?v=_2OZuIDJeNw

Radoslaw - have you and your team (and maybe Predica) thought about or talked with Atlassian about doing this in the Cloud with Access?

Radoslaw Cichocki {Deviniti}

Hi @Darryl Lee

So you're the one who has actually watched it!
Good to meet you.

I haven't talked to Atlassian about it, I changed my role at Deviniti a while back and now I'm more on the Atlassian Marketplace apps side of things and haven't followed advancements in the SSO area for a while.

If this hasn't been addressed already, you can file a feature request with Atlassian and ask other admins to vote for it if they also need it. Probably somewhere out there there is a feature request for it already.

From all the people in my circle only @Szymon Szerewicz from Deviniti can have a solution. If he does not, very likely it can't be done. Szymon, do we have a solution for the Cloud hosting?

Regards,
Radek

Jeffrey Ambler

Thank you.

Tom Braat

Hi @Dave Meyer

I'm also exploring Atlassian Access and I'm interested to see if Atlassian already implemented the "External user security" as you indicate from the Cloud roadmap. If have been searching the roadmap but I'm not able to find it back.

Could you tell me is it already possible to apply the security features of Access (SSO) to external users?

Thanks!

Dave Meyer

Hi @Tom Braat , we are still working on this feature, but it is coming: https://www.atlassian.com/roadmap/cloud??&search=unmana&p=b8d50209-93

Wim Abts_q3dxeb

@Dave Meyer Are there any details?
The status is 'Released' but without any further info?
Where can we find it?

Dave Meyer

@Wim Abts we have begun early access testing with select customers but it is not available for open signup yet. Look for it in the next few months.

Joakim Ellestad

Hi @Dave Meyer

Is there now any solution for Azure AD B2B users?

Or what is the recommended way to grant access for business partners?

Joakim Ellestad

Hi @Michael.Barriere did you manage to find a solution for your Azure AD B2B users?

Or did you settle on an alternative?

Mani Chaudhary

@Dave Meyer , it has been more then a year, I know this feature is quite common these days, to provide guest access with SSO with IDP Azure or Okta etc. for a SaaS app; have you guys made a headway and is there any clear documentation for community? We work with contractors a lot and would like to manage everything in one-place and also make it a better experience for them.

Has anyone tried to do SAML attribute/claim transformation, where after your IDP as verified your identity (guest or user), a transformation is done to scoped users 'All guests' (or a group in AAD), to transform guest_domaincom#EXT#.domain.onmicrosoft.... to guest@guestdomain.com and pass that as claim/attribute to Atlassian? Provisioning works as per Azure AD but Atlassian doesnt see account, get an error about access denied, mismatch. The guest domain is obviously not listed as verified domain. We also don't want to use internal Atlassian user directory if we don't have to.

Maqsood Ali Bhatti

@Mani Chaudhary did you make it work? any solution?

Lise Wåsjø

Hi @Dave Meyer,

Is this available now? I saw the single sign-on for external users update, does this also work for guest users in Entra ID?

Dave Meyer

Hi @Lise Wåsjø ,

Yes this is now available. We treat Azure AD B2B guest users as "external users" and support them like any other "external" user in our SSO configuration. See this comment in another Atlassian Community discussion on this topic: https://community.atlassian.com/t5/Questions/Re-Re-Authenticating-external-users-with-Entra-AD/qaq-p/2815549/comment-id/5789#M5789

Darryl Lee

Hi @Dave Meyer and @David Olive - the new external IdP "step up" verification is exciting to see.

HOWEVER.

It doesn't seem like it addresses an outstanding issue for many of us, which is less about Authentication (SSO), and more about Authorization (provisioning of Users and Groups).

That is to say, the new feature definitely is welcome, because it ensures users have to go through OUR IdP for that additional layer of security.

But it DOESN'T seem address provisioning.

Many of us would like to leverage Azure AD/Entra's capability to group all Guest users from "Company X" into a "Company X Users" security group that could then be synced to Atlassian and other tools for proper granting of access.

It seems that both SCIM and Nested Groups (Microsoft Graph) will ONLY provision users in the claimed domains.

We have over 100 external domains accessing our Jira. Many of these domains have access to OTHER tools, which DO support Guest Domains/Users and Groups, and so say, "Company X Users" have access to the "companyx-collab" repo in our external Gitlab instance.

We'd like to use that same group to grant access to the COMPANYX project in Jira, and maybe a COMPANYX space in Confluence.

Arjan Jorink

Oh, I couldn't agree more.

Would love to see this functionality in the Atlassian suite.

Welcome!

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

Quick Links

Find more posts tagged with

cloud

atlassian-guard

azure

active-directory