Single sign on with active directory credentials

[Kenan Dervisevic]

Are there any options or plugins that we can use to pass active directory credntials through to confluence (using Kerberos)?

We would like to have a user login to their PC on the domain, launch confluence and automatically be logged in using those same crednetials. Our environment is already LDAP integrated, however currently a user has to login in with their domain credentials into windows, then again into confluence with the same login.

What are our options in this scenario?

[Alejandro Conde Carrillo]

There is a (paid) plugin for that: Single Sign-on.

[Sorin Sbarnea (Citrix)]

That's not expensive, it's most expensive piece of code I ever seen (when it comes of price/line of code written).

[Ellen Feaheny [AppFusions]]

It is an Enterprise solution - and supported.

[Richard Cross]

https://marketplace.atlassian.com/plugins/no.kantega.kerberosauth.kerberosauth-plugin.confluence/server/pricing

But I agree that it's expensive, given that Atlassian Crowd does so much more for the same price.

[Ed Letifov _TechTime - New Zealand_]

Disclaimer: I am a Single Sign-On vendor.

You are certainly entitled to your opinion, but I see this as a very misleading comment.

If you take single sign-on out of Crowd - what does Crowd actually do, that the Atlassian applications like JIRA or Confluence don't do themselves (since they have Embedded Crowd inside).

Crowd "single sign-on on the web" i.e. "having to login once and then switch between multiple web applications without the need to login again" can not really be compared to a true single sign-on plugin, as in "login into your workstation and proceed to the application without the need to login ever". They are similar but not the same.

A true single sign-on plugin does little things that become important when you think about economy of scale:

• saves you time (3 seconds spend entering your login/password, multiplied by the number of your people, every day, multiple times per day can mean a lot to many organisations)
• increases security - no more saved passwords, if you are not using HTTPS - no more plaintext passwords send over the network
• saves you money (by removing the possibility to have locked accounts incidents completely and thus reducing calls to your service desk)
• removes barriers for adoption and as such removes barriers for collaboration (compare the dread of "if I click on the link in this email I will be faced with yet another login window" vs. "here is something interesting, click, reply")
• simplifies rollouts ("here is the link, you will be logged in automatically" vs. "here is the link, use your Domain user/password")

Perhaps none of this is important enough by itself, but you just need to see a person who moves from an organisation where SSO was deployed to the organisation where there is none. "It's like air. You only notice it when it is not there." - this is the real comment from a customer of ours who found themselves in this situation. Why don't you install one of the plugins using an eval license, which you can re-generate several times, let it run in your organisations for at least a month, and then pull it out. And then please report the reaction of your users.

"Expensive" needs to be viewed in the context.

Yes, it seems more expensive than asking your fellow sysadmin to read-up on some docos and spin up a home-grown solution using Apache and some kerberos library. However, he is not going to do it instantaneously, and any minute spend on this is a minute he could have spend on something more important. What do you do when this sysadmin leaves or when client OS vendor pushes a security update that stops the solution from working? What do you when Atlassian application changes? How much cost do you put on your SSO "down-time"?

You need to take into account what the solution actually does. For example our SSO plugin does auto-enrolling users, automatic failover to a different Domain Controller based on DNS, support for AD sites and services, filtering by gazillion different criteria, dare I mention fallback to NTLM when Kerberos is not possible? Take a look at our FAQ - try to guess the "complexity" of the task. And (if you know what you are doing) the deployment is still "under 15 minutes". If in doubt - get in touch and I'll be happy to prove it to you via a desktop sharing session. I bet you, your sysadmin can't beat this even following a well written configuration document.

