How to enable a mix of internal & external users?

[Philip Colmer]

At the moment, we're running Jira, Confluence and Service Desk as self-hosted server products. Each of them syncs to our LDAP infrastructure, which holds account information for internal and external users.

I'm trying to map all of this onto the Cloud offerings and I'm stuck with how to deal with the external users.

I've got Atlassian Access syncing against Google for the internal users, with our verified domain.

It looks like we can't use Atlassian Access to hold accounts for our external users, even if we tried to use the REST API to do so, because the documentation says:

"A user account can only be created if it has an email address on a verified domain."

and I'm not going to be able to claim verification on every domain.

In theory, I think I could work around this by creating "local" users on each of the actual Cloud products ... but then the group membership breaks because the groups are held in Atlassian Access ... and they are going to be incomplete because they can't hold external users.

What the heck can I do? I thought that I could use our Keycloak SAML server but (a) that isn't one of the supported IDPs and (b) I think we'd hit the external domain problem again.

[Martin Strak]

Hi, a potential customer who uses Keycloak as IDP asks if and how they will be able to manage their external users (partners and clients). Are there any news on this topic? Reading various community posts, most of them probably outdated already, it doesn't seem like a walk in the park. 

What can I tell them? Is there any good info / instructions available, at best officially by Atlassian, on how to get external users managed by Atlassian Access, strictly applying authentication policies like 2FA? 

All the best, 

Martin

[Philip Colmer]

It does occur to me that one potential solution would be to get all of our external users to sign up for an Atlassian ID account. I say that because I clearly only have one Atlassian ID account and that gives me access to various Jira Cloud sites that I do not manage.

However, I would then seem to have a problem in terms of looking up an external user in order to determine their ID reference so that I can add them to our groups.

The absolute fallback workaround would be to generate internal accounts for all of the external users but that is a massive failure if we reach that point because it puts a huge hurdle in the way of signing up people for access.

[Narmada Jayasankar]

Hi Philip,

We are working on supporting syncing external users via SCIM user provisioning. If your IDP supports standard SCIM protocol, you should be able to start syncing these users after we rollout out the feature. We plan to have it out before the end of this calendar year.

Thanks,

Narmada Jayasankar

Lead product Manager, Atlassian Access

[Philip Colmer]

Thank you, Narmada. That is a huge relief.

I'll now schedule the work to get our Keycloak IDP upgraded so that I can install the SCIM add-on I've found.

[Philip Colmer]

Hi @Narmada Jayasankar 

Is there any update on when external users can be added to Access?

Many thanks.

[Narmada Jayasankar]

Hi Philip,

Provisioning external users through SCIM is available by default for all new SCIM connections since the beginning of December 2020. If you configure SCIM now, it should work for you.

Thanks,

Narmada Jayasankar

Lead product Manager, Atlassian Access

[Philip Colmer]

@Narmada Jayasankar thank you for that update.

We don't yet have SCIM in place. I'm scheduled to upgrade our Keycloak IDP at the end of this month and that will hopefully allow us to set up SCIM.

In case I cannot get SCIM working or cannot get Keycloak working, will the user provisioning APIs be updated to allow the provisioning of external users?

[Philip Colmer]

@Narmada Jayasankar it doesn't look like the SCIM implementation on Keycloak supports the push mechanism required by Atlassian Access so I've switched to Okta.

I'm syncing from our LDAP server to Okta, then using SCIM to provision from Okta to Atlassian Access.

There is something weird going on ...

Under "User provisioning", a group shows it has members:

However, if I go to the groups view in the admin interface, it shows zero members:

It should be noted that this group *only* contains external users so I'm wondering if there is some filtering going on somewhere ... If I pick a group that I know has internal users, it displays correctly. If I pick a group that is a mixture of internal and external users, the groups view only lists internal users.

Also, if I go to People in Jira, I cannot find any external users.

[Narmada Jayasankar]

Hi Philip,

How long has it been since you sync'd the group? There is a delay for the sync'd users to propagate to sites but it shouldn't take too long. If it's been more than 20-30 (shouldn't take this long), please file a support ticket and pass me the link the link to you ticket. I'll have my team investigate this further. 

Thanks,

Narmada

[Philip Colmer]

@Narmada Jayasankar Thanks - the ticket is PCS-25394.

(Interestingly, I cannot find a SEN for Atlassian Access so had to submit the ticket without one. I'm presuming that Cloud products don't have SENs, but the support forms don't seem to understand that)

[Narmada Jayasankar]

Thanks. Let's communicate on the ticket.

[Philip Colmer]

In case anyone else comes across this topic, the outcome was that I had migrated a lot of groups, which was then multiplied by the number of sites, so overall importing took a long time.

For a given Cloud organization, you can go to Security > Audit log to see what is happening with regards to any imports.

Eventually, the products caught up with our user management system and I'm glad to say that we have external users visible and in groups.

The one gotcha I have hit is that Okta, for some strange reason, *insists* on LDAP accounts including first names, even though their own profile configuration for users doesn't. Okta silently refuses to import LDAP accounts without first names ...