@Matthew Russell I've communicated to Okta support and the feature request is internally tracked at Okta with ticket REQ-7770. I would recommend that Atlassian and all it's customers communicate to Okta to expedite the connector by referencing this ticket number.

They've communicated that the work-around currently is to provision a generic Okta SAML2 app and configure JIRA to use those details. However, if you use lifecycle management, this workaround requires you to maintain two apps within Okta, one for provisioning and one for SAML2 auth.

Sorry parker.despain699968528, I've been in touch with Okta multiple times since your original question, and status hasn't changed. They're still in progress with their connector. They suggested for those interested to send an email to support@okta.com or open a case directly at https://support.okta.com/help/open_case. This is not really in our control at this point - we're as keen as you are to see it available. 

sracherla969129257 - I'll assuming you're looking at testing while Atlassian account is enabled (Single sign on is turned on). Deleting a SAML configuration does not send password reset emails. If, however, someone goes through login while there is no SAML configuration, they will be able to login with their password (or able to set a password with password reset). Please be aware that while you're testing with your Test IdP, all logins for your users will be going through that IdP - so you will likely lock out some users. We have better testing capabilities in mind for a future enhancement. 

hairom1715481686 - If the existing Atlassian account has an email on the domain you have verified, this should enforce SAML for them. Are you still experiencing this issue. There are a few valid edge cases that explain a failed SAML authentication. If you're still experiencing it, I'd recommend raising a support issue so we can investigate. 

So is that a No!!! on the Okta thing, or are you just ignoring us to be hilarious?

^^ I'm waiting for the exact same thing, fingers crossed...

Please provide on update on SAML for okta.

Can an update be provided for when this will be available for Okta? 

@mrussell@atlassian.com
We have 2 idp instances- idp Test and idp Prod
SAML implemention workflow:

1. Implement idp test
2. Test the implementation
3. Delete the idp test
4. Implement idp Prod

How will the end users/admins be affected by this? Will the users get a password reset email or go back to Atlassian account password when we delete the SAML configuration?

Thanks.

Yeah.  Mine is working today as well.

I used Chrome. After contacting Atlassian Support, this was resolved.

I used Chrome, Firefox, and IE

stephen_brile1875246223 & dfriedman722787694 - what browsers are you using? 

miller.jira699748083 - Deleting the SAML config won't send a password reset. It will be possible for people who've successfully logged in with your SAML to have no password set on their Atlassian account, but they will need to perform their own password reset. If you turn of Single Sign on, you are pointing your site back to our legacy login system, and anyone who has successfully authenticated with an Atlassian account will receive a password reset in that case. For your mismatched email question, existing domain users will not be able to authenticate, though they will not be deactivated. I hope that answers the question?

mreilly326238220 - The main component of support for ADFS comes in the form of documentation from Microsoft. Since Microsoft are not planning on providing documentation / configuration guides, we don't want to set an expectation that our support engineers will all know the in's and out's of ADFS to help you get set up. Microsoft have recommended Azure AD as the solution with ADFS. 

For troubleshooting if I delete the SAML configuration, will the users get a password reset email or can we still implement SAML again without effecting the users? 

^^ I just submitted a support ticket about this issue.

When I click the verify button from my domain, I do not get a window that lets me download the .html verification file.

I see that email id's are case sensitive, what if the email id's do not match?
Will the existing domain users be deactivated?

I wonder: Why no official support for ADFS as an IdP?

Per: https://confluence.atlassian.com/x/bJlCMw 

"We don't officially support ADFS, so we recommend using Azure Active Directory instead."

sracherla969129257 - you are correct. The implementation on your DEV instances will impact login at your PROD instance. 

nmoore@co.pierce.wa.us - To add to Russell's point, my language may have been ambiguous - the users are provisioned automatically upon arrival at your site. So of the 2500+ users who can authenticate with SAML, only those 150 that arrive at you Atlassian site will have accounts created for them, when using domain restricted sign up in combination with SAML.

DevReports195286775 - it should be your IdP password. Your Atlassian account password is now only used for API authentication. 

******************
Testing Instructions:

1. Open a new incognito window.
2. From your site's login screen, sign in with an email address on one of your verified domains.
3. Confirm you are signed in correctly and have all the expected access.

