-
Suggestion
-
Resolution: Unresolved
-
None
-
10
-
Problem Definition
SAML configuration and "managed" Atlassian ID editing options are not available to users on non-verified domains. There is a need for customers to be able to manage these user accounts.
Suggested Solution
- Find a way to bring functionality to all accounts within a given Jira instance.
- We may need to replace or supplement the domain verification process.
- Define a "contractor" account type.
Why this is important
- Customers often have "contractors" or teams using email domains which the customer does not own. SAML and domain verification is not possible, so functionality is not available on these accounts.
- In some cases, changes to a customer website or DNS changes can't be made due to company policy/political reasons.
- An example of this being an issue is a customer has connected to their IDP using SAML, their "contractors" attempt to login, but are unable to gain access to the instance. Entering a fake email address using the verified domain will allow the redirection to the IDP page to occur, but access is not granted as the contractor's domain is not verified.
Workaround
- No workaround.
- duplicates
-
- Closed
- mentioned in
-
Page Loading...
[ACCESS-1140] Verifying domains that are not owned by the customer
Hello,
Just a comment about the workaround "The workaround is to enter a fake email address on the verified domain so that the redirection to the IDP page occurs."
That's right, however, it's not a workaround, because you cannot login to Atlassian even if you successfully logged yourself in through the IDP's login page:
- coworker X with email address mr.x@not_my_verified_domain.com
wants to log in - coworker X enters a fake email address on Atlassian login page (e.g. mr.x@my_verified_domain.com) to get redirect to IDP's login page
- coworker X logs himself on the IDP's page using mr.x@not_my_verified_domain.com / password
- coworker is logged (proper SAML ticket is sent, session visible in IDP's admin interface), however, Atlassian refuses to log the user as it's address email's domain (not_my_verified_domain.com) in the SAML ticket mismatches the verified domain (my_verified_domain.com)
Regards
Comment on behalf of Jon Gilmore:
SAML implementation - ability to use SAML with unverified domains: Here is the scenario: we have ~1200 users currently using Confluence/Jira. Our actual company size is ~300. The remaining 900 people are contractors or are partners that we're working with. We use Okta for our IDP and all of those users have accounts that we manage in LOTS of other applications using their own corporations email domains. We're not able to 'verify' that we own those domains (because we do not). Atlassian should change their SAML implementation to follow every single other SaaS app out there: trust that when a SAML assertion comes in from a trusted IDP, map that username to an existing Atlassian username, regardless of whether or not they're coming from a 'verified' domain.