You need to understand the cost of actually maintaining an add-on as an Enterprise solution (as Ellen briefly alluded to above). Where Atlassian is capable of spreading the costs across multiple products and customers - smaller marketplace vendors cannot. Every time when a new major version comes out Marketplace marks a plugin as "incompatible". We have 5 SSO plugins for 5 Atlassian applications - keeping them up-to-date does take effort. We support Windows, Linux and Mac OS X, IE, FF, Safari and Chrome - testing across all of these platforms is daunting. As commercial vendor I undertake responsibility for my product, so you don't have to take the risk.  I have at least 4 full-time people involved in supporting this add-on - developers, support, marketing. In New Zealand the minimum wage is about US$10/h. If I were to pay these 4 people just the minimum wage that's US$80k right there. Take mine or Katenga's "active installation" numbers from Marketplace, our average customer is 250-500 users - do the calculation.

You also need to take into account what the customer should be able to afford as far as we the vendors think. Let's take 25 users level, one where we are more expensive than Katenga. Our cost is US$600 for the first year, US$300 renewals after. Let's say you are on the bottom level of 25 users i.e. 11 users - don't fit into the Starter license anymore, but feel the pain of suddenly "having to pay more that $10 for everything". Your JIRA license costs you US$1800 and renews are at US$900. 11 users - applying the same "minimum wage" argument - you are paying them at least US$220k in salaries. If you can afford that - you overall gross revenue should be at least 2-3 times more. So now look at $600 per year in this context - still too expensive?

Pardon me for this long diatribe. We get this feedback all the time. People try our plugin, then uninstall and Atlassian application pops up a dialog asking why. The choices are limited and "Too Expensive" is one of them. We try to get back to everyone who leaves their contact details. Interestingly, those who label it as "too expensive" NEVER come back to us to explain why. And it's truly a pity - since it would have helped us to reshape the pricing policy if we understood this particular segment of the audience.

[Steve Gerstner [bridgingIT]]

If you are using an Apache in front of Conlfuence, you can use mod_auth_kerberos and use the HTTP-Header variable REMOTE_USER for Login.

[Kenan Dervisevic]

Do you have any more info regarding this, or can you elaborate a little further?

[Steve Gerstner [bridgingIT]]

Use Apache for Authentication via Kerberos. This will store the Username in the headervariable REMOTE_USER.

In Confluence you need to extend ConfluenceAuthenticator's getUser-method to read the headervariable and to perform the login.

That's all

[Richard Cross]

"In Confluence you need to extend ConfluenceAuthenticator's getUser-method to read the headervariable and to perform the login."  

That doesn't sound entirely trivial.  Could you explain a little further?

[MelviN]

Apache in front of Conlfuence!!! It is not at all clear how this will work for Conlfuence? Apache needs to be installed for this solution? Describe step by step how to install everything.

[Ed Letifov _TechTime - New Zealand_]

If you want to roll-your-own using Apache, yes, Apache needs to be installed in front of Confluence as the reverse-proxy and configured to perform Kerberos authentication before the request hits Confluence. Then you need something on the Confluence side to parse the results.

If you use EasySSO for Confluence with the headers authenticator (one of the 5-in-1 authenticators included) you can configure Confluence to take the value of a named header e.g. REMOTE_USER from the designated IP addresses e.g. your reverse proxy only.

Thus the need to write code to override ConfluenceAuthenticator's getUser method is gone.

If you only use headers-based authenticator we offer discounts (to account for no need to use IOPLEX Jespa library) see our EasySSO FAQ specifically - Discounts for some authenticators

Having said that - you can save yourself trouble of installing Apache, maintenance pain and ultimately money and just deploy EasySSO in full mode, doing Kerberos authentication with NTLMv2 fallback when Kerberos is not possible. This should only take 10 minutes, and you can always reach to our 24x7 support.

[Jeevan Desarda]

Microsoft is offering this integration for FREE. You can use Azure Active Directory FREE version which comes with 500K directory objects. See the Free SKU details from here.

You can connect you existing Active Directory with Azure Active Directory using Azure AD Connect. Once you have all the users in Azure AD then you can simply use our FREE plugin listed here and then configure SAML based single sign on with Confluence server. All the instructions are listed here.

Feel free to post your queries on the article and we are happy to help.

Thanks.

[Christian Reichert (resolution)]

@Jeevan Desarda

