Does the AppFusions Kerberos SSO Authenticator for Confluence work with the Confluence Remote API?

[Joe Clark]

Thought I'd throw this question out here since I know there are some AppFusions lurkers around. :-)

Currently handling a support request for a customer who is using the Kerberos SSO Authenticator for Confluence. We are trying to get a .NET Web Services client to connect to the remote API, but so far Confluence just loves to return HTTP 401 (Unauthorised) no matter what username and password combinations get thrown at it.

I'm not really super knowledgeable about how the password-less Kerberos authenticator is supposed to work, given that Seraph is tightly-coupled to the concept of username/password authentication.

Are they are any tips or tricks to getting this working? Any known configurations in which it will categorically not work?

Thanks!

[Ellen Feaheny [AppFusions] · Accepted solution]

On behalf of our developer who supports, created, and configures this authenticator for our customers (and who is not on Atlassian Answers), here is the answer:

The AppFusions Kerberos SSO authenticator does work with the Confluence SOAP API. You were getting a 401 because you were not using Kerberos in your request. To turn on Kerberos in your .NET code, use DefaultCredentials as Jamie Echlin stated. Unfortunately, the Confluence SOAP API itself does not care if the request is already authenticated by the Kerberos authenticator, so to do anything with the API, you still need to get a token by passing in username and password.

For example:

ConfluenceSoapServiceService service = new ConfluenceSoapServiceService();
service.UseDefaultCredentials = true; // set to true to use Kerberos for the request
String token = service.login("username", "password"); /

[Joe Clark]

Thanks for your response, Ellen!

The client in this case is an ASP.NET app, so "UseDefaultCredentials" isn't appropriate. We do provide a Credentials object with the request, and this works against HTTP Basic and NTLM authenticators.

I now suspect the customer has an incorrect configuration, or is using the wrong user account to try and authenticate. Now that I have your confirmation that this is a scenario that should function correctly, we can dig deeper into their encironment.

Thanks for your help!

[Ellen Feaheny [AppFusions]]

I will say this.

We have configured this Kerberos support for a few customers now. The ones we have eyes for (VPN access), 100% success but not 100% instant efforts - indeed we have uncovered incorrect configs, etc. like you say.

We had two customers who would not give us eyes (no-VPN) b/c of red-tape, and we "consulted" via Wiki collab and JIRA thread conversations. Though painful, one was successful. twice - internally and he replicated it also at a client house.

Another was not successful and likely we'll never know. Really needed eyes to figure out what was going on.

Devil in the details. Good luck with that.

[JamieA]

I have not used the AppFusions one, but with my own Kerberos authenticator it worked fine from .net, assuming you have set:

serviceProxy.Credentials = System.Net.CredentialCache.DefaultCredentials

[Joe Clark]

Thanks, Colin!

[Colin Goudie]

I'll send an email with a link to this post to one of our devs