Security and Authorization Roles in midPoint

Last modified 27 Jan 2025 10:36 +01:00

Table of Contents

Structure of security roles
- High level structure
MidPoint initial objects
Authorization roles
Examples of other roles
Open questions

This document contains working documentation to preparation of security roles for midPoint.

Structure of security roles

There will be top level business role "Security officer" - this role will not probably be initial role in midPoint as its content is organization specific. We will define application roles for definition of access level to midPoint and authorization roles defining actual authorization blocks for operations.

High level structure

Table 1. High level structure
Business Role	Application Role	Note
Security Officer		Security officer within an organization - privileged access to multiple systems, not only midPoint.
	midPoint:Security Officer	Security officer within midPoint
	…	Other roles providing access to other applications…
Internal Auditor		Internal auditor within an organization - read-only auditor access to multiple systems, not only midPoint.
	midPoint:Auditor	Auditor role within midPoint
	…	Other roles providing access to other applications

Each application role will consist of a list of authorization roles as defined below:

Table 2. Security application roles - proposed definition of initial objects
Application Role	Authorization Role	Note
midPoint:Security Officer		Security officer within midPoint
	midPoint:data administrator	Can manage all data
	midPoint:report administrator	Can manage reports
	midPoint:audit reader	Can read audit events (history).
	midPoint:resource reader	Can read configuration of provisioning.
	midPoint:config reader	Can read midPoint configuration.
midPoint:Auditor		Auditor role within midPoint
	midPoint:data reader	Can see all data.
	midPoint:report user	Can read all created reports and run reports.
	midPoint:audit reader	Can read audit events (history).
	midPoint:resource reader	Can read configuration of provisioning.
	midPoint:config reader	Can read midPoint configuration.

MidPoint initial objects

We should define 2 application roles + list of authorization roles:

Application roles:

midPoint:Security Officer
midPoint:Auditor

These roles should provide access to midPoint for defines security functions. They are not customized to specific archetypes/situations. If necessary, they, or the copies must be tuned by engineers in specific projects.

Authorization roles

Table 3. Structure of authorization roles
Line	Authorization role	Description of authorization level	Note
1	midPoint:user reader	Read users and their assignments	No access to user’s history.
2	midPoint:data reader	Read all data - even users
3	midPoint:report reader	Read created reports.	Can’t run reports.
4	midPoint:audit reader	Read audit events - and objects history	We can’t limit user’s access to audit objects. So full access or no access to audit. Of course - read only.
5	midPoint:resource reader	Read resource configuration using resource GUI
6	midPoint:markReader	Read object marks assigned to the objects
7	midPoint:config reader	Read whole configuration.
8	midPoint:certification user	Run and process already prepared certification campaigns.
9	midPoint:report user	Run prepared reports.	Allowing creation and starting of report tasks.
10	midPoint:simulations user	Define and run simulations	Assignment/inducement configuration can be simulated only if configuration modification is not allowed.
11	midPoint:task user	Read and run tasks	Run any task.
12	midPoint:user administrator	Full administration of all users	All operations on objects of UserType except displaying object history. Access to audit not defined here.
13	midPoint:role administrator	Full administration of all roles.	dtto as above
14	midPoint:service administrator	Full administration of all services.	dtto as above
15	midPoint:case administrator	Full administration of all cases and workitems.	dtto as above
16	midPoint:certification administrator	Full administration of all certifications and certification campaigns.	dtto as above
17	midPoint:policy administrator	Full administration of all policies.	dtto as above
18	midPoint:report administrator	Full administration and usage of all reports. Running reports.	dtto as above
19	midPoint:task administrator	Full administration and usage of all tasks.	dtto as above
20	midPoint:simulations administrator	Full administration and usage of simulations.	dtto as above
21	midPoint:archetype administrator	Full administration of all archetypes.	dtto as above
22	midPoint:marks administrator	Full administration of all object marks.	dtto as above
23	midPoint:resource administrator	Full administration of all resources.	dtto as above
24	midPoint:data administrator	Administration of all data in midPoint.	Allow full control over all objects in midPoint. The "data" can be problematic.
25	midPoint:config administrator	Administration of configuration.

Examples of other roles

Table 4. Examples of other roles
Application Role	Authorization Role	Note
Example: midpoint:Security officer - read only		Example of security officer in organizations where he is not modifying data - just performing control function.
	midPoint:user administrator	Providing access to block users in emergency, or override processes for some situations.
	midPoint:data reader
	midPoint:report user
	midPoint:audit reader
	midPoint:resource reader
	midPoint:config reader
Example: midPoint:Role manager		Security function responsible for management of roles.
	midPoint:data reader
	midPoint:role administrator
	midPoint:archetype administrator
	midPoint:audit reader

Open questions

REST access - allow to whom ?
What object types we will consider as "data" and which are "configuration"

data

UserType, RoleType, ServiceType, OrgType, PolicyType

configuration

ObjectmarkType,

?

ArchetypeType,
Shouldn’t we add some attribute to all objects specifying if the object is data or configuration ?
- Example: Authorization roles mentioned in this document are definitelly configuration ano not data.
  Users who does not have authorization to "modify configuration" should not have access to modify these roles.
- In the RoleType, we can specify what is configuration and what is data, excluding "Authorization role" archetype and "system roles" archetype (for sure?), just this:
  - is not consistent across all object types - other object types (e.g. Orgs) may have different definition of data and configuration
  - is harder to read for engineers - and not clear everywhere. isConfiguration (True/False) is much cleaner.
  - is even "system roles" only configuration ? Can’t it be data as well ? Can we use other system roles for this ?
  - in each project it would be easier to define what is configuration and what is data if engineer can define just objects in the project.
  - is slower for processing - getting and comparing single attribute value is the fastest operation. And this can be compared very often.
Should we use archetype "System role" ? Existing midpoint roles are using it, but we need 2 levels - system roles and authorization roles.
- Can’t engineer define other "system roles" for other systems ? Shouldn’t we have "application roles already" ?
  - If we create midpoint:Security officer as "application role", then - how we define what application roles are data and what is configuration ?

Was this page helpful?

YES NO

Thanks for your feedback