We are evaluating the Atlasssian suite for our company: This is an absolutely mandatory feature. If we are going to purchase and standardize on Atlasssian, we need single sign on. It's not feasible for us to manage multiple accounts across all of the different platforms out there.

It's really disappointing, I am going through a tech. solutions analysis for a client right now and including Atlassian...honestly I was totally surprised when I saw that this was still lurking around. I remember seeing this talked about maybe 3 years ago...thought it would of been implemented by now. Guess not!

I along with a lot of other people are really disappointed in Atlassian and I will no longer be evangelising their products. I'm mean really, 5 years and 200+ votes and it's not on their radar. It's really quite laughable.

A lot could of happened in 5 years, LDAP should of been one of them...

@Kimmo - I wouldn't hold your breath. 5 years is a doddle waiting for features. Sometimes regression issues take longer to resolve.

This is also a barrier for us using Service Desk or Jira more extensively in our organization. Without this capability, Jira will remain a small PM tool rather than a systemic issue tracking system. Please add this feature ASAP.

We need this feature as well, must be soon coming as been cooking so long

Bye bye Jira... Welcome Zendesk...

How is this ticket 5 years old. There is a huge need for this - please reevaluate the integration with this feature...

Brad, unfortunately we're doing the same thing. The only thing I can't figure out is client facing solution support, but then my customers can't figure out JIRA OnDemand either, and HelpDesk OnDemand just doesn't have the flexibility to work.

Report back here to let us know what you find. I'm talking to Microsoft to get pricing for cloud-based TFS. Better at some things, not as flexible with other things, but it looks like they have the simple things right. I'll probably move away from Bitbucket while I'm at it.

Yep. Tired of managing an on-site instance of Confluence. Have been waiting for something similar to this feature so can move to On-Demand. Been a customer for many years. Time to look for another solution and take my $$$$$ elsewhere.

I about threw up yesterday when I saw the message notification from yesterday...I don't have a leg to stand on when it comes to convincing other departments and divisions to use Atlassian within my org of 3,000. Atop this basic need, I can't even get powerful add-ons in the marketplace because of my decoupled SaaS instance. Sucks.

Atlassian used to be such a leader, but now it appears to be falling way behind. Seriously, SAML and LDAP integration isn't even difficult.

The user banding levels on OnDemand show an intent to target larger organisations than just start ups. I concur, Jason, the more my business grows the harder this mess gets to manage and the more my users give up on it, and the more I give up on it. SharePoint Online from Office 365 has de facto taken over a lot of what we used Confluence for, and you know what? It IS easier for my end users, and it's actually easier for me to administer. I feel like burning my keyboard after typing that, but it's a changing world!

It appears that Atlassian is focusing on individuals and small companies. The problem for the medium to large companies is that none of the Atlassian products have effective management of large amounts of data, particularly relating to administration. The more I use the Atlassian tool chain as an administrator, the more disappointed I am. This is just another example of how Atlassian is failing to standup.

Exactly - in today's age of SaaS computing, what modern enterprise system does not have integration with LDAP? Atlassian - this is unacceptable and quite embarrassing for you. Tells me there is some serious flaw with your architecture that your engineers are unable to solve.

Might be time to look at other tools. The cloud-based TFS is coming along now that they are general release. Time to take a fresh look at the marketplace.

I assume this means that effort is instead going into finding new ways to make people buy things from the Marketplace, or confusing end users with banner messages about "Try our new feature!"

God forbid you'd want to make Atlassian OnDemand EASY for Enterprises to adopt and maintain!

Kevin, be patient, the issue was only created 5 years ago!

What is the status of this feature? It appears to be stuck on Accepted, but with no real progress

Daniel, Atlassian don't appear serious about doing anything that would allow enterprises to use their stack. This issue, the stupid rounded logos issue, the inability to fix the integrated search function - it's regressed and Atlassian aren't keeping up with my companies growth. They don't even bother contacting you when you show public dissent or contact the CEO's office saying you are going to move your business elsewhere. My advice - don't bother.

Is Atlassian serious about solving this problem, and if so, what is the projected timeline? My company really wanted to use ondemand, but not being able to use our existing LDAP authentication is a major roadblock with our IT department.

