Secure connection

[Cristina Rodríguez Amado]

Hello, 

I´m installing an integrated solution with jira service desk and confluence for an enterprise.

We work with a few diferent companys and need to give support for all of them.

We plan to have one project of jira for every company with an asociated confluence space.

We are dealing with a few security obstacles.

-We would like not publishing our confluece space on internet but want our clients to have access to their space via jira. We want to have our private resources on a diferent space of confluence and we consider it's insecure to publish it.

It´s some way to do this?

There is some kid of two factor authentication?

We need to ensure our private information.

Our servers are behind a SSL reverse proxy.

Which is the best aproach to this kind of instalation? 

Thank you in advance.

Regards.

[Dave Theodore [Coyote Creek Consulting] · Accepted solution]

You really should start with a conversation with your Infosec team to see what they will require.  Fundamentally, you will be giving your Jira and Confluence instances direct internet access. The Application security can ensure that users can see only the content they are supposed to, but not all Infosec teams are comfortable with relying on application security. Then there is the concern about application vulnerabilities and the ability for hackers on the internet to have the ability to exploit them.

This is an issue that many companies are facing.  Here is what we commonly see with clients the we work with. I'd expect one of these will apply to your company as well.

1. Infosec is totally OK with the security provided by SSL and application security to limit access to logged in users. Simply expose your Confluence and Jira to the internet, configure SSL and appropriate application security and you're good to go.
2. Infosec has some policy requirements for a system to be made internet accessible. These vary, but 2 factor auth, client certificates, IP address whitelisting or some additional steps are required.  You will need to jump through these hoops in order to satisfy Infosec, if this is the case.
3. Infosec is OK with only the content that is exposed to external users being on the internet, but not all content. In this case you have an internal and external Jira and Confluence (ie: 2 instances of each application) and you synchronize data between them as appropriate. If you can avoid this option, you should. It's costly, messy, complicated and will never feel very polished, as none of the Atlassian tools were designed with this use case in mind.  There are a number of 3rd party Apps that can perform these functions, though.
4. Infosec says no way those services can be on the internet. In this case, you give your external users VPN access or go rogue and set up an Atlassian Cloud instance that you interface with your external users on.

We typically work with Infosec at our clients to give them all the information possible. This can help them make an informed decision.  Often times, the initial response is based on ignorance of the tools capability, and once they understand how application security works and what the risks are, you might be able to do #2 above.

[Cristina Rodríguez Amado]

Hello, 

Thanks for the fast reply, probably we will implement some 2FA.

I'm now struggling with what I think, is a strange behaviour.

I have now two confluence spaces, configured for two diferent clients (enterprises).

The clients of this enterprises will be unlicensed users, maybe its so simple, but I can't achieve the clients of one enterprise to see only that one space but not the other one.

Tried to create user groups or give them individual permissions but anything seems to restrict the access. Unlicensed clients stay like they are all the same.

There is some way to manage clients from jira not having web access but seeing the articles from the jira space? Or only having access to their space?

I'm adding the clients on confluence and jira, don't manage them from jira.

[Dave Theodore [Coyote Creek Consulting]]

It's not strange behavior. It's expected behavior. Granting "Anonymous" access (you are referring to this as "unlicensed users") means anonymous.  Anyone and everyone can see that Space.  In order to do what you are proposing, you will need to have your clients log in, and therefore consume a license. There is no other option.

Jira Service Desk has the concept of "agent" users and "customer" users.  Customers have free access.  When you connect a Jira Service Desk Space to a Confluence Knowledgebase, customers can see the knowledge articles that come from Confluence in Jira Service Desk with their free license.  That might be a workable solution for you, given that it sounds like these client users will also be using Jira. Atlassian has a video demo that you can watch to see how this might work for you. I hope that helps.

[Cristina Rodríguez Amado]

They are not anonymous users, are the customers from jira, and they can access other customers knowledge base.

I mean, if I sign on on confluence, with a customer user, I can access every customer knowledge base.

This is the configuration on two knowledge bases of two clients.

Because this configuration every customer can see the two knowledge bases instead of their project one. (knowing the url)

[Dave Theodore [Coyote Creek Consulting]]

Got it.  The issue is likely with your Space permissions.  I would recommend managing permissions as follows.

1. Create one group for all customers and add all customers usernames to this group.
2. Grant the "Can Use" Global Permission to this group.
3. Remove this group and all customer usernames from all Space permissions and Page Restrictions.

Doing this will allow the customers to log in to Confluence only.  They will not see any Spaces or content.

Then:

1. Create one group per customer and add the associated usernames to each group.
2. Add the customer group to the associated KB Space for each customer and assign the appropriate permissions they require.

This will cause the customer to only see a single Space when they log in.