|
|
Post by ratagupt on Jul 26, 2019 3:03:44 GMT
In Linux, a user can be a part of multiple groups. We have a similar requirement where on a system we have multiple interfaces(IPMI/Redfish/SSH etc).
We were looking for flexibility where admin can create the user and assign the groups to the user. eg Suppose we have two groups defined (Redfish and IPMI)
user1 can be a part of IPMI and Redfish group. user2 is only part of IPMI.
By doing so user1 can access the IPMI and Redfish interface, however, user2 can only access the IPMI interface.
To achieve the above use case can we add the group's property in the ManagerAccount schema for the account?
We also need to add the group's schema where we need to define the group properties to accommodate the above requirement.
Do we have something in the plan like this?
|
|
|
|
Post by ratagupt on Aug 21, 2019 8:29:43 GMT
Mike/Jeff
Any suggestion on the above proposal.
Ratan
|
|
|
|
Post by jautor on Sept 17, 2019 20:19:55 GMT
Hi Ratan,
We discussed this in the group (and I apologize that I didn't reply here...), and there was not support for adding the 'group' concept to the local accounts. We don't see a large number of local users generally created (so adding groups seems like overkill) in end user environments. We'd much prefer that user grouping be handled by network/directory-based authentication as that is the preferred path for larger scale deployments.
We also discussed (and this will probably come up again) the ability to specify what types of access are provided for the account (IPMI and/or Redfish access, for example) - but as many implementations today do not "integrate" their user databases (meaning a separate list of accounts for IPMI), this is functionality that may never get implemented.
Jeff
|
|
|
|
Post by josephreynolds1 on Sept 10, 2020 15:58:43 GMT
I'm not sure we are talking about the same thing. This is NOT a desire to group together multiple accounts that should all have the same access. The desire is to control which BMC interfaces a user is allowed to access. For example, the joeuser account is allowed to access the BMC's Redfish and SSH interfaces but not its network IPMI interface. The OpenBMC project defines "group roles" [1] which control which users are allowed to access BMC interfaces. The "group roles" are ssh, ipmi, redfish, and web (for webui access). For example, if the joeuser account has group roles ssh and redfish but not ipmi, that user is allowed to access the BMC's Redfish and SSH services, but requests to access the BMC's network IPMI service are rejected. (Under the covers these are implemented as Linux groups.) [1]: github.com/openbmc/docs/blob/master/architecture/user-management.md#supported-group-rolesHow can OpenBMC do this? Will Redfish extend the ManagerAccount AccountTypes, or should OpenBMC use OEMAccountTypes? - ssh: can we add this to ManagerAccount.AccountTypes? - ipmi: can we add this to ManagerAccount.AccountTypes? - redfish: is already present in ManagerAccount.AccountTypes. - web: can we add this to ManagerAccount.AccountTypes, or should this be added to OEMAccountTypes? |
|
|
|
Post by rthomaiy on Sept 12, 2020 7:20:12 GMT
Jeff, Ratan, Joseph, Redfish support these grouping indirectly. i.e. In terms of Session, SessionTypes are used to differentiate the same already (Excerpt from redfish.dmtf.org/schemas/v1/Session.v1_2_1.json) "SessionTypes": { "enum": [ "HostConsole", "ManagerConsole", "IPMI", "KVMIP", "OEM", "Redfish", "VirtualMedia", "WebUI" ], We need to expose the same as part of ManagerAccountAccount --> AccountTypes (Currently OEM, Redfish, SNMP is there) (Need to add fields from SessionTypes ). Note: OEMAccounttype must be used for OEM Account Type (similar to OEMSessionType). Note: As Redfish recognizes other services, it needs to list all the accounts in a Manager, even if there is an account which is not enabled for Redfish (IPMI don't recoginize the same, i.e. IPMI can't list users which doesn't have IPMI group support). |
|
|
|
Post by josephreynolds1 on Sept 15, 2020 19:22:43 GMT
Sounds good to me. I think there are some additional considerations for IPMI. Can we ask the IPMI maintainers to comment on this?
How does the Redfish operation of adding & removing IPMI from ManagerAccount.AccountTypes interact with IPMI's user management?
1. Does it add & remove that user from the list of 16 IPMI users? `user set name #user_slot# "newuser"` and `user set name #user_slot# ""`.
2. Or does it enable & disable that IPMI user's access as in `ipmitool channel setaccess 1 #user_slot# ipmi=off`?
I prefer option 1 because it seems cleaner.
Note that an IPMI service limits to 16 users. What should happen when you try to create a 17th account with has the IPMI AccountType, or try to add the IPMI AccountType to more than 16 accounts? I assume this would fail with an appropriate error.
How to handle the IPMI password length and recoverability requirements? Do we want to require the IPMI AccountType be provided when the ManagerAccount is created, and not allow it to be PATCHed in later? (<--I vote no.) Can or should an implementation also require the ManagerAccount password be changed in the same operation that adds IPMI access? For example, a new Base message like, "Adding IPMI to AccountTypes requires the password to be changed at the same time".
|
|
|
|
Post by josephreynolds1 on Sept 15, 2020 19:40:05 GMT
|
|
|
|
Post by rthomaiy on Sept 16, 2020 5:50:09 GMT
Hi Joseph
In OpenBMC we are not tracking user names with user ID, it is left to IPMI itself. When we create new user it is added in to the system, and IPMI will mark it to a user ID slot (next available one).
phosphor-user-manager today tracks the number of user in the system (including IPMI), and accordingly return the error (https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/xyz/openbmc_project/User/Common.errors.yaml) Say when we reached IPMI User limit 16, NoResource error with "ipmi user count reached" as reason is returned, whereas if we have reached the max user account of the system can support, then it currently returns NoResource with "Non-ipmi user count reached" (Which we can rename to "system user limit reached").
In OpenBMC Group based restriction is also returned
Say, When user name length is > 16 and user group includes IPMI, then error --> UserNameGroupFail (With reason IPMI length) is returned, whereas if the username is > system maximum say 30, then we return Invalid Argument with reason User name + Invalid length.
Reg the password, it should be fine to allow the password update separately (Reason: Admin, can just add one user to IPMI Group, and later that user can change his password and access IPMI RMCP+). We don't need to enforce Admin to update the password during the change of group. I don't find any security issue, as without changing the password, other session establishment will work, only RMCP+ won't work.
|
|
|
|
Post by josephreynolds1 on Nov 11, 2020 0:25:08 GMT
I want to understand the meaning of the `WebUI` SessionTypes enum value (per redfish.dmtf.org/schemas/v1/Session.v1_2_1.json). Does it refer to legacy web applications, to web application built on top of Redfish REST APIs, or both? For web applications built entirely on top of Redfish REST APIs, I don't see how the WebUI value could be enforced. Because in this case, the web application is downloaded to the browser before any authentication, and then authentication is performed by Redfish API, so the `Redfish` SessionTypes enum value would control access. Effectively, WebUI and Redfish access are equivalent. Is that understanding correct? If so, such an implementation would not need the WebUI value or could tie them together. Is that correct? |
|
|
|
Post by josephreynolds1 on Nov 12, 2020 16:14:23 GMT
Answering my own question: the implementation in the example above does have a web interface, so it should expose the WebUI value. Then because the Web application is built entirely from Redfish REST APIs, the WebUI and Redfish values should be tied together.
|
|
