This is also affecting me. However, it seems that if I put the Jira internal directory first in the list of directories, then JSD creates the new user locally in the Jira directory and not in Crowd. This is a sufficient workaround for me.

I replaced the crowd with the keycloak.

This insane licensing scheme for Jira Service Desk when using Crowd is a megamonstrous nail in the Crowd coffin, but, hey Atlassian - it's your own choice to make   

Let me just add one more vote to this. With JSD and public signups enabled, using Crowd for authentication with anything other than the unrestricted user license opens us up to really simple denial-of-service attacks simply by registering a couple of accounts in JSD, thereby blocking new customer signups once the Crowd license hits its limit. 

Customers don't see Crowd as a single product; it's a piece of glue to tie other Atlassian applications together. Requiring a $10k+ license to enable proper SSO-based authentication for those products is insane from a business perspective. 

This issue will hit five (5) years. I don't think Atlassian will change it's mind on customers licensing with Crowd. The solution here will be to ditch Crowd completelly.

Hi, I think the same as Mohammed Amine.

Today I'm using keycloak as a customer manager, but sticking with the crowd managing operators and another system to manage customers is not feasible.

I am seriously considering migrating everything to keycloak and leaving the crowd.

I would prefer to get everything on a single platform from the same manufacturer, but if it is not possible, I am evaluating this migration.

It is really a must have. A client with 50 agents cannot pay for 500 clients ! Moreover if his customer base is growing it is really difficult to explain that he has to buy more licences for customers. No other service desk application is doing that. Please consider this suggestion urgency. 

Someone should take this issue serious...

Our organization just rolled out the service desk product on the premise that it would allow customers to submit requests w/out consuming our developer licenses in Jira, and while this is sort of true, since they are managed through Crowd this is not the case, this became apparent and painful to see as our Crowd licenses were unknowingly being consumed as new customers were signing up and consuming these licenses, as it stands we have 1 seat left after a day of release and to find this issue (which has been around for several years it seems is disheartening).  Please remove the dependency that customer accounts consume Crowd licenses, it is urgently needed and this will no doubt damage my advocacy of Atlassian products in my organization.

We've read in the latest Crowd release notes for 3.4 "We’re proud to present you SSO 2.0 - Crowd’s single point of access for Jira, Jira Service Desk, Bitbucket, and Confluence across different domains with one common login page." so I think that will stop the MIDAN Authenticator work around from being viable.
Our answer may be to go to the DC versions of the other products and use ADFS for SSO. As we can put as many customers as we want into AD and/or the local directory we may just have to drop crowd all together.

so i have now hit this problem. we only have 25 agents and over 2000 customers!!! still no fix!

I guess it should be easy to fix that, isn't it?!

Jira Servicedesk v7.12.3 don't start after the Integration of midan.

For anyone else who has only recently run in to this, ridiculous, issue; I have just made use of the MIDANAuthenticator courtesy of Alexander Sebastian Jost's comments back in 2016.

I can confirm the MIDANAuthenticator still works and I am using it with Jira version 7.7.0 and Crowd version 3.1.2

Instructions:

1. Set the JIRA internal directory to be above the Crowd directory on JIRA's user directories page.
2. Download the the midan-authenticator-1.1.jar from the github releases page.
3. Copy the .jar in to the [JIRA ROOT]/atlassian-jira/WEB-INF/lib folder
4. Comment out the CrowdSSO authenticator in the [JIRA ROOT]/atlassian-jira/WEB-INF/seraph-config.xml
5. Add a new authenticator:
   <authenticator class="eu.midan.MIDANAuthenticator"/>

How Atlassian still haven't fixed this is incredible. I guess people paying for crazy crowd licenses to accommodate all of their customers is a disincentive.

Another vote. It's misleading to promote 'free' users in one product, knowing any customers wishing to extend further use into the Atlassian suite will be penalised with additional undocumented fees.

One more vote for yet another critical "blocker" and "should be implemented out of the box" feature in a half-baked product sold to Atlassian customers.

There are many other requrests like this with 300+ votes left without response from Atlassian... they don't seem to bothered about it. The steep licenses pricing for users such as Jira or Agents is a justification for free Customers access.  Period!

Any movement on this Edward? It remains an issue for us and a complete pain to be forced to disconnect JIRA "Just" because we want to use Service Desk...

This feature is also a must have for my company. We run several Atlassian environments with different count of users (overall >15k) - and of course, not all of them are allowed to use crowd - and wanted to implement a superior service desk with JSD.