******************
After implementing SAML, do you have to use your Idp password or Atlassian Account password to login

Thanks.

@ Nate Moore

I dont know what SAML provider you are using however with Azure you can assign apps per user or group (if you have Azure AD Prem) and that can be a control mechanism...also with ADFS you can restrict to domain group who is authorized to leverage the appropriate claim

Matthew - regarding your comment on Jan 2 about automatic provisioning:

If you have Domain Restricted Sign up configured on your site, with SAML enabled on that domain, you will get automatic provisioning. If an user with an authenticated IdP account arrives for the first time, they will go through the SAML dance, and arrive back at your site as a new user, with "default access" groups that you have configured.

What is the solution for when you're not providing accounts for your entire enterprise?  For example, we have 2500+ users who can authenticate via SAML, but only 150+ who need JIRA access.  Is there no mechanism for only using SAML for authentication?

@mrussell@atlassian.com 

Thanks for the info.
"If your PROD instance does have Atlassian account, then testing on a DEV instance will not provide you a sand-pit. All configurations on your DEV instance will apply to all Atlassian account enabled sites" 
Does this mean even if I implement SAML on a DEV intsance, the users will have to use their Idp password to login to their PROD instance?

Thanks!

@Matthew Russell: Fantastic. Enabled domain restricted signup and provisioning works fine. It would be even better if it skipped that middle step of hitting the login screen, but it will work for now.

Another feature I might suggest for the future is reading the group memberships the SAML provider can push across and automatically place the user in those groups if they exist on the Confluence side.

Thanks!

brett.wiard980557619 - we are close to having IdP initiated SAML complete - we hope to have that incorporated before we go to public beta. Timescale here is days/weeks. 

aaron.pollock1141433412 - Thanks for your feedback! We're looking at improving the configuration page to include a feedback button. For your questions: 

• We have an ability to suppress the invite to a user coming soon also. 
• There are no plans to remove the Login with Google button from the login screen, as this login screen is used across all of Atlassian account - it is not customisable per customer.
• If you have Domain Restricted Sign up configured on your site, with SAML enabled on that domain, you will get automatic provisioning. If an user with an authenticated IdP account arrives for the first time, they will go through the SAML dance, and arrive back at your site as a new user, with "default access" groups that you have configured.

sracherla969129257 - If your PROD instance does not yet have Atlassian account enabled, you can safely test there (SAML configurations only apply to login with Atlassian account). If your PROD instance does have Atlassian account, then testing on a DEV instance will not provide you a sand-pit. All configurations on your DEV instance will apply to all Atlassian account enabled sites. This is a quirk of the single-account nature of Atlassian account that we are looking at solving with better test capabilities within the configuration. 

@Brett Wiard

I had it running for a bit and when it was enabled, if I went to domain.atlassian.net it piped me over to the SAML page...but post login it had me do a quick validation...

I would love to be able to an IDP into it so I can 302 page and make it friendly, ie atlassian.internaldomain.net and that lands on a page to log into pass credentials into the system, no email, etc...did it with new relic and ADFS (ADFS is still unsupported for this beta)

Are there plans to have SAML send the user to <domain.atlassian.net> instead of id.atlassian.com? This causes the user to have to enter their email address, then click the <domain.atlassian.net> URL inside their Atlassian profile page.

Is there a place for customer feedback surrounding the SAML features? Specifically, I'd like to see the following implemented:

• No invitation sent when adding a user that will be logging in with SAML. There's no need for them to have that, as they'll just be clicking the Atlassian and/or Confluence button in our SSO provider.
• Removal of the "Log in with Google" button on SAML enabled sites.
• Auto-creation of accounts for people that log in with SAML which get placed into the default "confluence-users" group.

I love a hands-off deployment where I wouldn't have to send invites to every employee (That when clicked, sends them to a page that tells them they have no access to view it).

Cheers!

Hi *

there is new ticket for SAML and standalone Server installations.

https://jira.atlassian.com/browse/CONF-45634

Please vote

KR - Wolfgang

@Wesley_Kirkland

while I did read over the rfc governing email and SMTP messaging, I feel this is not applicable here as we are dealing with SAML protocols and not messaging...I worked with Atlassian product support on this and they did confirm they did this by design...

