How to safely use corporate Active Directory (LDAP) authentication for an internet facing Jira instance?

[Sorin Sbarnea (Citrix)]

I have a Jira instance that is used by both intranet users and external users. The server is already configured to use HTTPS (secure).

Because the server is accesible from internet it is located into a DMZ/COLO zone, outside intranet.

Still, you do want to be able to allow all people from the company to access the website, without having to create accounts for them.

We all know that LDAP authentication is the solution but the problem is that you still need to be able to access the AD server, which is on the intranet.

As usual, IT Security said that they cannot allow connection to AD from outside intranet, even they are secured.

What is the proper solution in this case, one that can be accepted by IT Security and that also provides the desired functionality?

Further info:

The funny part is that from DMZ you can access HTTPS services from the intranet, as long you know the IP of the machines (internal DNS is not available to DMZ).

Security already accepted us to link the external Jira instance to the internal Jira instance via HTTPS but the problem is that this type of authentication-fallback does not scale with our number of users. Atlassian states that you should not use this type of authentication with more than 1000 users, and we have 12000 in LDAP (even if most of them are not using the services they are still there).

[Manse Wolken · Accepted solution]

I'd opt for crowd too.

You install crowd in the intranet (thus alloing the AD connection) and open a ssl port to crowd from DMZ (jira).

I don't know how to add things like SSL truststore to tomact etc, but i can imagine, that you can restrict the access to crowd with SSL certificate based authorization. Might be a hard target, but worth your time, if security has to be really high.

[Sorin Sbarnea (Citrix)]

Or in numbers, crowd means 8000$ first year and 4000$ after this, just the licensing, not including the maintenance of another service.

[Manse Wolken]

Another way could be:
1. Open Port 88 (kerberos) from DMZ to AD
2. create a seraph plugin for jira wich reads "remote-user" from http header and checks if the user is already authenticated. if not, create auth cookie and accept user. If no "remote-user", check if session is already authentificated, if not create session and ask for password (means, you have an external user)
3. Follow the howtos for Tomcat and Kerberos integration using jiras tomcat
4.make sure, that you don't use AJP proxys in front of Tomcat, only normal http proxys

5. Use Kerberos for your internal users, and require external users to be authentificated by jira.

Bonus: Your users won't have to log in to jira any more. It is not possible to read your user database from AD, only check Kerberos tickets from your AD.

I never walked this way, so you are on your own. Maybe a company called Appfuisions might help you, I asked them about Kerberos and Jira and they told me that they can do that.

[Sorin Sbarnea (Citrix)]

Kerberos is an interesting approach, still it is not a solution by itself, lots of internal users are using non-Windows machines, Linux or Mac OS X so kerberos is just a nice-to-have feature on top of normal login.

It's enough to have at least 1 internal user that cannot use kerberos in order to make the entire case irellevant.

[Manse Wolken]

You are right, but in conjunction with a ldap server, that is filled once daily from the ad, and without password sync, you have a more complete solution. Another would be to sync your AD users directly with Jira, using the Jira command line tools and a script which simply checks if a user in the AD is already in Jira or not and creates the users in jira if neccessary.

An attacker who gets access or ownage of the Jira server can access the complete jira information and the database, probably the userbase (names, loginnames and emai) but never the password database for the internal users (which might be, what IT Security wants to protect?) external users and their info iaccessible. So, a successful attack always leads to a message to your external users informing them about the attack...

And as I assumed for the seraph plugin: Users, that are not identified by Kerberos have to use the normal Jira login.

use of Kerberos: Any Client, that is able to use Kerberos (Linux, OS/X Windows) and is configured within the AD can use Kerberos for single sign on.

[lance_lyons]

Hi Sorin,

How did you end up setting this up?

[Sorin Sbarnea (Citrix)]

We bought crowd and we are using Crowd now with 5 instances, one being a public one. Crowd is on intranet and the public jira is allowed to talk with crowd via HTTPS. IT Security approved this, while AD/LDAP access was a no-go from start.

[Wilhelm Krüger]

Why don't you set up a reverse proxy which redirects the requests from the internet into intranet?

So you could put the JIRA Instance into the intranet and connect to the AD-Server.

[Sorin Sbarnea (Citrix)]

Let me remark the the "proper" way of cheating is to create a SSH port forwarding from another server on intranet that connects AD port to a local port on the DMZ machine ;)

[Jason Hensler]

I agree with Wilhelm, If your goal is to allow employs outside access, it would make the most sense to move the Jira to the intranet and have the employs either vpn in or go through an internet face apache with mod_ajp or mod_proxy and of course ssl.

The other thing IT might left you cheat with is to setup a vpn from the server to the intranet. Then you could pretend to be on the localnet for the AD server.

[Harry Chan]

Hi, I'm not really sure what security would allow, but would Crowd work? Could you have LDAP connect to Crowd and for both JIRA instances to authenticate to Crowd? The internet instance can then connect to Crowd if it's allowed and Crowd can sit inside the intranet.

Crowd does not have the 1000 user restriction.

[Sorin Sbarnea (Citrix)]

Yep, adding another expensive product and another single point of failure. There is some reason why LDAP is used for authentication, it's so easy to replicate it and provide the required redundancy for it.

[Harry Chan]

I definitely understand, but just trying to work around your security restriction. I'm not sure how else you can have LDAP without having LDAP. The JIRA user directory is actually an embedded Crowd.

[Harry Chan]

Perhaps another LDAP server on the DMZ? This LDAP server can get updated once a day or something with a backup from the intranet main LDAP server (but is not directly connected)? This way each JIRA connects to their own LDAP server but use the same username/password.