Which user generated/owns an API key?

[MartinS]

Hi, 

We deal with a lot of managed services providers, and a request we've had a few times now is to help an SP find out which Meraki user generated an API key so they can add that user to a new Org. Is anyone aware of an API call that can be made where the user that generated the key is returned please?

Best

Martin

[alemabrahao]

The Meraki Dashboard API key is associated with the dashboard administrator account which generates it, and it inherits the same permissions as that account. The API does not provide a direct way to identify the user who generated a specific API key. This is likely for security reasons, as API keys provide authentication to all organizations with the API enabled.

If you need to manage API keys for different users, it’s recommended to have each user generate their own API key from their profile. This way, you can keep track of which key belongs to which user. Please note that SAML dashboard administrators cannot view or generate API keys.

Cisco Meraki Dashboard API - Cisco Meraki

[GreenMan]

You can list all the admins for a given Org using https://developer.cisco.com/meraki/api-v1/get-organization-admins/

hasApiKey is one of the returned fields.

You can also establish who is using the API in a given Org:   https://developer.cisco.com/meraki/api-v1/get-organization-api-requests/

As mentioned previously, security concerns would probably preclude the specific association you're asking for.

[John_on_API · Accepted solution]

The above are both correct. Personal API keys are not generated within the scope of an organization. The API keys belong to the user (identified by email address), and the user alone. They inherit access to whichever organizations have added the given email address to their admin list.

If you're wondering which email address is associated with a given API key, then use https://developer.cisco.com/meraki/api-v1/get-administered-identities-me/

If you're wondering who's making API calls in an organization, then use https://developer.cisco.com/meraki/api-v1/get-organization-api-requests/

Hope this helps!

[MartinS]

Fantastic, getAdministeredIdentitiesMe is exactly what I'm looking for, thanks very much @John_on_API !

Just as a side point, is there a best practice guide on how managed services organisations should use accounts and generate API keys when integrating with 3rd party systems like Highlight? I ask because generating API keys on user accounts associated with individuals is dangerous because if that individual leaves the MSP, their account gets suspended and that kills the key (we've seen this happen several times). 

I'm guessing the right thing to do is have a key associated with a non-personal api@serviceprovider.com account where the credentials are carefully managed and not widely known, but where emails to api@serviceprovider.com do get delivered somewhere?

[John_on_API]

---

@MartinS wrote:

Fantastic, getAdministeredIdentitiesMe is exactly what I'm looking for, thanks very much @John_on_API !

Just as a side point, is there a best practice guide on how managed services organisations should use accounts and generate API keys when integrating with 3rd party systems like Highlight? I ask because generating API keys on user accounts associated with individuals is dangerous because if that individual leaves the MSP, their account gets suspended and that kills the key (we've seen this happen several times). 

I'm guessing the right thing to do is have a key associated with a non-personal api@serviceprovider.com account where the credentials are carefully managed and not widely known, but where emails to api@serviceprovider.com do get delivered somewhere?

---

I'd recommend that approach in most scenarios for now.

The email should be something that's clearly named and helps identify who manages the key/credentials, e.g. serviceaccount@partnerdomain.com. As the partner, you should not share these credentials (password or API key) with the customer.

Customers who want to revoke partner access would simply delete the given admin from their admins list. The customer would never have the API key for that identity.