API account

[winningham_2]

I was thinking that "back in the day" one must have privileges to use the API but within 9.3 I don't see this explicitly pointed out.

My questions are:
1) Most of my API calls are GET so perhaps I would need to create a read-only account that touches everything privilege-wise? 2) For the PUT/POST scripts, should I then create a full-admin access, minus a couple of options, for API writes?
3) The API-writes scripts have the username/password hardcoded in them, but I am afraid if I need to add write access and those un:pw are stored in plain text some where, so any thoughts on getting around that if question 2 applies?

Any thoughts or let me know what I am missing?

[mm2270]

Its still there, listed under Privileges > JSS Objects. You'll see a number of items that have checkboxes for Create, Read, Update and Delete (or CRUD if you prefer) These are the equivalents to the same API Privileges in the older JSS version.
If you want to set up a Read Only API account (good idea) then give your account any of those privileges in that JSS Objects section you want. The rest, like JSS Settings, JSS Actions and so on can be left unchecked and it should only have access to the API, not the JSS itself.

Hope that helps.

[winningham_2]

@mm2270
So it would be an API credential with the appropriate boxes checked depending on whether or not I want CRUD or just Read. Kinda scary but understandable...

So to you or the general community, any way to authenticate to an API-CRUD account and NOT show it in plain text within your JSS-housed script?

[mm2270]

You could pass the username and password as Casper Suite script parameters to the script. So in the script themselves it would only be hardcoded to have something like-

$apiusername
$apipassword

which could be populated by $4 and $5 respectively. Whether that still passes these in plain text down to the script I actually don't know but I don't think it does. Can anyone confirm or deny that? (Would actually be a good thing to know)

[exno]

this post is on the older side. roughly 4 years old. but i found it while trying to gather discussions and information to help doc out Jamf API best practices for work.

Incase others come across this post and want to know a good way to obfuscate the API user and pass:

https://github.com/jamfit/Encrypted-Script-Parameters

this is a process that uses openssl to encrypt the user and the pass, and then a function that takes the encrypted values to decrypt them for use in the script. Storing the encrypted string in parameters will help to separate the needed pieces.

i have an easy to use script that helps encrypt the user and pass, all with system event pop ups.

https://github.com/exno/encrypt_user_input

i tend to toss it into self service and scope it to only IT/IT Eng/Jamf Admin macs, or limit based on AD login to self service.