Well, we have to do this for the moment with Remedy (I see your dirty sneer), whilst this "non feature" is in place ...

Also a vote for the feature. This is required for smaller businesses to use JIRA Service Desk in combination with Crowd.

I don't get it that this isn't thought through in the basics when releasing JIRA Service Desk...

I completely agree with Timothy Harris.

Also, one more problem to consider.

You can edit a connection to a Crowd directory from JIRA when you are logged in with a local user. As soon as you switch to SSO, you turn off the local access. This means what I cannot edit my connection to Crowd unless I turn off SSO. This just does not work, even from the maintenance viewpoint, let alone that our customers (we are consultants) will say no to the whole Atlassian stack as soon as they find out they are forced to have licenses for their customers. 

Please consider reprioritizing.

I realize that Crowd is a different product, with it's own licensing. But the application is part of the suite of applications that Atlassian offers. As such most customers expect that the integration between them is pretty much out of the box. One of the strong selling points

The Service Desk scenario for customers is a bit of a paradox in this regards. Companies using Crowd and Service Desk do not expect to have to pay for customers in Crowd. There could be thousands. You could say that this breaks the concept of customers not costing anything but only agents. People don't really care that Crowd is a distinct product. They simply see the cost.

So I highly support this feature request. Allowing companies to use the suite of applications together so they compliment each other fully will help the suite as a whole and the overall bottom line. 

Okay . Then I will test the new release and hopefully not getting in trouble again .

JIRA Core / Software 7.2.3
JIRA Service Desk 3.2.3
Crowd version 2.10.1

Hi Alexander,

which Crowd version do you use?

We have updated the MIDANAuthenticator to version 1.1, using the new libraries (jira-api-7.2.4) and tested it successfully with JIRA 7.2.3.

https://github.com/MIDAN-SOFTWARE/MIDANAuthenticator/releases/tag/1.1.0

Hi Damian,

thanks for the detailed information so far . I got some Java exceptions when I used the newest Crowd version 2.10.1. 

Hi Daniel,

Yes, instructions are with the code. Package the jar, drop it in the appropriate directory and update seraph-config.xml then restart.

We're currently on JIRA core 7.1.8 with current service desk and software applications on top. Crowd is version 2.8.3.

If you build it with Maven edit the pom.xml to specify your JIRA version. It defaults to 6.4 . The code may not be all that specific to the version, but I think it is safest.

Hi Damian,

which versions of JIRA, JSD and Crowd do you use? And you just package the jar for MIDAN Authenticator?

Hi Johnathan,
I am trying out the MIDAN authenticator and it does look like the best solution. Trying to use Crowd for both the free customers and the real Jira users introduces too many complicating issues, particularly in my case with delegated auth in Crowd. I don't know why Atlassian can't roll the same code into their version of the seraph authenticator for Jira, but it works.

This is stopping our firm from purchasing Service Desk. We're a consulting software firm, and we'd love to use SD for customers to input bugs/enhancements/etc. rather than trying to train every customer on JIRA Core/Agile, but we also use Crowd for SSO. If I could get the "free" users for Service Desk, we'd likely purchase in a heartbeat. This limitation is a complete showstopper. Unbelievable that Atlassian did not consider this when they built out Service Desk.

Not part of the cloud offering. Not core. Nobody at Atlassian is listening.
Look at the MIDAN authenticator for your solution, it is really easy to setup. If you are waiting on Atlassian, your retirement or Crowd end-of-life announcement will probably come first.

This is a show stopper, this is not IssueType "Suggestion" but a "Bug"

Oh my.. just encountered this issue.. this is bad..

So this is still an issue your customers are unhappy with after a number of years. C'mon Atlassian!

Here is another use case for you. We use Crowd with a delegated authorization directory (AD) so only our staff that need access to Jira and Confluence are counted in the license and SSO integration between atlassian products works nicely but they don't have a local password. Up until adding Service Desk into the mix that was great. Now my first problem is people signing up as customers using their email address as a login ID won't be in our AD system and you can't set a password from Jira (which is good) so while it created an account in Crowd they cannot log in.
I solved that by adding an internal directory in Crowd so they are created there and can set a password while regular staff are provisioned from AD automatically when trying to log in the first time (though an admin needs to grant them the right groups for access to the applications so we still control the number of licensed users). That fails though as we do user maintenance via Jira, so adding a new user there and selecting Crowd as the source doesn't let you decide which crowd directory to use, so it ends up in the internal one which doesn't use AD for passwords. Defeats the purpose then!

