Lines Matching +full:data +full:- +full:role
22 operation-to-privilege mapping.
26 `ConfigureManager`, etc). A service may define custom OEM roles (read-only). A
27 service may even allow custom client-defined roles to be created, modified, and
30 The operation-to-privilege mapping is defined for every resource type and
33 authenticated Redfish role are sufficient to complete the operation in the
35 official registry collection as a base operation-to-privilege mapping. It also
49 and properties of `Mappings` are all read-only.
53 1. https://redfish.dmtf.org/schemas/DSP0266_1.15.1.html#privilege-model
54 2. https://redfish.dmtf.org/schemas/DSP0266_1.15.1.html#redfish-service-operation-to-privilege-mapp…
58 ### Phosphor-user-manager
60 Phosphor-user-manager is an OpenBMC daemon that does user management.
65 ("priv-admin", "priv-operator", "priv-user", "priv-noaccess"). These privileges
74 1. https://github.com/openbmc/docs/blob/master/architecture/user-management.md
75 2. https://github.com/openbmc/phosphor-user-manager
76 3. https://github.com/openbmc/phosphor-dbus-interfaces/tree/master/yaml/xyz/openbmc_project/User
88 1. PAM based: use Linux-PAM to do username/password style of authentication
94 phosphor-user-manager to query the user's privileges and uses a hardcoded map to
97 | Phosphor-user-manager privileges (implemented as groups) | BMCWeb Redfish Roles |
98 | -------------------------------------------------------- | -------------------- |
99 | priv-admin | Administrator |
100 | priv-operator | Operator |
101 | priv-user | ReadOnly |
102 | priv-noaccess | NoAccess |
104 To map Redfish role to their assigned Redfish privileges, BMCWeb implements the
108 | -------------------- | --------------------------------------------------------------------------…
126 3. https://github.com/openbmc/bmcweb/blob/d9f6c621036162e9071ce3c3a333b4544c6db870/redfish-core/lib…
133 1. the set of Phosphor-user-manager privileges
134 2. the mapping from Phosphor-user-manager privileges to Redfish roles
137 5. the operation-to-privilege mapping
140 and operation-to-privilege mapping need to change when the system keeps running.
141 E.g., a new micro-service is introduced and needs to talk to existing BMCs in
143 proper Redfish role and is authorized to access certain resources without
146 Another gap is that current Redfish roles and operation-to-privilege mapping
147 lead to a very coarse-grained access control, and doesn't implement the
153 resources it needs. For example, a micro-service responsible for remote power
155 corresponding ResetActions. With the existing implementation, such micro-service
166 3. Clients shall be able to modify existing operation-to-privilege mappings
171 - It rejects ill formatted modification
172 - It rejects modification of non-OEM privileges
173 - It rejects deletion of OEM Redfish roles if any user (either local or
175 - It rejects deletion of OEM Redfish privileges if any OEM Redfish role is
179 is not introduced, including non-Redfish routes (e.g., KVM websocket)
184 - The total rwfs disk usage increase is less than 100 KB on systems with the
186 - The runtime memory usage increase is less than 1 MB on systems with the
188 - The binary size increase of modified daemons is less than 100 KB on all
191 - It shall implement all overrides in the Redfish base Privilege registries
195 - BMC exposes PrivilegeRegistry which represents the current configuration
197 - Changes to resource entities shall be propagated to the current privilege
208 Linux secondary groups with prefix "priv" (includes "priv-admin",
209 "priv-operator", and "priv-user"). And a Linux user is in one of these groups
210 representing that a user is a specific Redfish role. BMCWeb then uses a
211 hardcoded table to map Redfish role to Redfish privileges.
214 well with OEM Redfish Roles where a Redfish role maps to a dynamic set of OEM
229 Redfish roles will have a fixed prefix "openbmc-rfr-". "rfr" refers to Redfish
230 role. OEM redfish roles will get prefix "openbmc-orfr-". "orfr" refers to OEM
231 Redfish role. For example, the base Redfish role "Administrator" will result in
232 a Linux secondary group "openbmc-rfr-administrator" and a local user
233 "openbmc-rfr-administrator". We can also make the vendor name ("openbmc")
238 stored as Linux secondary groups with a fixed prefix "openbmc-rfp". rfr" refers
239 to Redfish privilege. OEM privileges will have fixed prefix "openbmc-orfp".
242 **Username to Redfish Role Mapping** Mapping a username to Redfish role becomes
243 searching the group starting with "openbmc-rfr" that the user is in.
245 **Redfish Role to Redfish Privileges Mapping** Mapping a Redfish Role to Redfish
246 privileges becomes searching all the groups starting with "openbmc-rfp" or
247 "openbmc-orfp" of the user.
250 certain privileges; for example, user "PowerService" is in "openbmc-orfr-power"
251 group meaning its Redfish role is "openbmc-orfr-power"; local user
252 "openbmc-orfr-power" is in secondary groups "openbmc-rfp-configureself" and
253 "openbmc-orfp-power" groups meaning "openbmc-orfr-power" is assigned to Redfish
257 with identity (username in PAM, or CN/SAN in TLS) "power-service" is resolved.
260 +-----------------+
263 +--------|--------+
266 +-----------------+
270 +--------|--------+
272 |username:power-service
274 …+-----------------+ +-----------------+ +-----------------------…
275 …| BMCWeb |DBus: privileges | phosphor- | | Linux …
276 …| ------------------------>| user-manager | |user: power-service …
277 …| |<-----------------------| | |group: …
278 …| | privileges: | <----------->| openbmc-orfr-power …
280 …| | OemPrivPower | | |user: openbmc-orfr-powe…
281 …+-----------------+ +-----------------+ |group: …
282 … | openbmc-rfp-configureself |
283 … | openbmc-orfp-power |
284 … | openbmc-rfp-login |
285 … +----------------------------+
288 The above diagram works for LDAP users as well. A remote role or group can map
290 maps to a single Redfish role stored as local users.
292 We propose to extend the existing phosphor-user-manager:
295 2. Phosphor-user-manager provides DBus APIs to query privileges of a given user
297 The legacy groups (e.g., `priv-user`) still works as before. For example, a user
298 in both `priv-user` and `openbmc-orfp-power` will have the following Redfish
310 We propose to extend the existing phosphor-user-manager:
312 1. Phosphor-user-manager provides DBus APIs to create/delete OEM Redfish
315 2. Phosphor-user-manager keeps a maximum number of Redfish privileges; we
317 3. Phosphor-user-manager performs validation:
318 - Names of OEM Redfish privileges are unique and valid; e.g., start with
319 "openbmc-orfp-"
320 - Reject deletion of a privilege that's currently in use (assigned to any
328 POST on the RoleCollection in the AccountService to create an OEM role, with
330 the Role resource.
332 DELETE on the specific Role in the RoleCollection to delete an OEM role.
335 We propose to extend the existing phosphor-user-manager:
337 1. Phosphor-user-manager provides DBus APIs to create Redfish role
338 2. Phosphor-user-manager keeps a maximum number of Redfish roles; we propose 32
340 3. Phosphor-user-manager performs validation:
341 - Names of OEM Redfish roles are unique and valid; e.g., start with
342 "openbmc-orfr-"
343 - Reject deletion of a RedfishRole that's currently in use (associated with
349 assigned Redfish role.
360 Redfish role which is assigned a new set of OEM Redfish Privileges is mapped out
364 … Root User BMCWeb Phosphor-User-Manager Linux
366 |-------------------------->| DBus: createGroup | |
367 | Add OemAddPowerService |----------------------------->| groupadd |
368 Create | | |----------------------->|
369 OemPrivilege| | Okay |<-----------------------|
370 | Okay |<-----------------------------| Okay |
371 |<--------------------------| | |
375 |-------------------------->| DBus: createUser | |
376 | |----------------------------->| useradd + groupadd |
377 Create | | |----------------------->|
378 OemRole | | Okay |<-----------------------|
379 | Okay |<-----------------------------| Okay |
380 |<--------------------------| | |
385 |-------------------------->| DBus: createUser | |
386 | |----------------------------->| useradd |
387 Create | | |----------------------->|
388 User | | |<-----------------------|
389 | |<-----------------------------| Okay |
390 |<--------------------------| Okay | |
396 ### Non-Redfish Routes or OEM Resources
399 privileges for non-redfish routes via `BMCWEB_ROUTE`.
404 stay unchanged for non-redfish routes.
433 ### Operation-to-Privilege Mapping Data Structure in Memory
435 BMCWeb keeps a JSON like data structure in memory to represent the whole
436 Operation-to-Privilege Mapping. For a given route with known entity name, HTTP
441 still the existing bit-wise `isSupersetOf` between the required privileges of a
442 given operation on a given resource and the assigned privileges of a role.
444 ### Generate Operation-to-Privilege Mapping Data Structure at Compile Time
449 Thus, we propose to generate the data structure at compile time, it takes a
451 a variable that represent the whole Operation-to-Privilege Mapping. The input
463 ### Operation-to-Privilege Mapping Overrides
465 In routing codes, we can parse the Operation-to-Privilege Mapping Data Structure
474 the Operation-to-Privilege Mapping in-memory Data Structure.
479 +---------------+
482 +-------|-------+
489 +-----------------------+ +--------------------------------------------------------------+
490 | Any | |Operation-to-Privilege Mapping in-memory Data Structure |
491 | ResourceURIOverrides? <------>| |
493 +-----------|-----------+ | "Entity": "EthernetInterface", |
496 +-----------------------+ | "Privilege": ["ConfigureComponents"] |
498 | SubordinateOverrides? |<----->| }, |
500 +-----------------------+ | "Targets": ["Manager", "EthernetInterfaceCollection"], |
504 +-----------------------+ | }] |
506 +-----------|-----------+ | }] |
509 | +--------------------------------------------------------------+
510 +-----------------------+ ^
512 | PropertyOverrides? |<----------------------+
513 +-----------|-----------+
529 With the proposed Dynamic Operation-to-Privilege Mapping Data Structure, and
530 DBus APIs that phosphor-user-manager provides, the implementation is trivial:
531 convert the JSON data structure into a JSON response.
535 Though the Redfish spec declares PrivilegeRegistry to be read-only, this design
570 ### Persistent Data
573 maximum number of roles and privileges being set, the total persistent data will
576 To minimize size of persistent data, we propose that BMCWeb only stores the
577 serial of PATCH requests on the PrivilegeRegistry. This data can be stored in
584 small piece of data to disk is acceptable.
587 disk usage. Most upstream systems also have several MB of read-write partition
592 persistent data added.
598 We can infer the entity from the URL by building a Trie like data structure.
604 1. New DBus interfaces on phosphor-user-manager
605 2. New persistent data managed by BMCWeb will be added on BMCs
612 No new repository is required. Phosphor-user-manager and BMCWeb will be modified
622 1. verify base Redfish roles, privileges, and base operation-to-privilege
628 4. verify operation-to-privilege can be modified via PATCH on PrivilegeRegistry;