Russel,

The case sensitivity is probably coming from this RFC https://www.ietf.org/rfc/rfc5321.txt

So I was able to get ADFS online with Atlassian SAML, its pretty straight forward but there was some caveats and a possible bug that gets in the way

1) caveat - nameID must match AtlassianID down to the case...ie the final transform from the system must align to what Atlassian has for your ID, jdoe@test.com=jdoe@test.com, JDoe@test.com will not work

2) bug - Currently if you have a managed domain (which most of us do), you can not update your email case...they have that in flight, so you would need to update UPN or what ever source is for nameID transform

3) IdP direct auth - some sites you can do adfs.test.com/adfs/ls/IDPInitiatedSignon.aspx and select the provider or simply have a 302 page to https://adfs.test.com/adfs/ls/idpinitiatedsignon.htm?loginToRp=identifier...this does not work quite yet...historically this is hit or miss with some of the ones I have done and usually takes some more work to get correct info or add another SAML page

4) Secure Logoff - no SAML url posted yet, since this is beta not a big deal

ADFS Fun

creating the ADFS claims connection wasnt too hard since they give you the pertinent info in the saml page, however there is no XML or web site to pull the config from...so manual fun, still not that crazy...

below are the fields that need to be in place for the site

Next is the Claims/Transforms

and your done...

just remember the output of the nameID in email format MUST MATCH the Atlassian ID to include case...this is by their design...