We also have the issue that we could easily hit our 500 user limit by having to include customers that are supposedly free in Service Desk. You should really have this caveat spelled out to people before they purchase Service Desk. I'm in a tight spot now having told managers that there was no more to pay until finding this out. You've made great progress changing the license mechanism in Jira so that the agile product (now Jira Software) is counted by group membership instead of having to match the level of the base product. Now please fix this!

Beginning to wonder what the value of Crowd actually is?

We have also encountered this issue; We use Crowd to handle authentication for our Jira, Confluence, Bamboo, Bitbucket Server and Fisheye users. We have different groups of users accessing each product and each product is licensed differently according to our requirements. To enable SSO we use Crowd. We have less than 50 users that need to be licenced across all products, so a <50 Crowd licence is sufficient.

We invested in JIRA Service Desk partly on the basis that Service Desk Customers were not included within the JIRA licencing. It was not made clear that the the customers would consume a Crowd licence.

In order to allow us to use Service Desk as advertised we will need to either spend substantial additional $$ to upgrade Crowd, or migrate all our applications and group management into Jira. Neither of which is acceptable Atlassian sorry.

As somebody else further up commented... this is not about trying to rip off Atlassian. This is about using the products the way they are advertised. Service Desk has been challenging since v1 but v3 looked like it was maybe getting somewhere...until we discovered this user count issue.

Atlassian, please listen to the voice of the customer here and give us a workaround that allows Service Desk to operate as advertised. Thanks.

Sure, take a look at: https://github.com/MIDAN-SOFTWARE/MIDANAuthenticator

Can we use MIDANAuth without restrinction?
I want to keep sso activated and use customer on local jira directory

Thank you, we merged your pull request and added the tested jar file as release download.

I've just tested the MIDANAuthenticator and it appears to work as expected. From looking at the code, I can't see how it could expose any security risk, so looks to be a good solution. I looked into doing this myself in the past as figured it would be a simple IF statement, but didn't have the time to set-up a JIRA development environment.

I've submitted a pull request on the project to mavenize it, should make it easier for future contributors and you can simply copy the single packaged JAR into atlassian-jira/WEB-INF/lib rather than the .class files. The owner should probably publish the JAR to make it easier for those with zero development background.

Atlassian should really take notice of this and build it in.

We are no Java developers and made it October 2015 in less than two hours to solve our own dual authentication problem.
It was just a fast and simple solution to use the classes, so why "jar via maven"?

Cool I'll have a look - but why classes and no jar via maven?

Take a look at our custom build authenticator: MIDANAuthenticator

biggest problem imo was that this interaction between Crowd and JSD isn't so easy to find info about....at least it wasn't during the time I had to tell my clients the bad news

Bump ^
I keep forgetting about this and it is a source of frustration for many of my/our clients. Crowd needs some major <3.

Simply ridiculous. Crowd and Jira and confluence are all Atlassian products designed to help software development teams communicate and plan software development. It is billed as a tool to help unleash the potential of development teams... "Our software helps unleash the potential in every team". It is shameful and should be embarrassing for Atlassian, a company that promotes itself as an expert in intracompany communication for software that they develop to have such a core incompatibility with its own product. Why should any development team trust that Jira will deliver what Atlassian promises when it has clearly failed to keep Atlassian's team on the same page.

Simply CAN'T use (and therefore buy) JIRA Service Desk because of this. Disabling SSO is not a fix and requiring a Crowd user for every service desk user is also not a feasible solution. Atlassian product teams need better communication and dog-fooding! Do Atlassian not use SSO in-house?

Also, regarding the comments about Crowd being a separate product... In this case we're not even talking about a separate product. The Crowd SSO authenticator is bundled WITH JIRA, it is part of JIRA, not Crowd! This falls on the JIRA + JSD side and they have opted to only EITHER support internal authentication OR Crowd authentication, they lack the facility to have an authenticator that can provide both.

I was going to spend my own time to develop my own Authenticator.

The Atlassian SSO Authenticator is easy to decompile. I was surprised at how small it was. I was then going to implement the Authenticator class by wrapping the SSO authenticator and the standard authenticator:

// Some comments here
public class MyAuthenticator extends Authenticator
{
    public class BasicAuthenticator extends Authenticator {
    }
    public class SSOAuthenticator extends Authenticator {
    }
 
