-
Suggestion
-
Resolution: Unresolved
-
None
-
4
-
27
-
NOTE: This suggestion is for JIRA Service Desk Server. Using JIRA Service Desk Cloud? See the corresponding suggestion.
Problem Definition
In certain cases, Service Desks need to be restricted to a set of customers belonging to one and the same organisation.
Public signup does not provide a proper means to prevent incorrect customer accounts not belonging to that organisation from being created.
The only alternative available right now, is to disable public signup, which has as a result that the Service Desk administrator can get presented with significant amounts of work solely for account creation.
Suggested Solution
As such, being able to define an email domain as requirement for public signup, can provide a small degree of safety, while at the same time prevent a lot of overhead for the administrators.
For instance, if a Service Desk has public signup enabled, and an email domain has been defined, the Service Desk will only allow account creation if the source address conforms to the defined domain.
- is related to
-
- Gathering Interest
- relates to
-
- Closed
- links to
- was cloned as
-
SUCCESS-1043 Loading...
| Form Name | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
[JSDSERVER-3669] Allow email domain restrictions for public signup
In our case we have 2 Service Desk configured.
Service Desk 1 is for External Users to submit issues regarding our Product, public signup is open.
Service Desk 2 is for internal users, to prevent external users from seeing the issues (or submitting issues) the only way we know of to accomplish this is to restrict it to Customers in an Organization. What we need is instead of having to add each and every user to the Organization just whitelist a domain, then anyone with a specific domain will be a customer in that organization.
I'm not seeing a difference between this request and another that is resolved. (https://jira.atlassian.com/browse/JSDCLOUD-868) One is cloud and one is server, but it states that it affects both.
This has been available since May 2022, though my apologies if I'm missing a detail in this one that isn't included in the update.
This is highly needed, having to add customers 1 by 1 is time consuming and prevents adoption of Service Desk by the user base. All the suggested work arounds do not work for us. A simple *@domain.com allow would solve the problem.
All we need is to be able to whitelist email domains on user sign-up and if the user provided mail address not a member of a whitelisted domain, provide some pre-defined "sorry, you are not authorised" message.
I actually can't believe this ability doesn't exist. Jira - do you have any idea how much of a headache this limitation is operationally?
...to give you a sense: the current alternatives offered are operationally labour intensive and pervasive enough to make us consider starting our service desk on a different product.
Hi,
it would be great to have public signup in Jira like it is in Confluence: a white list of email domains (our company and certain customers) which can signup by themselves not requiring a Jira administrator to do it for them.
We have linked our Confluence datacenter to Jira user directory.
If we let Jira handle public signup we can have Jira apply default groups to each new user - the same as if the user was created by an administrator. But Jira at this time cannot constrain public signup to administrator defined email domains.
On the other hand, if we let Confluence handle public signup we can constrain this to administrator defined email domains. But we are missing automaticly assigned default groups on signup in Confluence.
We have also looked into a possible purchase of Crowd. But from the documentation I read, Crowd has no public signup functionality of its own. So public signup from Confluence or Jira needs to be used - with the same results as without Crowd.
For us this is a mess which prevents us from public signup entirely.
Is there any solution?
Best Regards,
Lars
Ensure for every customer coming to portal for sign up - the domain blocking should be remembered while allowing customer to do sign up.
for any domains which are not listed. It should call out that please login with valid domain id.
This way, the admin, setup responsibility is not custom made rules / automation which is not consistent from scalability point of view.
if the whitelisted domain is given just reject user creation and prompt them for additional CAPTCHA or other such challenges to avoid any DDOS
PS: Ensure this solution is given across to Server, DC, Cloud solutions
-Vijay Mane
It's rather shocking that this has not been moved on by Atlassian in 4 years!
We also need this feature, but operating as more of a whitelist.
For example, we want to allow public signup via email for selected domains (i.e. those of our customers), for example:
- domain1.com
- domain2.com
Here's how it would work. If we get an email from anyone at these domains, an account should auto-magically be created (if it does not already exist). If email confirmation if turned on, they would still have to confirm their email.
This REALLY should've been implemented from the start, the ability to restrict which email domains are able to create accounts and raise tickets as it would be a very basic method of spam prevention. As of adding this comment the request has been open for 3 1/2 years. Is there an update for when we will see this?
+1 vote. We need this flexibility, as we are providing support via JSD to 3 large companies that are competitors of each other, and the TIME it takes to allow 1 user at a time per JSD project is crippling.
If we could allow access to JSD portal by group / domain name i..e. @companyname1.com vs @company_name_2.com > this would make much more sense.
Joshua Harris
added a comment - we are validating JSD also - and this might be the deciding feature to go with Jira or another product.
Joshua Harris
added a comment - we are validating JSD also - and this might be the deciding feature to go with Jira or another product. 
nprasad
added a comment - +1 vote. This feature will alleviate some security concerns and will make the system more fluid where authorized domain users can still register on their own.
nprasad
added a comment - +1 vote. This feature will alleviate some security concerns and will make the system more fluid where authorized domain users can still register on their own. This really is a must - without it, there is a lot of admin to do setting up accounts. With the public option off, then new ticket requests from clients without service desk accounts get lost in emails..and with the public option on, spam and all sorts creates a mess in JIRA...
Roger Birong
added a comment - We'd also like to whitelist domains for registration. It would be great if this feature could be integrated quickly, our company is currently evaluating JSD and we are looking for such an option.
Yes that is a little more complicated. We were able to allow public sign up again in June, and only users with the domain we whitelisted can sign up. We do still have an organization set up though, so users can share with others in their org.
We still have to manually add all users to the org after they have created their account. So it's 50% better with not needing to create accounts ourselves.