SSO is great and working well however we want more . In our case we dont have use for public access so white-listing is necessary 

alexk1007397506,

Thanks for the suggestion. Is your organization using an Identity Provider (such as Okta) to handle authentication today? I believe many identity providers provide authentication-level IP whitelisting, which you could start using with your cloud products immediately. Here is a link to the relevant Okta documentation, for example.

Thanks,
Rak Garg
Product Manager

Finally, I have been watching this for a couple of years now. #

Just basic IP whitelisting at the top level. Either you can log into your account by being on the whitelist or you can't. That will do for now. You can add more white listing features later and take you time, this basic level of IP whitelisting is a MUST and should have been implemented years ago.

Hi Rak Garg

We use a tool like Bitglass (CASB) to do SSO and only allow trusted devices to access, but ideally we would prefer to restrict via Atlassian rather then having another layer between Atlassian and the end user 

Hi karthik2,

Rest assured that we believe in the value of this feature and are actively investigating how we can bring it to customers in the most efficient way. I'd love to understand: what other tools are you using with your Atlassian products to restrict access today?

Feel free to shoot me a note at rgarg@atlassian.com if you have any other questions.

Thanks,
Rak Garg
Product Manager

Hello @rgarg@atlassian.com

We haven't got much of an update from the last quarter of 2019 on this feature. Atlassian implementing this feature would remove the integration of other tools to restrict access to help in maintaining the simple architecture. Please let us know if the feature is even considered valuable to deploy into prod or still waiting for sufficient votes. 

It will be great to be able to restrict access to Atlassian Cloud using IP whitelisting to restrict access to our environment from public internet. What is the timeline for such implementation 

Good afternoon.

I'm the Head of Compliance of BET, Jira's user and the whitelist is really a good practice in terms of guarantee the security of access out of the office. Please check this possibility as this is acceeded outside of our office and we need to guarantee the security in a safe environment like only office IP.

Thank you

Microsoft planner is hot on the heals of replacing jira in organisations if this security control isn’t in place. Security wins over functionality. Planner doesn’t have workflow but has whitelisting.

This would make Jira a big player in cloud hosting space. Much needed feature from a security point of view. A thousand upvotes from me!

Nice feature to have

Seems like IP Whitelisting will be a "premium" feature.

This tells me they will charge the double amount of money to give us this basic feature and other less important stuff

Seemingly low-complexity feature making a lot of customers happy.

Value of this feature is that it will be one of the last arguments internal teams will have with their internal security department.

Suggestion to manage the security settings from within the billing / account section (different host) to prevent lockout.

As Atlassian Cloud is on AWS, while at it please integrate it with the corresponding AWS Security Group /WAF so we can have network level security (as to the less desirable application level security).

I totally agree with Simon , Whitelisting is the basic security feature which atlassian has to provide to customers.

Looks like atlassion is not concerned about security .anything which is hosted in the cloud should have the whitelisting feature .

We really must have this feature.

Bitbucket has many issues but restricting access to it via wihtelist is invaluable to us. Why this is not already a feature in Confluence is beyond me.

Atlassian - if you want customers to put their production & documentation pipeline in the cloud, you need to give us  the basic tools to secure it !

Hi Rak Garg,

with my team, we just moved to Atlassian Cloud.

Actually our Confluence contributors are around 100 and we are in the process of opening it to our product and operation specialists.

