New Redfish roles for ServiceRep and OemRep

Joseph Reynolds jrey at
Tue Feb 18 11:48:58 AEDT 2020

On 2/17/20 1:29 AM, Thomaiyar, Richard Marian wrote:
> We need to make sure user account are not getting created in this role 
> by end-user. i.e. when creating a new user, these options must not be 
> provided. We need to have a separate way of selecting this role or 
> instead of not defining as role, we can add this as some mode in redfish.

Yes, I am looking for a solution to this: I don't want a BMC admin to be 
able to create a user account and escalate their privilege to the 
ServiceRep or OemRep role.  Only the Oem and Service organizations 
(which may be different) should be able to access the BMC with these roles.
Redfish offers no help here and simply notes that the BMC admin can 
become whatever role they want.  It's up to us to define what we need.

Some options are:

1. Don't define the role (or disable it in your distro).  ==> This 
doesn't help us.

2. Have a predefined user with that role, and don't give those 
credentials to the BMC admin.  ==> This doesn't let us change the 
credentials, and relies on the credentials remaining secret, which 
violates best practices.

3. Have a special mode that makes additional operations available. ==> 
This requires you to do one of:
(A) Permanently disable that special mode (like FieldMode or some other 
process during the manufacturing process).
(B) Have a way turn the mode back on ... but how to do that securely so 
the OEM or service can do it, but not the Admin.  Maybe have the admin 
install a certificate?
(C) Have a secret way to toggle the mode, which violates best practices.

4. Bake a special OemRep and ServiceRep certificate into the BMC 
firmware image and use that to authenticate the ServiceRep.  I tried to 
explain in an IBM issue 
(, with the relevant 
parts cut & pasted & edited here:
 > To ensure the admin cannot assume the ServiceAgent and 
ManufacturerRep roles, I think we would need to:
 >  * Have a certificate baked into the firmware image.
 >  * Use the baked-in certificate to validate the certificate the 
ServiceAgent would have to uploads as part of their authentication. The 
certificate is rejected if it wasn't signed by the baked-in certificate. 
In this way, the service agent could gain access, but the Admin will not 
have access.
 >  * Note the Admin will still have full control over the service 
agent's account. In this way, the admin and service agent would have to 
agree before the ServiceSystem privilege could be used to perform a 
sensitive operation.

Despite the challenges, I think it is valuable to begin to create the 
ServiceRep role, even if we don't have a good way to lock out the admin.

> Note: Currently we are using SpecialMode 
> ( 
> called Manufacturing mode, and certain activity can be done, when we 
> are in this mode (i.e. Administrator role user in this mode will be 
> able to do certain operations).

Thanks for explaining.  I had not considered using a special mode for this.

- Joseph

> Regards,
> Richard
> On 2/15/2020 1:51 AM, Joseph Reynolds wrote:
>> This is to propose two new Redfish roles:
>> The BMC Administrator should not have access to operations involving 
>> the manufacturing process or servicing the host because these 
>> operations can damage the system or cause unintended operation.
>> Examples of access needed:
>> 1. ServiceRep - Needs to access BMC operations to service the system, 
>> such as re-enabling locked out field replaceable units (FRUs) after 
>> replacing a defective unit.
>> 2. OemRep - Needs to access BMC operations to test the host system, 
>> such as how the system responds to overheating.
>> I believe these roles are clearly distinct from role=Administrator or 
>> any other role.
>> The roles should NOT have access to the BMC's configuration or user 
>> management.  For example, the BMC admin will be able to lock out any 
>> service agent or OemRep using the regular user management functions.
>> Does anyone else need for these roles?  If so, I will try to get them 
>> into Redfish.
>> - Joseph
>> This topic was discussed briefly in the OpenBMC security working 
>> group, 2019-11-27: 
>> See also:

More information about the openbmc mailing list