Classic API Basic Auth Deprecation

[BradB]

Hey Jamf Nation,

In Jamf Pro 10.35 we announced the deprecation of Basic authentication in the Classic API scheduled for a future release of Jamf Pro (https://docs.jamf.com/10.35.0/jamf-pro/release-notes/Deprecations_and_Removals.html). We received some great feedback from the community, and there were some questions around why we chose to make this change. I’d like to address those here. 

The change in authorization mechanism in the Classic API was an effort to quickly mitigate the threat of brute force attacks against Jamf Pro instances. Today, the Classic API is the main target for attackers executing brute force attacks to attempt to gain access to a Jamf Pro instance.

By using the same authorization mechanism as the newer Jamf Pro API, we're able to funnel all auth requests through a small number of endpoints that we can rate limit, without limiting every API request.

We know that a change like this causes additional work for customers and partners to update API workflows, but we believe this change is critical to improving the overall security posture of Jamf Pro. We encourage customers not currently using the Classic API to disable basic auth as soon as possible to reduce the attack surface of their Jamf Pro instance. Starting in Jamf Pro 10.36 you can disable this directly within the web interface by unchecking the "Allow Basic authentication in addition to Bearer Token authentication" checkbox in your Password Policy settings as outlined in the release notes (https://docs.jamf.com/10.36.0/jamf-pro/release-notes/Deprecations_and_Removals.html). We continue to evaluate all aspects of our APIs to ensure simple and secure programmatic access to the entire Jamf portfolio of products.

Thanks again to everyone who has provided feedback on this change.

[rocketman]

Glad to see Jamf moving this direction and making their platform more secure! We discussed this change in our last Jamf User Group, check it out if you want more information about how to implement this: https://youtu.be/6xVmJqpbEHI

[ubcoit]

@rocketman 

Thanks for the video! Good explanation. I understand that this is apparently "more secure" but in reality, you still need an account, you still need to pass the parameters of username and password to generate a token. So the only advantage here is that the token expires. But you can still sniff the username and password and generate your own token. You also mention no one has scripts that runs longer than 30 minutes. Well, my voyage into bearer token was for PowerBI reporting and I'd hit the 30 minute timeout all the time while waiting for the query to end. At the time I talked with Jamf about options about settings a longer expiry and I believe it's supposed to be an option but, at that time, wasn't working. I had to bail on what I was trying to do with PowerBI and just use the PowerBI plugin for PowerBI Desktop (which I'm also guessing will break soon because of this change).

Fun fun!

[rocketman]

That was my main thought when Chad showed me this as well, and I tasked him with coming up with a more secure way of doing API calls, and here's the result: https://youtu.be/A0dHwGPdZ3E

Lets use something like grabbing the asset tag from Jamf. Normally, I am giving the users access to a Jamf Pro account that would be able to read ALL the inventory of ALL the Jamf computers! This way, since we're offloading the work to another server, they only get the ability to lookup a asset tag based on a specific serial number in our Jamf server, which really doesn't show them much. WAYYY more secure. 

[bethjohnson]

Are we going to get a webinar on how to switch from Classic to Jamf Pro API with tokens?

[rocketman]

We're actually talking about this Friday - come join us!

https://us02web.zoom.us/meeting/register/tZIld-2rqT8oG9wToialV2pkYndjmyYyTS2W

[rocketman]

@BradB It's currently past the December 2022 date and Basic Authentication is still alive and well. Do you have another official date on when this will be completely removed?