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.
This community is celebrating its one-year anniversary and Atlassian co-founder Mike Cannon-Brookes has all the feels.Read more
To anyone who doubts that Atlassians are a little too obsessed with collaboration, and tools related thereto, let me describe a recent discussion we had (which took place on our internal Confluence, ...
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