@Paul Alexander this is correct. Therefore I am recommending to Atlassian to just buy the whole company and integrate the module by default. Buying might be cheaper than producing.

@ Manuel Blechschmidt: That SSO plugin only appears compatible with local installations (not atlassian on-demand)...

I've created a separate request regarding SAML support: AOD-7183

There is already a SAML 2.0 implementation in JIRA marketplace:

https://marketplace.atlassian.com/plugins/com.resolution.atlasplugins.samlsso

@Atlassian: Just buy the whole company (resolution Reichert Network Solutions GmbH) and make it a default plugin in JIRA

When will this be released to the public?

Yes please...would love an update from Atlassian on this...SAML 2.0 is my target as well.

Any ETA on when this will be implemented? This has been requested non stop for a long time.
SAML 2.0 specially.

me too!

We would like to remember only one password: the user AD account/password.

thx

We are a small company, but this would help particularly for those people who only use the system occasionally; remembering another login is just a pain for them.

+1 here would love to see ldap integration. We are currently an OnDemand customer as our business has grown having to maintain 2 different user sets has become a task.

We are would also be interested in moving to onDemand but lack of SAML 2 support is an problem for us as we cannot integrate with our identity management solution

Our organization is contemplating moving to OnDemand, but the inability to centralize user management is making it incredibly difficult for us to recommend moving out of self-hosted.

We have multiple Google Auth domains within the same account, and only the primary domain is supported so we cannot have two factor authentication for these accounts. We also have external contractors who require access and without SAML (or buying a Google apps account) we cannot facilitate their access.

We love OnDemand but are frustrated that we have to maintain different userid's and passwords - hooking in to an existing SAML idp would be fantastic - without this there is no way we can scale our use and ODemand will remain a minority app

We are using Office365. It would be awsome to see SAML support to create a federation.

http://technet.microsoft.com/en-us/library/adfs2-step-by-step-guides(v=ws.10).aspx

outlook.office365.com

Unfortunately, we will have to drop our Atlassian OnDemand service in 2014 without this functionality. I'd like to get a sense of the implementation timeline for this.

SAML, LDAP, or integration with AD would all be options we'd consider.

We're doing a PoC of the On Demand product and the ability to centrally authenticate users is a must have. Ideally, this would be through SAML. I'd be happy to "manually" create/remove users as along as there is an API through which I can automate this, but we'd need to be able to use our email addresses and central password store.

Would love to be able to integrate this with Azure Active Directory!

As we need the LDAP integration with OnDemand, I would be willing to be beta tester.

This one have 83 votes now! How many votes Atlassian need to prioritize this functionality? This is indeed crucial for us too.

I wanted to consolidate my wiki and jira together with 500 users, but I can't even consider this route because of no SAML support. Please reconsider to put this back on.

We would use either LDAP or SAML if offered

SAML

SAML

A solution similar to Google Apps Active Driectory Sync and Google Apps Password Sync would be what we're looking for. Having OnDemand access our LDAP directly would not fly for us. We'd need to push accounts and password hashes into On Demand on a scheduled basis.

For larger demands, you're better off partnering with an Expert vendor. Still would like to see some effort towards SAML, like Zendesk and other like-minded cloud vendors offer.

Please provide an LDAP solution. It can't be that hard to create a read only AD connector can it?
Now more and more users migrating to OnDemand, this is a feature you just can't do without.

Fons

I recently worked with a 12,000 seat company that was planning to utilize Confluence onDemand. The lack of LDAP or SAML required us to look at hosting externally or internally.

We eventually went with an internally hosted Confluence instance.

We are similar if a bit smaller: 2,000 employees with only a couple of hundred on the system because of this limitation.

Similar for us 35,000 employee's but only using a 500 person license due to audit requirements around managing user id's etc.

~17,000 employees. Currently at only 500 licenses because there is simply no way we could roll out Jira/Confluence OnDemand without SAML-based SSO. Even with our limited users it is an audit finding waiting to happen, that we have an open account for someone who has left the company. It is frustrating that we're being pushed to run the products ourselves because of this gap and the better but still not good enough password policies in OnDemand.

Large organizations (at least in Norwegian scale): Norwegian Broadcasting Corp. (3700 employees)

