Creating an API User with Administrative Access ?

[goodwill]

Is it possible to create a master API key that grants full administrative access to all API endpoints for example, the ability to call

GET /api/v1/ActionHistoryRecord

modify entities, and perform other privileged operations?

I’ve already created a role with all permissions, but it still isn’t sufficient to access the admin area.

[victor]

API User cannot have administrative rights.

[jamie]

Is it possible to create a master API key that grants full administrative access to all API endpoints for example, the ability to call

GET /api/v1/ActionHistoryRecord

modify entities, and perform other privileged operations?

I’ve already created a role with all permissions, but it still isn’t sufficient to access the admin area.

a great way to get hacked

[goodwill]

jamie

EspoCRM already uses the same REST API that the UI does for pretty much everything. Most CRMs out there (Zoho, Odoo, ERPNext/Frappe, SuiteCRM) also expose metadata, field management, and even some system configs through their APIs. Exposing admin features through API does not magically make a system less secure. Weak passwords or over-privileged accounts are what get people hacked.

Even the Espo docs say:

EspoCRM is a single page application so the frontend uses REST API to connect with the backend. All operations you perform using the UI, you can implement via API calls using your programming language.

https://docs.espocrm.com/development/api

This is true in principle. Right now though, if you want to do admin-level stuff you need to pull some tricks like passing admin cookies. It is not officially supported through Roles. CRUD on entities, settings, templates, field metadata, all runs on the same backend the Admin UI uses. I guess the currently exposed endpoints cover most integration needs, but that does not mean exposing more would suddenly open security holes. If someone gets a privileged account, they can destroy the system from the UI anyway. A bad admin password is enough. No attacker needs to try stealing ENV secrets or do anything fancy.

yuri

I love what you and the EspoCRM team are doing. Espo helped me a lot and I really appreciate the project.
I’m just trying to understand the thinking behind this.
Is keeping admin-level operations out of ( Roles ) the official API a deliberate design choice or just not a priority yet?

My guess is this ties into Espo’s flexible ACL and field level access controls. It is a very capable permissions system that applies deeply across entities. Supporting admin configuration and extensions through the exposed API and Roles while keeping those controls consistent would probably be a big job to maintain without breaking things and it's not priority.

[yuri]

Roles cover user-level features. Admin features are not controlled by roles. More correct to say, when a particular feature is designed, a developer either implement the Role level access control or not. If not, it implies that only admin has access to it.

If you want to expose some admin feature to API users, you will need to custotmize it so that it's controlled by roles.

You can also use the admin user instead of API user.

[yuri]

Whether it's easy to enable access control for a particular scope, it depends on many factors. For some cases, it can be a matter of a few lines
in one metadata file.

metadata > scopes > {scope}

"acl": true,
"aclLevelList": ["all", "no"],
"aclActionList": ["read"]

https://docs.espocrm.com/development/metadata/scopes/#acl

[goodwill]

If you want to expose some admin feature to API users, you will need to custotmize it so that it's controlled by roles.

You can also use the admin user instead of API user.

Can you point me in the right direction for where to start if I want to expose specific admin features to an API user ?

Also when you say “use the admin user,” do you mean authenticating directly with the admin account over the API? I did not know that was supported, so I want to make sure I understand what you meant.

[yuri]

> Can you point me in the right direction for where to start if I want to expose specific admin features to an API user ?

custom/Espo/Custom/Resources/metadata/scopes/ActionHistoryRecord.json

{
    "acl": true,
    "aclLevelList": ["all", "own", "no"],
    "aclActionList": ["read"]
}

But it won't be enough for your case, as the ACL levels are forcibly set for users here. The only way to unset it, is to use additional metadata builder.

>

Anything that can be done via the UI can be done via the API as the frontend communicates with the backend via the same API. You will need to authenticate under the admin user using the basic authentication (rather than API Keys).

[goodwill]

Thank you. Every time I am blown away by how well thought out the underlying utils are.