Workaround to Effect Client Certificate-Based (Passwordless) Authentication to Confluence?

[Ben Jacobs-Swearingen]

I am aware that Confluence / Crowd does not currently  directly support Client Certificate-based authentication to Confluence via PKI, per this discussion.  As any such support remains a distant and uncertain prospect, I am wondering whether there are alternate, more convoluted means to achieve the same result. 

Specifically,  is there  a way to use client certificates to authenticate to an (Open) LDAP service, and then have the service broker authentication to Confluence over Crowd (which seems to support LDAP), with client certificates being used for the entire process from the perspective of user (i.e. user is never prompted for/enters a password directly)?

[Ed Letifov _TechTime - New Zealand_]

I believe you can achieve what you are after by deploying a reverse proxy in front of the Atlassian application, configured to perform the client certificate-based authentication and then pass the extracted Subject to the Atlassian application as HTTP header value. We have customers who are using F5 appliances in front of their applications to do just this.

To stay secure, the proxy and the service must be configured in a way that it would be impossible to set this header from "outside" circumventing the proxy i.e. no direct access allowed, and the proxy must clear this header on the requests from outside.

You can then use our EasySSO for Confluence app on the Atlassian application side, to take the username from the header, or apply some custom decoding code before that happens.

Please feel free to reach to our 24x7 support if you require more details.

[Ben Jacobs-Swearingen]

Yeah I have a reverse proxy deployed already - I'll check out the EasySSO appliance in the next few days, thanks!

[Kat Warner]

I don't know the answer to this myself but someone from the TechTime team will know. I'll follow up on Monday.