Compatibility say up to Confluence 5.10 ... sure it's still actively maintained & supported?

[Jeevan Desarda]

Yes, it is. Try it out and let us know how it goes!

Thanks,

Jeevan Desarda

[Ellen Feaheny [AppFusions]]

AppFusions has deployed Kerberos SSO over 30 times for Confluence, JIRA, Crowd -

It is an authenticator AND service - since devil is in the details of configuration for sure. Not all deployments are alike.

We are working on having the Marketplace deployable - but even this will not be plug and play, but it will be close. And also will have a license so you can keep up to date with releases.

Contact us at info@appfusions.com if interested.

Best,

Ellen

[sdgew sdfwe]

~~~ spam ~~~

[Bruno Vincent]

You might want to have a look at the Integrated Windows Authentication for Apps using Crowd (IWAAC) plugin: https://marketplace.atlassian.com/plugins/com.cleito.iwaac/server/overview

IWAAC provides your Windows domain users with automatic logon on any application using Atlassian Crowd as its user management system, including Jira, Confluence, Bitbucket Server (previously known as Stash), Bamboo, FishEye, Crucible, Jenkins and G Suite (formerly Google Apps).

IWAAC is a generic plugin that works on all applications that are compatible with Crowd. Once you have purchased a proper license, you can deploy the plugin on as many applications (Confluence, Jira, Bamboo etc.) and server instances as you want since an IWAAC license is an Enterprise license that is valid for your entire organisation.

You can download IWAAC and test it for free at: https://www.cleito.com/products/iwaac/

[Ed Letifov _TechTime - New Zealand_]

TechTime Initiative Group, an Atlassian Expert in New Zealand has been providing a solution to do NTLM authentication with Confluence and Jira for over 6 years. Though one can argue that this is not an SSO solution but merely an auto-login one, it works well in Windows-based environments.

We have over 60 customers successfully using this solution in New Zealand, Australia, Switzerland, Finland, Norway, Sweeden, France, Germany, Netherlands, Slovenia, Czech Republic, Turkey, Russia, Latvia, the UK and the USA both in NTLMv2 and NTLMv1 environments with and without Crowd in the backend.

The NTLM Authenticator is delivered as a jar file and instructions how to deploy it to Atlassian Jira and/or Confluence to work in conjunction with IOPlex Jespa to perform NLTM authentication in Windows environment.

The cost is one-off NZ$150 (plus fees for Jespa license payable to IOPlex). We do sell bundles that include IOPlex Jespa license.

If you need it, the trial version is available from our TurningRight website. Our NTLM Authenticators for Jira and Confluence support the latest versions of both applications.

We are currently working on moving it to Marketplace (Jan/Feb 2014) and as byproduct eventually making it support the rest of Atlassian tools (planned for 2nd quarter of 2014)

[Deleted user]

Our company already delivered a working solution (Jira/Confluence authentication via AD/Kerberos) to an enterprise customer.

If you are interested feel free to contact us.

Regards from Hamburg, Kai

[Marcos Sciarra]

Hi Kai, its a commercial product or something you can share for free?

[emailrichardchen]

Hi KP, we are interested in using enterprise AD solution.  can you share solution with us?

[AJ Greyling]

Good day,

Please provide details of your solution

Regards

[Lars Olav Velle]

We have a commercial product for all Atlassian products (except Crowd)

The products are integrated with dektop logon and work on windows, mac and linux.

We support JIRA servicedesk, Kerberos for webdav in Confluence (edit in office) in addition to the normal login paths. 

We have recently added support for Kerberos on the JIRA api also.

Our products are listed here: kantega.no/marketplace

Feel free to contact us on atlassian.support@kantega.no We offer chat with the developers and remote support. 

Our customers range from 10 user to unlimited. We have customers in bank, finance, insurance, government, energy, health, commercial, logistics, education and military 

[onkeldom]

+1 from me. We need a working solution as well (for Confluence and JIRA), since our last one broke up Office-Connector <-> Office 2010 functionality. So any hints about this topic would be appreciated.