Kerberos for REST

Kantega SSO Enterprise allows you to authenticate REST clients with Kerberos. The feature is disabled by default as it can interfere with existing integration. Note that you can specify URL paths, IP ranges and user agents to restrict Kerberos from triggering in unwanted situations.

The screenshot below shows you where to enable and configure Kerberos for REST, and the syntax for defining excluded URL paths.

See also how some user agents are excluded from getting Kerberos challenges.

 

Using Kerberos for REST from Windows PowerShell

Log into Windows as a domain user for the domain where Kerberos has been set up. Then verify that Kerberos works for this user by opening a browser and navigating to your Atlassian site (for example https://confluence.example.com/users/viewmyprofile.action). When Kerberos login works, you should be directly logged in and it should be possible to do scripted REST requests from PowerShell for this user. Also, remember to activate “Kerberos for REST” as described above.

Open a PowerShell window and use the below example to verify that Kerberos for REST works for you. Please change the URLs to match your Atlassian site.

# remove all existing kerberos tickets. This is done just to illustrate # how the Invoke-WebRequest below requests a Kerberos ticket from AD klist purge # list all existing Kerberos tickets for this user. This should now be none. klist # login page URL $loginUrl = "https://confluence.example.com/login.action" # rest resource URL $restResource = "https://confluence.example.com/rest/api/content/38109187" # User-Agent $useragent = "Windows NT" # Get a valid web session Invoke-WebRequest -UseDefaultCredentials -Uri $loginUrl -UserAgent $useragent -SessionVariable websession # Invoke the REST request Invoke-RestMethod -Method GET -Uri $restResource -UserAgent $useragent -WebSession $websession # list all existing Kerberos tickets for this user which now should be # typically two that were created if the Invoke-WebRequest worked klist