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

Big bug? User access settings - "Any Domain" treats gmail.com as a private domain!

Jörg Hoffmann March 28, 2024

From the documentation page: https://support.atlassian.com/user-management/docs/control-how-users-get-access-to-products/

The Any domains feature allows you to decide how users with non-public email domains access your products. A non-public (or private) email domain is hosted by a private server and is more secure than a public email domain. Examples of public email domains are outlook.com, icloud.com, or gmail.com.

Email domains from private companies are considered to be private domains. Examples of private domains are sony.com, atlassian.com, or samsung.com.

This has proven to be incorrect!

See the screenshots below:

Screenshot 2024-03-28 124952.pngScreenshot 2024-03-28 125731.png


It seems any user with a gmail.com address is treated as a user from a non-public domain if you enable the "customer" Role for "Any Domain". This means they are granted access based on the roles assigned in "Any Domain", which is contradictory to the information on the documentation page quoted above.

It's unclear if other domains are affected as well as I only tested it with gmail.com. I think the testing gmail user has to have an existing full Atlassian user account and then try to access the internal Jira instance URL (not the portal), which will then grant access and redirect to the portal based on the "any domain" configuration above, at least if "admin approval" is disabled.

Any thoughts? Is it a bug or just a mistake in the documentation?

 

Edit:

Adding to my confusion the above test worked with the following setting turned off, which leads to the question, what makes a user an "internal" user to Atlassian, as opposed to an "external" one?

Screenshot 2024-03-28 143356.png

My 2 cents:

Overall I feel like Atlassian tends to write admin tooltips and documentation with almost a mindset of addressing a non-tech savvy user and introduces imprecise terminology, that changes as quickly as the features evolve, which leads to outdated, confusing and sometimes plainly false documentation.

Sometimes I feel like a beta tester forced to do extensive testing, because there are no established and up-to-date best practices for core requirements even when it comes to security which means there are no guarantees and of course no liability. It's the wild west and somehow everybody is okay with this.

1 comment

Ed Letifov _TechTime - New Zealand_
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
March 28, 2024

Specifically for "Customer" role allowing public email domains kinda makes sense – question is will it also work the same way with non-Customer role?

Like Jörg Hoffmann likes this
Jörg Hoffmann March 28, 2024

I would guess it works with all roles. Maybe I'll figure out a safe way to test it.

I think the "user settings" approved domain configuration only applies to full Atlassian accounts in any case, at least that is what the docs imply (but at this point I'm not sure the docs can be trusted):

Screenshot 2024-03-28 134712.png

Access through and creation of portal-only accounts seems to be exclusively configured through:

/jira-service-management/portal-only-customers

and

/jira/settings/products/servicedesk/customer-access

Comment

Log in or Sign up to comment
TAGS
AUG Leaders

Atlassian Community Events