one tool to help is a plugin for chrome (https://chrome.google.com/webstore/detail/saml-message-decoder/mpabchoaimgbdbbjjieoaeiibojelbhm)

hope this helps some folks...but remember at this time ADFS is not officially supported by atlassian, so enjoy at your own risk/sanity

Would like to add our voice to the chorus of those requesting SAML for Atlassian Cloud products. 

I successfully configured SAML with Azure Directory. I faced one Issue:

• After finishing configuration I was not able to login with an AD user - error was: Reply address "https://id.atlassian.com/login/saml/acs" does not match the configured value "https://id.atlassian.com/login" (message is not 1:1)

• I fixed it by setting the Reply URL in Azure Active Directory configuration to "https://id.atlassian.com/login/saml/acs" (under advanced settings)
  

All,

I am still tinkering with ADFS however there is a small catch that may not be explained quite right...if you disable, it states everyone will get their password reset...not exactly true, its everyone that has successfully authenticated VIA SAML will get reset...could lead to some moments of panic or sudden resume updates

While I was able to get ADFS to work with jira.atlassian.com I experienced a new error "Unfortunately we currently do not support change in email in your Identity Provider."

We have hundreds of users and we really need this but I am afraid to touch this beta

@ mlavigne 

on my instance/tenant when I switch it off SAML, all is good...but when I want to post to boards on jira.Atlassian.com it wants to authenticate me to id.atlassian.com which has my domain flagged for saml so I have to do id.atlassian.com/logon?saml=false

so for all my users, life is back to normal...its only when a user hits id.atlassian.com...

@russel, are you saying you were NOT able to disable it and have to always pass in saml=false now?

@datagenic

I am also playing with ADFS3, I got it to pass the data but stated no UserID...I was doing Email (and also tried UPN) to email ldap match then doing a transform in the claims from email to Name ID and format email...also added the additional surname and given per the docs but no love...no errors in adfs either...I disabled it and fwd'd them my SAML logs from my plugin from chrome...I also tried IDP initiated from /adfs/ls/IDPInitiatedSignon.aspx and that just basically said "huh"? I think the endpoints are correct, just the claims or something is off however wouldnt be surprised if you we need to do custom xml for claims

also worth noting after I turned off SAML for the instance, if I went to ID.atlassian.com again it defaulted to SAML for me, had to use the logon?saml=false flag

@Mike https://id.atlassian.com/login?saml=false It's in the document.

I've tried this with ADFS (guessing some endpoint URLs and mappings based on other SSO plugins etc) and had no joy, but instructions are not yet available. A step in the right-direction Atlassian, now we just need SAML for BitBucket too please.

Has anyone turned this on yet? I am worried about the enforcement by domain. What happens if its configured wrong and I can no longer log in as an admin. Seems like a mess waiting to happen...

Just FYI:

• SAML single sign-on for Atlassian account

Just received the beta invite. 'Azure instructions coming soon' FFS

tracy.rhinehart yes the SAML beta is running SAML 2.0

What version of SAML is the beta? SAML 2.0?

If I enable the SAML beta is it enforced for the verified domain or is it optional? 

Nice to see the beta starting up, now let's hope that they do the same for LDAP, then my company would be able to seriously consider Atlassian Cloud apps.

Hi thomas.hadig Just passing by to know if you were able to catch this update of the private beta for SAML?

In case you missed please, fulfill the form in order to participate .

-------------------

Best Regards!

Daniel Brito | Atlassian Cloud Support

Please feel free to register to take part in our SAML Private Beta as mentioned in the update at the top of this issue. We would welcome feedback on the feature and the process to enable SAML for your Atlassian sites.

We are now investigation alternatives for Jira, Asana and Phabricator.

I wouldn't hold your breath... I've been waiting 5 years for this. Unlikely to happen anytime soon I suspect. There are other decent hosted tools that are equal to Confluence and JIRA.. (Asana et al).

From Wikipedia: "Atlassian also began a now-popular tradition at software companies where software developers can spend 24 hours tackling any problem they like four times per year. Atlassian calls these ShipIt Days".

So even if Atlassian Management don't care about their customers, it's clear the developers don't either or this would be fixed by now. JIRA is the Flagship product for Atlassian, and along with issue ID-79 for LDAP integration which has been open for 6 years  this one is stinking up the place.

@Dennis Portello - they even have their own IdP solution (https://www.atlassian.com/software/crowd), so it's not like they don't have a very good grasp of SAML / OAuth. It's just very odd that it's not integrated into their cloud products, where it would benefit most.

Yes - can we have an update please!

100% agreed with the above... I've used https://github.com/bitly/oauth2_proxy to provide Azure AD authentication to simple sites/applications, and I've integrated oauth2 libraries in apps we've built ourselves. SAML and OAuth2 can be a little mind numbing, but it's not rocket science. There are tons of Java libraries out there that Atlassian could integrate with their products. I just don't get it... smh

100% agreed. We actually started setting up Crowd, on a (wrong) understanding that it would allow us to do SAML auth to the Atlassian cloud apps... We were wrong, and very nearly terminated the trial of JIRA. As it stands now, we're only licensing about 10-15% of the users that we would otherwise use if full SAML was available.

We currently use Azure AD (or ADFS if really needed) for our SAML auth, and integrate with half a dozen other cloud services already. Not just a "nice to have" anymore, but a need for businesses like ours for full adoption.

Yes, what Dylan said.  An update and timeline guidance, please.

And me as well. Especially interested in integration with ADFS/Azure AD. This is a requirement to even investigate using JIRA cloud for us. Is it possible to get an update on progress for this feature?

Add me to the chorus of people that need SAML support.  Jira is the only SaaS product we use that does not currently have it.  I cannot realistically expand our usage of Atlassian tools until this exists.

I've given up on Atlassian as a company wide tool. It's been relegated to a small department within IT where I don't need to worry about managing large number of users.

JIRA is the last of our apps that doesn't support SAML... Seriously Atlassian? Wake-up we are in 2016 and most companies don't care about the iDP features you are or will provide, they need to integrate with their current iDP platform...

Bump... (Asana supports SAML btw)

We're having a hell of a time getting our password synchronized from our iDP (Okta) via SWA and wouldn't you know it, SAML would solve our problem.

Unfortunately, I have discovered that Atlassian does not support SAML ATM.

Tisk, tisk...

Time is ticking Atlassian and it's high time this standard feature be implemented ASAP. Wouldn't want Atlassian to market share to a competitor simply because of SAML support.

ESSENTIAL FEATURE

I'd like to adhere to @msholmes comment.

We are implementing a wide DevOps platform, with cloud and on-premise tools, many of those can authenticate with our SSO platform(Ping Identity) via SAMLv2.

Almost all of the newest tools have this important feature.

This feature is essential.

• MUST defer authentication to our domain's IdP
• SHOULD support SAML attributes from the IdP to the Atlassian application to auto-create accounts on first successful sign-in (i.e. pull sn, givenName (or displayName), mail)
• SHOULD support administratively configurable attributes mapped to Atlassian application (e.g. presence of "ConfluenceUser" gives access to Confluence, and "JiraUser" to Jira, etc; absense removes access)

SAML IdP administrators know the benefits of these capabilities for all parties involved.

We are looking at cloud-hosted upgrade options for our 2000 users, SAML/ADFS or SAML/KeyCloak is a requirement for us to minimize the acount administration burden and security risks.

SAML/ADFS/AzureAD integration is a must. JIRA is the only cloud suite that doesn't fit into our current setup and causes much friction for our users. We have O365, and use JIRA for JIRA,Confluence,Bamboo,Service-Desk. We'd like to understand how Service-Desk would fit into this mix also with non-SSO users (ie. customers) self-registering, and our internal users using SSO.

Please support SAML/ADFS soon!

We are looking at cloud-hosted upgrade options, SAML/ADFS is a requirement for us.

I agree with Dan, SAML and OpenID support are necessary.

I would hope they work on both SAML and Open ID. My project is a collaboration of many separate entities and I need to tie them all together. Hopefully we will have that in the future. We had to purchase the server based one and come up with a solution ourselves.......

I would love to test an Atlassian built solution.

Dan

In this day and age, why head for a dated protocol like SAML and not the more modern Open ID Connect which is gaining traction?

If we were playing Texas hold 'em, your first question would be classified as "tell:" "Atlassian believes a single account for end users will foster lower friction collaboration within and between teams everywhere, and that this is a highly desirable concept for our customers."

Ultimately, who controls the work that's produced is the question. If you're taking the GitHub approach (where individuals have their own GitHub usernames/passwords and are invited to join a particular company and collaborate on projects), that's one approach. Another approach is that the company that said individual joins is the IdP (Identity Provider), and once said individual leaves that company, (s)he leaves that identity (and work created with it) behind.

Both approaches have their merits. The GitHub approach to identity management ensures that an increasingly mobile ^{(cough millennial cough)} workforce can retain their individual identities & side projects wherever they may roam. The "traditional" corporate approach all but guarantees (at least in the eyes of the employer) that "what's produced here stays here." When you leave the company, you forfeit your access to your identity and the work you produced while you were under their purview.

I believe we're each entitled to our own opinions on who owns an individuals online identity as it pertains to collaboration tools, especially in the age of an increasingly mobile workforce.

What's at issue here is how authorized individuals gain access to corporate data.

If Atlassian is the Identity Provider (hereafter referred to as the IdP), and an individual's identity is "invited" to access corporate data, there are no restrictions on:

• Two-factor authentication
• Time-based access
• Geography, conditional access, etc. (depending on the requirements of the SAML IdP)

...whereas, if the company is the IdP, they can dictate the above requirements by refusing to issue a SAML token to their repositories/wikis/etc. to a user who does not meet their security requirements. This should not be understated--it's important from a security POV.

Furthermore, locking a user out of that company's directory would effectively prohibit access to said company's intellectual property by virtue of the fact that the company is the IdP. With so many disparate systems in use today, will 100% of admins remember 100% of the time to revoke an ex-employee's access to the company's repositories/wikis/etc. upon their departure?

Not a sermon, just a thought... ^TM

I took the survey to mean what would I pay for a combined Jira license, Confluence license, and SAML, so I based my answers on that. Do we expect they were asking for costs of just the SAML feature?

I'm shocked that after such a looooong time of building this that they are now even considering it as a "Premium" offering. Yes, I get that they had to do a bunch of infrastructure work to enable this. BUT, these:
• SAML 2.0 SSO Support
• Custom Domains
• 2FA Auth with optional SMS
• Consolidated Billing
are a core component of what any cloud offering in 2016 should have.

It is NOT a premium thing at all, period!

@anthony - absolutely - I got the same survey, and happily answered $0 for each of those.

Why on EARTH would I pay MORE for a consolidated bill?!?!? Honestly!

The reason I'd pay $0, and therefore wouldn't purchase those features, is that I expect those features from a SaaS offering. Also, I have no plans to extend my use of Atlassian Cloud, and in fact are actively migrating from it.

I was hoping for more free form text boxes where I could explain to them that this should not be a separate "premium tier" because after all THEIR SALES TEAM TOLD US THOSE EXACT FEATURES WOULD BE AVAILABLE SHORTLY WHEN WE FIRST BOUGHT INTO THE CLOUD VERSION.

I don't see any reason why I can't share what they sent me if they do truly value our feedback, unless the URL is unique to me. Give it a try:

Hello,

Your feedback has been instrumental in developing and improving JIRA and Confluence, and today we invite you to help us understand the value of our product.

We believe pricing and value should not be a one-sided conversation, so please take a minute to answer our survey. We're excited to receive your feedback!

https://www.surveygizmo.com/s3/2733520/Atlassian-0202

Yes - how do we get an invite to that survey??

I hope I get an invite, that would be so much fun

I was just invited to participate in a survey asking how much we would pay for "JIRA/Confluence Cloud Premium" with:

• SAML 2.0 SSO Support: Configure SAML authentication via IdPs such as: Okta, OneLogin, Centrify, Ping etc. and any other providers that support SAML 2.0.

• Custom Domains: Use a customer-provided domain, e.g. yourdomain.com for the Atlassian service.

• Two Factor Authentication with SMS: Enhanced security multi-factor authentication with optional SMS validation.

• Consolidated Billing: Manage all of your Atlassian services on a single bill.

So, it seems as if this feature may be in the works, but Atlassian wants us to pay more for it by calling it a "Premium" feature.

Not all of us use Google Apps. SAML is needed badly.

There is a roundabout way to accomplish this now, but it only works for those companies who use Google Apps for Business. If your Atlassian Cloud instance is set to use Google Apps for authentication and your Google Apps is set to use something else, such as Azure AD or on premise ADFS, it will work. When you go to your Atlassian Cloud and click to sign in with Google, you will be redirected to your ADFS login page. Atlassian won't show up as an App in your Microsoft portal though since Microsoft won't know anything about it. I realize this isn't a feasible workaround for most people and certainly shouldn't be treated as a legitimate solution by Atlassian. Atlassian needs to allow their products to integrate directly, without having to use Google.

@nginge maybe you want to chime in here?

FYI: I spoke with Atlassian's Enterprise Product Managers last year about the inability to meet basic enterprise requirements, beyond SAML (Think CAIQ /Cloud Sec Alliance compliance). This was on the roadmap but those people have since moved on and Atlassian will not return our requests for account management follow ups so we're dropping their cloud platform from available infrastructure options for our corporate use.

That's just the way it is. They'll still make money and we'll use another option. C'est la vie. Funny enough, Microsoft's "Planner" is getting more and more features so when it gains feature parity with Atlassian's JIRA Agile and Portfolio, it'll be a viable options for enterprises that require cloud security compliance.

Same issue here - I have huge fights every few months to keep it up and running. Security is very important these days and managing accounts in multiple environments is just no option if your organization has more than 10 employees working with a tool. Using O365 accounts should be a no brainier for an enterprise solution like Jira...

In short: 2 years - nothing happend... time to get it done!

It is really trange that this functionality is not present end priorized in a SAAS solution as JIRA ...
So My security reponsible refuse us to use JIRA in SAAS.
What a shame .....

I never thought I'd live to see the day but friends my Jira SAML issue may have already been solved. http://techcrunch.com/2016/06/06/microsoft-officially-launches-planner-its-trello-competitor/
Microsoft already integrated SAML for us awhile back for Office 365 so now we have a solution to migrate off of Jira completely. I urge you all to do the same.

It would be great if this was a SAML 2.0 universal solution so that it would work with other SSO providers like Okta too - right now I'm forced to look at google apps integration to see if that will work for us.

@agrutta I have also previously offered to work with them on this topic. ID-79 was my request in hope of getting SOMETHING out of it after that went nowhere.

I get the impression that this might be a renewed push for Atlassian Crowd. As if Enterprises want to base their identity strategy around a cloud suite of products for developer productivity.

I can believe this is what they went with, it is like they are complete missing the point and have completely disregarded the history of this issue.

First this...
"Consolidating the multiple user accounts that exist across the Atlassian cloud into a single account, profile and authentication technology - we refer to this as Atlassian account. Rolling out Atlassian account for all users and products allows us to establish a single identity for a given email address and simplify the identity management and authentication requirements for the end user. This also allows SSO for end users into all products and services they're authorised to access"

This is 100% untrue, I personally provided code that demonstrated that SAML compatibility required no alteration of the "Atlassian account" or any internal authentication or authorization system. And I also demonstrated that this would not have to be implemented across all products, it could simply be an option isolated to an individual app and turned on by the administrator for use within the subdomain. I offered this code up to Atlassian and even asked to speak to the product owner, it fell on deaf ears.

Next we have this little gem...
"Establishing account ownership principles that allow administrators to assert a claim over users within their domain. We need to provide assurance to admins that user accounts they lay claim to can be administered only by them - including accounts managed via SAML. We implicitly have this today with user accounts being scoped to a given tenant, but the global uniqueness of Atlassian account means that we have to make this explicit"

Seriously? You have no idea how SAML is implemented do you? Accounts don't have to be managed by SAML it can simply be used as a mechanism to authenticate that a user exists via the remote IDP, the authorization can them be handled by the Atlassian side of things which could also be further manipulated by clients using the REST api (for automation purposes).

What even gets more frustrating...
"Rolling out these pillars entails a significant amount of effort, and has been the focus of our team for some time. A lot of the foundation components happen under the covers which means that there's no immediately visible impact to users or administrators that we can share."

I call BS! I offered to give you the code, I was willing to provide a demonstration, this would have been a PATCH!!!!

Finally...
"I hope our team will be able to share a more substantial update in the near future."

Define near it's been since 2014, this is obviously not a priority and all this proves that when we started to voice our dissatisfaction via social media all of a sudden you took notice. It just shows we need to be louder!

@nginige how about even a broad ETA so we can plan how to run our businesses and decide if we need to pull out of cloud or wait for the solution? That response was just a lot of blah blah blah and tells us nothing different than what you did years ago. In fact, it was interesting that it came over the pipe as an edited version of essentially the same response as Nov 2015. It isn't a particularly compelling story if you can't supply any better information than that from 5 months ago. I'd interpret that as zero planning or progress.

It is great that Atlassian is working on this issue and explaining that it is a large effort is helps. But the fact remains that not even Q3 2016 or Q2 2017 is thrown out. I wish I could do that at my company, we are working on your requests you will have your features some day. Why is it so hard to give some sort of target, not looking for an exact date?

Agree with all the comments - perhaps SAML enabling ALL products would be the best way to deal with this? Insert your Atlassian Uniqueness ID in the SP layer. Problem solved.

If an ETA is unrealistic, would it at least be possible to link the blocking tickets to this one so we can see the progress as those tickets get closed out?

Yadda, yadda, your call is important to us.... yadda, yadda, we value your business...

Consolidating all Atlassian products to one account while noble, sounds like a large job (read: lengthy).
Adding SAML support to existing Jira accounts, (even a temporary, unsupported Beta) could probably be knocked out in a couple of weeks. We've been waiting years for this, please don't make us wait more years.

@Nuwan Thanks for the update, I appreciate knowing my voice is being heard. However this has been a very long-running issue as you note and your message is essentially the same as the previous message dated 19 November 2015 and, almost four months later, does not contain a "more substantial update" regarding ETA.

Nuwan Ginige, how about providing an ETA?

• Michael
  The problem is not the user Sync. It is having a Single Sing On. Who needs one more password to store and control? Not to say that adding users via your technique is not helpful.

I worked around this feature gap by writing a script that uses the JIRA API to get all active users and compares them against an internal Active Directory. Anyone not active in AD is deactivated in JIRA. It's not perfect, but it does the trick. Source code is shared on GitHub: https://github.com/katonahmike/jira-ldap-sync

I had the same thought. There's always the ulitmate goal, the most ideal solution, but sometimes you need to put in a stop gap to deliver something high value, even if it temporarilly deviates from that vision. It sounds like it will be 1-2 years before all the products share the same platform, where-as enabling SAML for individual platforms based on demand would be pretty straight forwad and fill a massive void.

Also the more I think about it, why does consolidating all the products is a higher priority rather than enabling SAML on JIRA Software. Then migrate all the products to use the same mechanism. Getting all JIRA users to have SAML activated seems like a pretty big win. Having other products use the same user base can happen right after.