Hello,

At the contact level, API access is only used for version 1.

In API v2, menu access is used to define access to associated endpoints.

So if your users have access to “Resource Status” menu, they can use {protocol}://{server}:{port}/centreon/api/{version}/monitoring/resources/<resources> endpoints.

We don't want to apply the old system to the new APIs because it complicates development.

Furthermore, the APIs used by the web interface are those available publicly.

Regards,

Understood, so the v2 does have a completely seperate permission architecture. I’m ok with that.

Does this mean that contacts don’t need those “v1 options” to be able to reach the V2 Api ?

And if so outside of the restrictions based on resources that you mentionned, what would be the permissions restricting the use of the V2 ? My point was if i was to allow users connecting with openID to be considered as admin to do configuration on that centreon, can i autoprovide those users or do i need to always enable the “admin” option manually ?
 

The “administrator” option allow to manage the Centreon Platform (authentication, authorization, backup, etc).

You must create a Centreon profile (ACL) to allow access to configuration menu with edit (write) mode and based on your IdP groups, link your users to correct profile.

Regards,

I understand that, but i want to understand if that “Admin” flag can be assigned to ACLs or is it limited to only manual affectation.

I will look into how to assign granular exploitant permissions, but if i want to assign some users as admins automatically, i don’t know how to do that. Maybe that’s by design ?

If this is a choice then this idea is invalid and can be closed.

Hi ​@Alexandre Belhomme ,

We consider the "Administrator" flag to be a super role whose sole purpose is to administrate the Centreon platform (authentication management, authorization, etc.) and that it must be managed carefully (manually).

Using ACLs on menu access, resource actions, and resource access, it is possible to create standard profiles and assign them based on the attributes of your users in your identity provider.

Regrds

Sounds clear to me, thank you ​@lpinsivy .
This topic can be closed then, sorry for missunderstanding that aspect of permissions.