Authenticating external users with Entra AD

[andrew.jones]

Hi

I'm trying to set up a configuration scenario that I can't find covered in the documentation.

We use Atlassian Guard for authentication against our Azure AD (Entra AD) instance for all our internal staff. We have several third-party customers who we need to collaborate with on a Jira test project. These customers are already registered with our AD instance as external users and currently collaborate with us on Microsoft Teams.

We want these external users to be able to log in to our Jira instance using their own organisation’s AD credentials. The SAML authentication process should handle all the referrals via our AD instance using B2B Connect. These users also likely have their own Jira instance for their company that uses an AD identity provider.

• Enable seamless SSO for external users through their own AD credentials to our Jira instance.
• Ensure the SAML authentication process correctly refers authentication requests via our Azure AD using B2B Connect.

Does Atlassian Guard support the configuration where external users authenticate using their own organisation’s AD credentials and are referred via our AD instance using B2B Connect?

What are the best practices for setting up SAML configuration and attribute mapping to ensure successful authentication and user provisioning in this scenario? Any special considerations?

[Darryl Lee]

Great question - I don't think Atlassian has ever had a definitive answer about the B2B that we also wanted way back when:

https://community.atlassian.com/t5/Atlassian-Guard/Will-Atlassian-Access-work-for-B2B-Guest-users-in-our-Azure-AD/qaq-p/1898496

There's discussion in there about External User Security and 2FA, but I believe that only applies to External Users who are not otherwise onboarded into Atlassian, and the 2FA is managed by Atlassian, not Azure/your IdP:

https://support.atlassian.com/security-and-access-policies/docs/available-external-user-security-settings/

[Darryl Lee]

My sense is that this is going to be problematic as long as Atlassian insists on being ... what's the right word... a shadow IdP?

That is, THEY are the ones dictating who "owns" a domain, so if ACME.COM has not signed up for Atlassian Cloud and claimed their domain, they don't want to allow YOURCOMPANY.COM to delegate authentication for an account in that domain.

The thread above, and this olde one (https://community.atlassian.com/t5/Jira-questions/Can-Azure-AAD-Guest-Users-log-in-with-Atlassian-Access/qaq-p/1166039) talk about how the Guest Users are actually provisioned as:

test1_somedomain.com#EXT#@verifieddomain.com

Which won't work as a valid e-mail address/account.

And if you try to provision user@ACME.COM, and again, ACME.COM is not an Atlassian Cloud customer, then those user@ACME.COM will end up with a "local" Atlassian account.

[andrew.jones]

@Dave Meyer any update?

[DG]

@Dave Meyer is there any update in this case?

[David Olive]

Hi all!

We just released an enhancement to external user security which allows you to enforce SSO on external users. This should work for any externals in your Azure AD.

You can read more details about the feature and see a demo video of the feature here.

Let me know if you have any questions!

All the best,
-David

[Julien Béchade]

Hi @David Olive

Unfortunately, it does not seem to work for Azure AD federated users.
I assume it's because their UPN is actually not their e-mail address but looks like this instead firstname.lastname_federateddomain.com#EXT#@mydomain.onmicrosoft.com.

Do you have a way forward with this?

Cheers.

Julien.