Base on our design, we have a Role "HostInterfaceAdministrator" is for create bootstrapping account. And our Engineer make this role as a "Restricted Roles" recently. Per the discussion with you guys, my understanding is "Administrator account can PATCH/DELETE the bootstrapping account" If the Role of bootstrapping account become a "Restricted Roles", we can't perform PATCH/DELETE for this account anymore. Is this correct? Or our design have some problem?
To be clear, are you saying the account created via the bootstrap method is assigned the role "HostInterfaceAdministrator", meaning, the new user created after invoking the IPMI "Get Bootstrap Account Credentials" command will contain the role "HostInterfaceAdministrator"?
If this is the case, you're right in that an Administrator would not be able to PATCH or DELETE the user. However, this sounds like a potential design issue. Restricted roles are intended to be set up for service providers to have well-known access points to the system. Think of cases where a user leases a system from a third party; the third party would want to ensure they maintain their access to the system in order to service the system when the customer has an issue or their lease is up and they need to prepare the system for the next user. Setting an end user role like "HostInterfaceAdministrator" as a restricted role does not seems like an appropriate setting.
Yes, the bootstrapping account created by the IPMI "Get Bootstrap Account Credentials" command will contain the role "HostInterfaceAdministrator". We use this role for make sure BIOS data can be push to Redfish when host power on. So you mean the "Restricted Roles" normally use for like "AD", "LDAP" account right? And we should not set the role "HostInterfaceAdministrator" as a restricted role.
No, I don't necessarily mean that it's strictly tied to AD or LDAP. It's more for cases where ownership of a system is shared between two parties. For example, the "Contoso Server Farm Company" might lease equipment to customers. As part of the leasing agreement, their customers might have access to Redfish to perform system management. However, Contoso might need to ensure they still have access when the lease expires or other events take place. So, Contoso would have a restricted role that ensures they maintain access to the system. They likely have their own local admin account that's locked out and the customer is not able to access. I would not recommend using HostInterfaceAdministrator as a restricted role given the use case.
Two more doubts. Here are some description under the spec. 1. "When a standard role is restricted, services shall provide the AlternateRoleId property to reference a non-restricted custom role intended for clients to use as an alternate. Services may pre-define or create accounts that are configured with a restricted role."
2. A service may restrict any privilege, including standard and OEM privileges. The RestrictedPrivileges and
RestrictedOemPrivileges properties in the AccountService resource shall specify the restricted privileges.
For 1, But if we pre-define another role (like SuperAdmin), So "the AlternateRoleId property to reference a non-restricted custom role" is unnecessary right? For 2, Are we required to shows both "RestrictedPrivileges" & "RestrictedOemPrivileges" or we can choose one to shows?
1) This depends on what roles you made as restricted in your service. If you set a role like "Administrator" to be restricted, then you might want to use AlternateRoleId to point to SuperAdmin if you want clients to make accounts with the SuperAdmin role instead of Administrator. 2) You only need to show whatever you've implemented; if you don't have any restricted privileges, but have restricted OEM privileges, then you would need to show RestrictedOemPrivileges. If you don't have any restricted privileges, then you don't need either property.