Agree with David. SAML, or any similar protocol, is what Atlassian needs to implement. As to why they don't implement SSO, however, I don't know if it's because of technical complexity or lack of general demand by their market – or, perhaps, some of both. I think that larger organizations, however, are going to require this. It would be interesting to know how many large organizations are currently using their OnDemand service.

Having a multi-tenant cloud environment constantly calling back out to thousands of customer's internal LDAP environments is not something I think they want to be in the business of doing. There are security concerns (customers would have to expose their LDAP to another company), infrastructure logistics (customers would have to open up firewalls or setup VPN tunnels), not to mention performance ramifications making LDAP calls back out over the internet to customer locations. I understand other companies do it.

Really, this issue should be about supporting something like SAML.

Since the installed version already supports integration it doesn't seem this would be hard to implement and support. What are the roadblocks?

Yes, we must need SAML based solution. Crowd (ping identity) is unsecured and not acceptable for my company. Need to prioritize this critical request.

Guys
We are getting pressure from our internal audit guys to tighten user management, which for us is via AD. You are going to force us to move elsewhere.

David

You can host Jira with Contegix and use OneLogin for your SAML auth.

Sent from my iPhone

On Jul 23, 2013, at 8:35 PM, "John Gill (JIRA)" <jira@atlassian.com<jira@atlassian.com>> wrote:

https://jira.atlassian.com/secure/useravatar?avatarId=10612 John Gill<https://jira.atlassian.com/secure/ViewProfile.jspa?name=john.gill%40westernpower.com.au> commented on an issue

Also this issue was created in 2009. Come on Atlassian... how about a solution.

Atlassian OnDemand<https://jira.atlassian.com/browse/AOD> / [Improvement] <https://jira.atlassian.com/browse/AOD-1837> AOD-1837<https://jira.atlassian.com/browse/AOD-1837>
Support LDAP integration with OnDemand<https://jira.atlassian.com/browse/AOD-1837>

[Add Comment] <https://jira.atlassian.com/browse/AOD-1837#add-comment> Add Comment<https://jira.atlassian.com/browse/AOD-1837#add-comment>

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA logo]

Also this issue was created in 2009. Come on Atlassian... how about a solution.

Implementing SAML is a must have requirement for serious enterprises. We also have regulatory and insurance related clauses that require us to terminate access immediately. Cloud based solutions that do not support SAML not an option.

I would support the comments above stating that without SAML (preferred) or LDAP integration, OnDemand is hardly enterprise-ready.

Hi,

We're experiencing an increased demand for Atlassian (or its like) products in Norwegian Broadcasting Corp.

As the owner of our 500 user installation (Jira+Confluence), I'm afraid we at some point have to leave the OnDemand service to migrate to some other cloud driven product that supports authentication to our own LDAP solution, as we cannot expect an increasing number of users to accept different user/pass.

We therefore strongly encourage Atlassian to add support for multiple user LDAPs including our own MS AD on the OnDemand product.

BR
Vegard Storstad

Also agree with the above statements. My company would be interested in a number of Atlassian products from "OnDemand", but cannot really consider this because of the inability to synch identity information. Is this feature on the product roadmap for "OnDemand" and/or Crowd?

I agree with the above statements. My company is also looking for SAML supports before considering upfront Greenhopper on SaaS mode.

This is a must have for my company to expand our use of this product,. Since this is not tied to our LDAP we cannot control access when someone leaves, we need to be able to shut them down immimediately, it is a regulatory requirement.

This is a deal breaker for my company, I can't even begin to bring this up to my executives without that sort of integration.

LDAP integration in the direct sense will not solve my companies challenges with managing accounts in OnDemand, we'd never expose our directory across the public internet. SAML would be ideal, or even a REST or SOAP interface of some sort so we could write our own integration would at least be something. The key from an audit perspective is that when an employee leaves and their directory account is deactivated, we need the OnDemand account deactivated as well, relying on a manual step is a liability.

On behalf of a customer:

In order for Confluence to be used as a hosted solution, we need LDAP integration to be solved for this to be possible.

Having either LDAP or SAML would be a great addition to your on demand product! It's a must from my perspective.

