Authorization Service built-in roles
The Authorization Service API comes with a number of in-built roles that give various permissions to callers.
This document defines the built-in roles and what they grant to users, as well as what roles are assigned to CERN and non-CERN accounts by default.
List of API roles and their description
The following table contains all the roles defined for the Authorization Service and what they mean:
|administrator||Full control on the Authorization Service.|
|afs_auth_admin||AFS Administrators can manage AFS resources for all users.|
|afs_user||Authorization Service AFS resource user. Can own an AFS account and workspace.|
|application_manager||Allowed to create and manage applications for other users.|
|application_reader||Allowed to read applications.|
|application_user||Allowed to create and own applications.|
|cern_account||CERN account, applies to users that log in with the highest LoA provider (CERN). Allows account operations.|
|deny_password_reset||Accounts which are not allowed to reset their passwords.|
|groups_administrator||Full control on all groups in the Authorization Service.|
|groups_reader||Allowed to read groups.|
|groups_user||Allowed to create and own groups.|
|identity_administrator||Full control on all identities and accounts in the Authorization Service.|
|identity_reader||Allowed to read identities.|
|identity_user||Allowed to create and own non-primary identities.|
|resource_administrator||Full control on the Authorization Service resources.|
|security_team||Security Team members can perform all service desk operations, including blocking and unblocking resources for security issues.|
|service_desk||Service desk members can perform operations on behalf of other users in the Authorization Service Service Desk Portal.|
Role mappings to groups
These are the groups that are mapped to each of the roles described above. We will be splitting the role-group mappings into two different tables.
Mappings to closed groups
First, we have the groups that users cannot request membership for. In case you need any roles that are mapped strictly to these closed groups, you should open a SNOW ticket stating your request.
|Group identifier||Role names|
|cern-accounts-primary||application_user, groups_user, identity_user|
|cern-accounts-service||application_user, groups_user, identity_user|
|cern-active-users||application_user, groups_user, identity_user|
|secondary-identities||application_user, groups_user, identity_user|
|service-identities||application_user, groups_user, identity_user|
|authorization-service-applications-managers||application_manager, application_reader, groups_reader, identity_reader|
Mappings to groups that allow self-subscription
The second table contains the roles mapped to groups which allow self-subscription. You can either request membership in the groups-portal or on the application-portal group membership tab, in the case that you want to call the API using an application's client ID and secret.
For most of these groups, a request will be submitted to the Authorization Service team and you may be asked to clarify why you require that specific role.
|Group identifier||Role names|
Roles assigned by default
Non-CERN accounts (guest, social accounts)
By default, no roles for the API are assigned to guest or social accounts. The applications and groups portals should not be functional for these accounts.
However, users can still view and modify information about their accounts on the users portal.
The following roles are assigned by default to all the CERN account types (primary, secondary, service):