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?
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).
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.
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.
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.
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.
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.
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.
In the past, Portfolio for Jira required a high degree of detail–foresight that was unrealistic for many businesses to have–in order to produce a reliable long-term roadmap. We're tur...
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