Thanks to this decision, we will be able to centralize all the informations inside one only tool (right now, the are dispersed among many google docs, evernote, google notes, etc....

However we would like that these users share their contributions to read-only users which will never be active users. We thought about the fact of opening a single account such user documentation@mail.com and spreading the ids to the read-only users. The security problem is pretty obvious and we discarded this choice since we don't want that a user connects to a Confluence instance (also if it would be seeing only one Confluence space).

That's why we would like to open the documentation to everyone but restraning the access to read-only users.

Like GCP, it would be perfect, if we could restrict the access to some IPs.

This is the main feature holding us back from moving to Confluence cloud. We use it for our internal intranet and do not want that information to be publicly accessible therefore we cannot move from server to cloud.

At Salesforce, by restricting with IP whitelist, we can register and store data in Salesforce with confidence.

ref: https://help.salesforce.com/articleView?id=users_profiles_epui_login_ip_ranges_edit.htm&type=5

ref:  https://help.salesforce.com/articleView?id=000321501&type=1&mode=1

At Atlasian Cloud, The fact that can't be restricted by IP whitelist means that you are putting users and the information they have to the risk.
Or it means that the data the user has is almost unimportant.

My team appreciates the Atlasian Cloud.
We want to migrate now, but we can not.

We need to be confident that they are communicating with Atlassian Cloud in a secure environment.

IP whitelisting is one of the most effective methods of ensuring this and prevents any internet traffic intended for Atlassian Cloud from being hijacked or rerouted to a rogue website.

If we can IP whitelisting, we can move to Atlasian Cloud.
If we can not IP whitelisting, we can not move to Atlasian Cloud.

We hope this feature will be realized.

Thanks.

Hi Rak Garg,

We currently use Jira Server and Confluence Server in our intranet.  We are uneasy about exposing our JIRA/Confluence content directly to the Internet to prevent user errors from leaking confidential or GDPR-related information.

Having an IP whitelisting in place would give us a lot more assurance to try the Extended Trial to evaluate a migration to Jira Cloud, as the atlassian.net instances seem to be in AWS Dublin, which is also where our intranet/Terminal Servers are.

Hi Rak Garg,

Following up on the previous post regarding license cost, which would be one reason for implementing white-listing for anonymous users. In my specific case, I'm representing a customer with more than 5000 users in the AD. I'm in the process of moving away from Confluence Server but I'm currently stuck since the majority of the users only need anonymous read access. Licensing 4000 inactive users is not an option. There are, however, two alternative solutions to white-listing that I can think of that would potentially solve the problem. 
1. Don't charge for named read only users
2. Allow anonymous users secure access from a CDN, for instance CloudFront. Whitelisting could then be provided by the CDN. This solution would require less work for you and would also minimize the load on your servers. 

Thanks

Robert

Hi Rak Garg,

From my perspective in a number of organisations I have worked in those that have used the 'Server' version of Confluence use white-listing to enable those spaces or pages that are accessible to anonymous users (i.e. public access) to be restricted to only trusted IP addresses, this is primarily due to information that is only relevant to the organisation and cannot be shared outside. Generally this has been the case as teams setup Confluence spaces/pages as 'Support wikis' where all support material for an in-house application is housed. Sometimes information within these can be sensitive and cannot be broadly shared with anyone outside the organisation. Additionally people do not want to cap out their licenses for Confluence for users that may or may not ever visit a Confluence space/page unless they require some support and bother to look at the support material (this however may go against the interest of Atlassian as additional licenses won't need to be purchased, but at the same time this functionality could intrigue people to use Confluence in this manner when they haven't done before and will generally have them embed all their support here in which it would be harder for them to move away from the application).

Thanks.

We are waiting for the feature as well.

Is there an update on this feature?

If you are seriously considering it, could this restriction apply by space if possible.

We want this feature as well!
Do you guys have an ETA for this feature?

We are awaiting for this security feature as well before moving our service to the cloud.

This is a must feature. Please update it asap

This is a critical security feature and a mandatory requirement for us to migrate the on premises installation to the cloud version.

What is the date plan to make this feature available?

Our tool selection policy prefers vendor cloud over self-hosting, but when using things like Service Desk especially (for internal service), we really want to be able to avoid 100% openness to the wider internet.  Requiring 2FA and using Azure SSO does remediate that a bit, but it would still be nice to have the whitelist option.

This is a critical security feature that is required in our environment for compliance reasons.

When will this feature be added?

As an organization, we are planning to move from Jira Cloud to on-premise because of the lack of IP whitelisting in Jira Cloud. 

This feature is a must. Please prioritize this higher.

Thanks

Hi,

For Enterprise companies this is a requirement.  Should be high up on the list. 

Thanks  

For compliance reasons, we need to restraint access to information.

As Soon As Possible we want close access by IP to our JIRA.

Thanks.

Now that this is listed as 'Accepted', is Atlassian able or willing to give an ETA for the feature?

My superiors have me withholding our renewal because of this feature not being ready. Some sense of timing would at least let us plan.

Hello,

Does this mean that I cannot really use rest jira's rest api until this request is done?

Thanks in advance

I’m very deflated that this is not assigned yet. With the data protection act and gdpr, spending twelve years implementing this tool into 15 organisations, I guess it’s time to use Microsoft teams to work in a secure manner rather than be left exposed to this security concern.

Restricting to ip is an essential security control for us, so we can control access from just our public ip addresses. We could not proceed with the product without it. Seems this would be a great selling point for all the cloud offerings. 

We need this as a feature too to satisfy our Information Security requirements.

When working on this issue, is it possible to add this suggestion also? https://jira.atlassian.com/browse/CONFCLOUD-6788.

This should be available in Confluence.
We'd like to add Anonymous access to an shared space, that's containing (client-specific) useful information for our external clients but we don't want it to have it open for the whole world.
And besides, it's lack of not having 2FA doesn't help us either.

For us, the ideal is enable access for every IP with login/password and for "public stuff" only from some ip or users logged in. This enable us to share with part of company status that today are only visible with Jira Users. 

We need this as a feature too to satisfy our Information Security requirements.

How are security requirements to meet data privacy regulations and laws a Medium priority:?

Atlassian needs to up its game with security requirements given recent GDPR introduction. We need this IP address filter if to continue to use Jira cloud. Otherwise will have to revert to using Microsoft Project linked to Microsoft Planner. 

Really need this as a feature to satisfy our Information Security requirements.

Disappointed to discover this isn't already a feature.

We cant, and will never consider migrating to the Cloud platforms without this. Happy to discuss our use case with David or whomever.

Can some users be set for single sign and some for Two factor?

This is one of our key security requirements, and looking for this feature to restrict access to our cloud site (with subscription to Jira and Confluence) for anyone outside of our company network/VPN.

+1

IP whitelisting is very important. Are there any updates on this feature?

Guys you can try to use any IAM like OneLogin or OKTA to restrict access by IP Address.

+1

Dave Mayer,

It will great feature to introduce network restriction on Jira and confluence.

I’ll be glad to discuss more on this, please let me know your email or any meeting room to discuss more on this. 

-Karthik 

Dave Meyer,

What's your email address?

-Ben

Yes Mark Reed. Also, is this request for Confluence Cloud as well? Same requirement here for CC.

To secure Jira and comply with GDPR, we definitely need to restrict access to Jira from designated IP addresses. 

Please can you add. 

M

I'm amazed this wasn't a part of the initial security design +1

Also can we get a session timeout?

+1

+1

+1

9 years later and we still believe!!! + 1

+1

+1, its in the top 3 requests sorted by votes, we need another 400 to reach number 2!

I see - Atlassian find it OK to have stuff in the backlog for >5 years. Still JRASERVER-1369 got into the "In Progress" stage. Let's increase the votes here to try to get their attention. @Tim Moore, does it work this way?

Not so sure. Have you seen JRASERVER-1369 ?

Guys, this feature has been requested more than 8 years ago. The only way I see to make Atlassian pay any attention to it is to ask your teammates to come here, comment and hit the Vote button (top right). Hopefully we can get some traction this way.

+1 we need to use this in order to move the rest of the company over. please add this asap

+1 our clients won't allow my firm use Jira cloud without IP whitelisting functionality.

+1, this is been a major concern for our company with Jira and confluence.

+1 we can't deploy Cloud Confluence at large because of this.

+1

+1

+1 please

+1

+1, but what is the likely hood of this happening if it hasn't happened for 8 years now? Unfortunately this is a deal breaker for our business... 

Looking forward to seeing this feature implemented. We've got around it a bit using google groups with filters on them for service desk, but this would be excellent to have for our deployment.

IP white listing is available for BB Cloud Premium licensing. Please make this available for Confluence and Jira Cloud products!

We are more or less violating our (common) security policy because there is not white-listing. Please do at least a hack, can't be that difficult to only serve a custom IP range.

adding one more vote - but after 7 years I am highly skeptical 

Can't agree more with the jist of these comments.  Surprised the Cloud version of these popular products was released without this critical security feature.

It is quite of an important feature for us, increasing the security around who can access our issues.
Can’t wait to see this one going in progress!
Please

The same reason for our company. IP whitelisting would be an essential feature for us.

An update on this feature/development would be great!

This feature would enable our organization to make use of Atlassian's cloud offerings.

After being requested 8 years ago, is this still being pursued in development?

This would be the one thing that I would have to have to go to a cloud hosted option.

Hi,

Is there any update on the whitelisting option?

Regards,

Engin Ören

engin.oren@edenred.com

You cannot whitelist on Atlassian Cloud version. These tickets with requests to add whitelisting have been open for 6 years now. We have spoken directly to folks at Atlassian - really nice people - but their response was move to the self-hosted edition, which was not an option, so we moved to Zendesk - yes it integrates with Jira Agile and no I have no affiliation with Zendesk.

There are other companies that understand the same issues you are describing - all security related. It is was a hassle to migrate to Zendesk, but security was more important than a little hassle.

I am bit confused.

May I please understand if Jira Cloud now can whitelist IP address? Or is this feature still not available? We are still using on-premises version of Jira. However want to explore cloud option. But this may not be compliant for us, if cloud access allows our developers to access website freely outside our premises.

I agree on earlier comment related to security. We do not want developers to connect from home and see few confidential Jira tickets or Jira confluence articles from their home or outside the office premises. 

While the whitelisting addresses may be nice, it could be substantially easier to have a subset of users that are restricted to just updating tickets and basic public functions.

This is the primary reason we're not using the Cloud version.

On a side note. Has anyone already created a list of reasons for using JSD Server instead of JSD Cloud? This is obviously a big one.

-rob

The answer I've been given is to purchase their on-premise product and you can control access as you wish. If anyone from Atlassian reads this, is that still the case and solve for this security control on the Jira product?

I am in agreement with Darian Miller. I'm looking for another platform to move off of Atlassian products because I need a way to whitelist customers on Confluence and secure my content. In a world where security is critical I really wish that Atlassian took this more seriously.

Looks like they are saying this is "Resolved", but this feature does not exist anywhere I can find it in Confluence or anywhere else. 

It would be very helpful if Atlassian would provide some guided training rather than changing the dashboard every other month...

I no longer refer people to Atlassian products simply for this single issue, rather I use this as a reason to tell people not to use your products.  It's an obvious requirement, has been that way for years, and I'm actually tired of seeing all the requests come through over time so I've quit watching the issue as well.

Over, and out.

As an add-on developer for JIRA-Cloud meant for internal use only, I would like to see this option in effect to strengthen the security policy.

Would be very interested in this security control.  Seeing more SaaS companies/products supporting this strong control for their solutions.  Here is a great example of one we use and have implemented.

Bump.  Please implement.

This is a critical need and should have been addressed long ago.  We have an immediate need and may replace Jira if it does not get corrected soon.

Agreed on importance of this feature.

This is very essential. We would like users through out the company to just view documents. Only certain users has to edit the documents while the rest of the company user would need to at least view these documents. I understand that you are looking at the licences and the cost. But with the anonymous option, there is no security for the company documents and that looks very bad.