This is a deal breaker for my company, with 15,000 people, I can't even begin to bring this up to my CIO without that sort of integration.

From some conversations it looks like something like a REST point to create/disable users is the bare minimum in absence of LDAP integration.

Hey Mark,

Sorry for the delayed reply.

We haven't moved off Google Apps (we still use it for our mail, calendaring etc), but have moved to Crowd for our directory and identity control.

Being unable to link the OnDemand suite to our own Crowd server meant that users had their Crowd ID, as well as their Google Apps ID. We moved Google Apps to auth off Crowd, so OnDemand was the missing link.

We moved OnDemand back to an on premises install, and haven't looked back.

Cheers,

Michael

Thanks for the recommendation Matt!

@mark.hursh I advise clients with the same requirement to go with a hosted solution, typically Contegix.

This is a serious deficiency in the product. Your competitors have this capability.

I just had to advise a client with 5,000+ potential users interested in Confluence OnDemand that they needed to look for another tool due to this missing feature. Now we have to look at competitor offerings when Confluence had already been short listed.

Michael,

Interesting. I haven't seen anyone move off Google Apps before. Any reason you can share?

~Matt

You can't connect On Demand to any directory service aside from Google Apps or its internal directory.

If you move your On Demand to an on premises you can connect the apps to your on premises Crowd, which is what we're considering doing (already running Bamboo, Fisheye/Crucible behind the firewall, so moving JIRA & Confluence back with them isn't the end of the world and would mean we can integrate with our own Crowd server).

This has been on my wish-list for ages. Also SAML or OAuth2 would be perfectly fine solutions for me.

@Michael Shimmins, so: on premises is also no option?

We've just started the process of migrating away from Google Apps as our directory/SSO provider to a BTFW Crowd instance. Most of our apps are now authenticating against it, was really shocked that OnDemand doesn't support it.

It is pretty important for us, especially as we start to scale, to streamline user access and accounts. We thought that an Atlassian solution to this would work with all Atlassian products. Quite disappointed to discover that OnDemand is the exception.

For us this is almost worth moving our JIRA/Confluence back to on premises shudder.

Anything more happening on this? SAML (Shibboleth support) would be extremely useful to us for OnDemand, but LDAP integration would at least be a start for enterprise information.

Would this functionality include interfacing with a local instance of Crowd?

Our userbase in JIRA Studio is growing and growing and I'm afraid that we will run into serious trouble if we can't manage to connect it to one of our internal user repositories! Please come up with a solution, I don't want to be forced to step back to an onPremise solution just because of that small but essential missing feature...

II am shocked and saddened to see ATlassian still hasn't addressed this isse

We are implementing JIRA Studio at an enterprise level and not having any option to integrate with AD or any other external user security system is dragging us down!

We have 525 licenses and expect to grow more! Can't keep creating users manually in JIRA Studio!

Can this functionality be implemented as soon as possible?

My management can't believe JIRA Studio, which is marketed as an Enterprise solution isn't capable of integrating with AD or through Crowd to AD!

Cheers
Khaseem

Good comparison of SAML and OpenID here http://identitymeme.org/doc/draft-hodges-saml-openid-compare.html

To throw my two cents in, LDAP is okay for enterprise security integration, but SAML is a much better option for SSO. Many enterprise Sys Admins are reticent to publish there Domain Active Directory on the public internet. Most large companies already have SAML integrations for Single Sign On - which is what Salesforce.com uses and Google Apps. To offer support for most popular security mechanisms, the Java Framework Spring Security (formerly ACEGI security)is a stable, robust, and supports pluggable authentication modules to allow Local security, LDAP/LDAPS, SAML, OpenID, x509, and more. By making this the core security framework you could support nearly everyone's preferences. http://static.springsource.org/spring-security/site/features.html (I am in no way affiliated with SpringSource or its affilitates - we have just had good experiences with this product).

A note to those watching this ticket - we are still attempting to identify a workable solution to supporting LDAP in Studio. While we hope to have a solution long term, I do not expect that there will be anything in the next couple of releases that help with this.

Thanks for your patience,

Michael

Needs to be fully tested before we can declare public support

This sounds like the features are already developed and are now waiting for testing. Is that really the case?