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?
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.
ConfluenceSoapServiceService service = new ConfluenceSoapServiceService();
service.UseDefaultCredentials = true; // set to true to use Kerberos for the request
String token = service.login("username", "password"); /
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!
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.
More and more people are building their careers with Atlassian, and we want you to be at the front of this wave! Important Dates Start the Certification Prep Course by 2 April 2019 Take your e...
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