y4b3d (y4b3d) asked a question.
TLDR: I'm trying to send a RAW HTML POST command to an external server's API that expects a bearer token with the command, and getting back error 401 Unauthorized. The external server does support basic auth to get the bearer token, but you can't used the basic auth beyond that for this subset of API commands/functions/etc.
Backstory:
So… Jamf is bragging about a new API framework that should re-deploy the macOS Jamf Pro Binaries. They've got a blog post up from March about getting it set up using Microsoft PowerAutomate (https://www.jamf.com/blog/how-to-reinstall-the-jamf-framework-through-the-api-with-webhooks-and-microsoft-powerautomate/) and have a throwaway line about "This workflow can be used with many other code automation tools or scripts like Torq, Zapier, Okta Workflows, JAWA and many others" using the API command: https://developer.jamf.com/jamf-pro/reference/post_v1-jamf-management-framework-redeploy-id
I figure what the heck, let's try to replicate some of this in Okta Workflows, but with more of the automation on the Okta side of things -- the Jamf Classic API connector for Okta Workflows can call a computer smart group, I can pull out the individual target computer IDs using parts of the Okta Workflow system, and then hopefully I can send back the right Jamf Pro API command to reinstall the management software for those computers.
I initially missed that Jamf has 2 separate APIs for Jamf Pro, and the "redeploy" command is part of the "newer" API system that requires bearer tokens to successfully run commands beyond "/auth/token" which can run with "basic" authentication.
I've literally got every other part of my Okta Workflow up and running -- I can get all of the computers, format out the absolute URL I need to run the command, get the Bearer Token to auth to the Jamf Pro server… but I can't get the final RAW Request HTML command to successfully POST to Jamf Pro via Okta, because I keep getting "401: Unauthorized".
From the crash course I've been on to figure out how the API POST commands work I should be adding the bearer token somewhere into the HTML Headers, but I must have some sort of a syntax error happening where the Jamf Pro API isn't recognizing it.
I haven't gotten much help from Okta or Jamf support, so I figure what the heck -- maybe someone in the Okta community knows what's up.
So unless I am missing something from the linked article I see:
Headers → accept application/JSON
Headers → Authorization bearer BearerToken
In Workflows this would be done:
If there is something I am not understanding here please elaborate.
I missed "content-type" with application/json header but that could just be added to the construct. Well that and any other header you need.
Hi Tim,
Re constructing the headers:
That's part of what got me hung up -- I finally got someone from Okta Support who pointed out I needed to pass build the headers as a Construct - Object, but even after getting that set up I'm still getting 401 Unauthorized errors and it looks like the Construct - Object headers aren't being accepted by the Jamf server.
I've got it so it's parsing over…
{"content-type":"application/json","accept":"application/json","Authorization":"Bearer [BearerToken]"}
…but this seems to be out of line with what the Jamf server is expecting, thus the continued 401 errors.
There's a `curl` based guide at https://www.modtitan.com/2022/02/jamf-binary-self-heal-with-jamf-api.html and it seems like there's a disconnect in how Okta is passing over the content-type/accept/Authorization formatting.
The Jamf server is accepting other API commands from the Okta workflow, but they're using Basic auth or the Jamf Classic API Okta Workflow App.
So based on that link:
curl -X POST "https://yourserver.com/api/v1/jamf-management-framework/redeploy/3" -H "accept: application/json" -H "Authorization: Bearer bigLOngTOkEnTHiNghEre"
Which is literally just the example I provided previously. This should just require the following:
There are basically 2 things that can return a 401:
1) The request doesn't contain the required auth information.
2) The provided Auth information doesn't identify you to the resource.
If it were a permissions issue I would expect a 403 instead. Essentially, you have been authenticated but you are not authorized to the resource.
🙈 Oh my gosh. The raw HTML post was still trying to pass basic auth _and_ the bearer token. I turned off basic auth and it works now.
Thank you for being the voice of reason Tim!