    public boolean authenticate() {
           sso = new SSOAuthenticator();
           if (!sso.authenticate) {
                  standard = new BasicAuthenticator();
                  return standard.authenticate();
           }
           return true;
    }
}

This is really really bad pseudo-code and doesn't properly reflect the API or class inheritance, But you get the idea. I just never had the opportunity to sit down and write it.

Maybe one day. Or maybe someone with some time can get this done? And share on Github so we can all download the class and then update the seraph file to use it?...

More than 8 months and this still hasn't happened?

So our choice is to lose SSO entirely, or burn a Crowd license for every service desk customer. Wonderful.

I agree, even if we accept Crowd as a completely separate product, it should not be allowed to cripple existing capabilities. Using self sign-up with single sign-on simply does not work. This is not something that can be labeled "by design".

I just don't get the argument that Crowd is a separate product, it's an Atlassian product, part of your integrated technology stack, and it's a common use-case to find Crowd and JIRA in use together - they are designed to be.

This is a big problem, and makes for it an expensive option for a service desk add-on.

This is definitely the big one:

3. There should be a way to log in as a local user when Crowd SSO is enabled (this is the big one!)

And get my vote... Atlassian, please understand we are not trying to rip you off here, this is a usability issue affecting real users.

This is crazy! I have a problem with Crowd sync right now and I want to try a full sync to do so. This problem creates a chain of dependencies several layers deep:

1. For force a full sync, I need to be able to "Edit" the Crowd directory.
2. To edit the directory, I have to be logged in from another directory.
3. To log in from another directory (like the local one), I have to enable the local Administrator account (or create a local admin account), which is not normally enabled
4. To log in a local admin account, I have to disable the Crowd SSO authenticator.
5. To disable the Crowd SSO authenticator, I have to shut down the server and restart it, creating downtime for my users while I muck about in the deep XML files.
6. Finally, after all these steps, I have to go all the way back into the settings, edit the directory, disable incremental sync, perform a sync, reenable incremental sync, shut down, edit the XML file again, and restart.

This is a pretty silly chain of dependencies. There are actually several things that need to change here:

1. There should be a way to force a full synchronization of a directory while logged in via that directory.
2. There should be a way to edit some of a directory's settings while logged in via that directory.
3. There should be a way to log in as a local user when Crowd SSO is enabled (this is the big one!)
4. Enabling Crowd SSO should not require editing an XML file.

I just like to send a ping, because we run into the same issue - for the moment we deactivated the SSO - but that isn't a solution.
Maybe somebody already wrote an authenticator for this external?

Please let us know how that ends up working for you James.

I guess it's time to implement Jasig CAS. About to abandon Atlassian Crowd ... I haven't tried it, but perhaps the Jasig CAS plug-ins will also allow for Internal Directory authentication? It's a long exercise just to find out...but might be worth doing....

One of the issues with Jasig CAS is I don't think there are plug-ins for Stash and Bamboo. The blogs just talk about Jira + Confluence + Jasig CAS

https://wiki.jasig.org/display/CASC/Configuring+Confluence+with+JASIG+CAS+Client+for+Java+3.1

https://wiki.jasig.org/display/CASC/Configuring+Jira+with+JASIG+CAS+Client+for+Java+3.1

The comment by Edward in JSD-923 is just so far out of touch with customer needs its not funny.

I have a 50 user crowd license. I have about 30 users in Jira. I have Service Desk/Stash/Bamboo/Portfolio/Agile/Confluence/Questions/Clover/Capture and about a dozen other Plug-ins and add-ons from Bob Swift, Camola, others. This is a SERIOUS amount of money for my firm. I mean...it takes a HUGE dent. At least a full FTE or greater!

Edward, asking me to upgrade Crowd to $8000/year just to support my customers and provide an SSO solution for my staff is not an option.

I agree with Spencer, how long will this take? I don't want to have to buy crowd for $1,200 if they are going to fix it in a month or two.

Our service desk customers (public jira registration) can't log into jira service desk because we are using crowd... This is a big problem!

The ability to use a combination of Crowd and local authentication is exactly what is needed so long as local authentication can be restricted to certain user groups such as Service Desk Customers.

If I'm a Crowd user please tell me how I can enable "Public signup" for Service Desk customers if you don't intend to fix this in the next 6-12 months?

... Should I ask my customers to wait?