Publish only certain spaces to DMZ

[Andreas Grabher]

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,

Andreas

[Davin Studer]

The only way to do what you want would need to be done at your firewall or reverse proxy using rules based on IP address and URL request.

[Rodney Hughes]

Why Davin?

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.

[Davin Studer]

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.

[Rodney Hughes]

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?

[Andreas Grabher]

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.

[Nic Brough -Adaptavist-]

If you aren't willing to use the permissions, then yes, your only choice is, as I said, multiple servers.  With the option of synchronisations 

[Nic Brough -Adaptavist-]

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

• access to the world (but with a login required)
• your internal users access to all spaces and projects
• your external users only the access they need

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)

[Matthias Gaiser _K15t_]

Hi Andreas,

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 support@k15t.com.

Cheers,
Matthias.

[Rodney Hughes]

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