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.

I'm very familiar with Crowd and have used it in the past, sadly it does not help... as you've noticed.

@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

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.

I stated this earlier in the thread, but I did open a new CEO message last week. The response to it as of 2/24 from their support team was:
"I have relayed your message to the appropriate parties to provide further insight into ID-80. You will be hearing from a Product Manager to provide you with an update on the status of the feature request."
As of 3/3 no feedback to either this thread or the CEO support ticket CEO-2586.
I hold out hope that eventually the product manager will reply to this string and the delay is due to them thoroughly evaluating the request to get us accurate information #optimist

@Shane Day

Nevermind then, I got an email today stating that there was something added to it, and thought it was the CEO link.

The email came in around 12:09 PM from Elisa Diel [Atlassian], with the message: https://support.atlassian.com/browse/JST-185547

So nevermind.

@Andrew Doering - the CEO ticket has been linked for about a year. Don't hold your breath.

We implore...

So now there is a CEO ticket, but we are unable to see it... so I guess that is some headway.

Go retweet @Erik Segerstolpe tweet +1

The case for LDAP integration (https://jira.atlassian.com/browse/ID-79) was opened in 2009. That was 7 years ago and still nothing.
Just setting some expectations for you all...

@john.colburn It looks great. We requires a SaaS solution but we need SAML to support seemless SSO for users who are on-premises, as well as MFA for those who are mobile/remote. We are planning on storing sensitive information so we can't rely on only username/password for an internet facing platform.

John Colburn,
Are you serious, maturing? In 2014 we were promised this, heck when we got it the rep told us "oh yeah SAML will be ready by the time you go live", that was YEARS ago now!

@bchristian Confluence is great and if you have an organization that is scaled to a level over 2000 users or SAML is honestly and truly a must have feature for security or other reasons you're better off hosting yourself. It's a great product but the cloud versions are still maturing.

well I started with my part - and keep a positive attitude, more will happen then let's hope he replies

As a potential customer (not existing) it's good to hear everyones feedback. I think I'll steer clear of using Confluence and keep looking. Thanks!

@ehruska No idea. I would have guessed this ticket would be linked/blocked by other tickets that focus on shared user base.

Takes a good amount of effort to do all the appropriate linking and Atlassian probably hasn't gotten around to it. Maybe they will link more issues to this ticket when they've made more progress and can see the light at the end of the tunnel.

Guys, I've tried the CEO link, got no response. I've tried social media, got no response.

I strongly suspect the CEOs are laughing all the way to the bank at present, and the existing user base is the least of their concern.

Personally, I've had a gutful of serious usability, administrative or security issues being unaddressed, or in the case of Cross Product Search, regressed into being totally unusable. Everyone in our organisation hates using Atlassian Cloud these days. The only good thing I have to say is that the Atlassian Cloud support team are awesome.

@IT Admin in that case shouldn't they link what they are currently doing to this issue? They track everything via issues even internally. Why aren't those related issues linked to this one in order to avoid a distraught customer base?

Perhaps we make a concerted effort to publicly shame them on twitter on this issue? @atlassian #showmethesaml

Well then, if we are all in the same boat, and no one from Atlassian is listening here, I think we need to go bigger. Anyone game for some good old fashion "use the Internet as your megaphone"? I am sure between us all we have plenty of contacts to get this issue published on some sites of note.

I doubt Atlassian has anything to add to this thread at this point.

They laid out the plan to support SAML in the description of this ticket and it's hard to show on roadmap since it involves all their products going to a shared user base. The SAML enablement step that would come after the shared userbase is complete is, in comparison, easy.

One thing I don't understand is why they can't work on introducing SAML for just cloud JIRA/Confluence since they already have a shared user base.. unless what's currently being worked on is actually a whole new way to manage users.

Given the description on this ticket, I'd expect BitBucket to become part of the shared user base as a milestone before we see SAML.

Would be nice to get a clear picture of a roadmap towards getting SAML. Even if it was a 6 month to 1 year timeline at least it would lay out what the remaining pieces are.

Also, I don't feel like anyone from Atlassian is monitoring this as:

Assignee: Unassigned
Reporter: dwierzbicka Dora Wierzbicka [Atlassian] (Inactive)

I see that this is still Verified and not In Progress. I would like to see that status change soon Atlassian. This is obviously a huge issue.

It would be comical if it wasn't causing my org so much pain.

I agree. Clearly a key issue with a crazy lack of response for an enterprise level item. I took the initiative to push this thread into their "connect with the CEO" form which states it will be read. We should see soon if anyone at Atlassian cares about losing business during product evaluation and supporting their clients as their volume scales.

Is anyone from Atlassian even looking at this thread anymore? I mean this is getting seriously ridiculous.

I agree Nick. We haven't signed for up Confluence yet due to lack of SAML support, and like your comany, we have a hard requirement for all new SaaS deployments to use SSO via our IDP. We recently migrated away from a SaaS platform that had no SAML support because they were unable to provide a roadmap for its implementation.

Sean Byrne,
Unfortunately, I don't think the announcement about Atlassian using Splunk for their Ops/Security needs is going to translate into SAML support in their cloud products. Nicely done, reigniting this discussion though.

Atlassian,
I think you guys/gals should do a better job managing your customers expectations with regard to timing. I know, in Agile, we don't want to commit to dates, and that's likely what's driving the silence (in addition to PMs not reading comments like this). However, as a customer, it's starting to feel like the only way we can communicate the importance of this feature is through lost sales opportunities and cancelled renewals.

As a data point: We have a security product that ensures that SSO logins through our IdP may only be initiated from authorized devices (the device itself is the second factor). We have put a moratorium on all new services that can't support SAML through our IdP. At the moment, we're not applying this retroactively, but at some point we are going to start discarding services that can't help us meet our strategic security requirement. Atlassian, are you listening?

Matijs, we are on the same boat, we already own TFS and that is been pitched as an alternative (specially since we already pay for it). I really like JIRA much better. Hope this issue gets resolved sooner rather than later.

It would be great if this is implemented, we really need this. On-premise is no option for us, and the number of user account is rising.
Some voices in our company say we should look at solutions other than Jira Cloud.

I wouldn't hold your breath.

Hi,

This was in the news the other day:

http://www.splunk.com/view/atlassian-adopts-splunk-software-for-security/SP-CAAAPHT

I'm wondering, in the light of this news article, will SAML integration happen since Splunk has SAML support:

http://docs.splunk.com/Documentation/Splunk/6.3.3/Security/HowSAMLSSOworks

Sean