REST API HTTP 401 Unauthorized Status

Customizations
1

At this customer we are experimenting with custom Wizard code that does a BigFix REST API Query. This code works in many other environments, but for some reason this HTTP 401 status code is being returned here. The REST API call is a GET request to fixlet/custom/API%20Test/3461

Anyone seen errors like that before when executing REST API queries from a Console Wizard? Would like to know what should be done to troubleshoot.

2

First thing to check is whether that operator has “Can use REST API” permissions assigned to their operator account.

I’d also check using a browser first, before trying to troubleshoot the custom wizard; point the browser to https://your-bigfix-server:52311/api/login

Edit: the operator also needs at least READ access to the custom site containing the fixlet.

3

Thanks Jason! Yes, the correct permissions are there on the content and the operators.

I’d also check using a browser first, before trying to troubleshoot the custom wizard; point the browser to https://your-bigfix-server:52311/api/login

Is that link supposed to work for customers who have SAML 2.0 SSO enabled in their environments? Since here we are doing AD FS integration with Smart Cards, I’m not able to auth at that URL, so am getting a 401 Unauthorized status.

4

I wonder whether that’s the root of the problem - I haven’t tried using the in-console wizards for custom restapi calls, I wonder whether it’s also not handling the SAML part. Is your custom wizard using the restapi javascript functions provided by wizards.js ? You’d probably need to file a support incident on it to get a possible bug report open… Can you post the simplest possible version of what you’re doing to reproduce the bug?

5

Thanks for you attention on this. I got a confirmation from someone running a SAML 2.0 SSO environment that the exact same REST API call does work for them in their console, so while that means it can work in that type of environment, it doesn’t rule out that type of environment being a factor causing the breakage here. I know for sure that it is preventing us from trying out that API URL from the browser for troubleshooting.

Here’s an example of the API call being made:

var restcall = 'fixlet/'+custom_or_external+'/' + uri_site_name + '/' + fix_id
API.Get(restcall, function(error, status, body) { ... })

Where the variable restcall equals this: fixlet/custom/API%20Test/3461 & And the fixlet ID 3461 is valid.

1 Like
6

Today we discovered that a local account has no issue using the wizard. So it is only our SSO-enabled accounts which are affected by this problem. There are, however, customers who can use the dashboard just fine with their SSO-enabled accounts, so the issue must be unique to the SSO configuration in this environment. Just wish I knew what it was…