We do have confidential information in our spaces and want to keep this information inside of our intranet. However some spaces should be available in the DMZ accessible (r/w) for external users over the internet.
What kind of application architecture would you recommend?
The same for Jira. Some projects are strictly internal, others do need access for external users.
Thank you and best regards,
JIRA and Confluence have no notions of "DMZ". They provide users access to issues and pages.
What you're trying to do is completely supported though. You grant
If you want to do it with traditional DMZ, that's a different story - you're into multiple servers and services and building copying/synchronisation processes (there are add-ons to help with that)
You can let the public in through your firewall to access a Space with "Anonymous User" enabled, but they can't see any other Spaces that don't have that enabled. And even within that Space they can see, they can only do what the Permissions settings allows them to do.
Based on the original post it sounds like they are saying that internal spaces should not be accessible outside (even by internal people). "We do have confidential information in our spaces and want to keep this information inside of our intranet." But that there are some spaces that they want read write access to outside. The only way of keeping the internal spaces only accessible on the internal network would be to have rules that drop the traffic based on IP and URL.
I see what you mean.
If they really do mean that no one can access if they are not connected directly within the intranet zone then firewwalls are teh requirement.
But I am not sure what they mean by "external users" - are these people sitting at home or in a hotel accessing the Spaces as a registered User, just connecting in remotely rather from their desk at the office?
We don't want to rely on Confluence security settings alone and would like to invoke our firewall. The problem is that I did not find a rule set that enables single space publishing for both, read- and write access.
It looks like the only solution would be to have two separate Confluence instances.
A Space "normally" can only be accessed by the Users that you grant access to .. so the Space is "confidential" to them.
Within that Space you can then View Restrict a page (and by inheritance all its Child pages) to a subset of the Users with access to the Space e.g. a task force or a executive committee etc
But by specific action of the Space Administrator, you can create Spaces for public access where they don't require login ... just like a normal web page .. by specifically turning on the Anonymous User option in the Space configuration - what they can do when they visit that page is up to the settings of the Permissions for that Anonymous User. Of course people with a registered user access can log in as normal and do other things in that Space like edit etc as per their personal Permissions for that Space. So whilst the Space is open to the public with no login, they can't edit or create any mischief, but your registered Users of that Space can manage the content
I don't know if you're still searching for solutions, but maybe other people do.
I would think about having two different Jira/Confluence instances, one internal and one in the DMZ and copy to the DMZ only the information which you really like to expose. This way you can guarantee that no internal information will be shared with the outside world.
If you further want to automate the jira information copy process, you could use an issue sync solution like Backbone Issue Sync. A solution like this also enables you to share only some fields of an issue.
For Confluence, I don't know of a solution which is the same way automated. However, you could use the internal Confluence as your authoring system and publish the space to the DMZ Confluence when you're done with your changes by using Scroll Versions and the Scroll Remote Publishing Endpoint.
If you (or someone else) is interested in a discussion, let us know via email@example.com.
Badges are a great way to show off community activity, whether you’re a newbie or a Champion.Learn more
Hi Community, Jessica here from the Confluence Product Marketing team! July’s community challenge is all about sharing pictures — and as an extension of our first post on what ...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs