|
|
Post by f31816 on Apr 23, 2020 13:28:45 GMT
As HostInterface specification defined,
• Authentication, and privilege authorization equivalent to the out-of-band Redfish API as specified
in DSP0266 shall be supported by the implementation when enabled from the Redfish Service
configuration.
Question 1. Is host interface apply the privilege-registry control also?
Question 2. If the answer is yes, Host Interface specification also has the content as below.
Host Interface and out-of-band API must be the same (where possible) so that client apps have
minimal (if any) change to adapt
There is possible to have other REST APIs which purpose for pushing redfish data from Host only, the oem for privilege is required in such case.
But redfish not define the oem detail for privilege registry.
Question 3. Redfish schema has ExternalAccountProvider, is those external account(LDAP) able to access redfish via Host Interface?
|
|
|
|
Post by mraineri on May 2, 2020 23:46:56 GMT
For question 1: Yes, the privilege registry applies the same to users coming over the host interface as it does for an external interface.
For question 2: At this time, we don't see the need to differentiate behavior in Redfish from the host interface vs external interface. Largely this is so clients running on a system communicating with their manager over the host interface work exactly the same as if they were running from an external source. If there are particular use cases where you'd like to see some data handled differently on the host interface than an external interface, it would be good to send us feedback about those so we can discuss them in the forum and see what the right answer is.
For question 3: Yes, if a client attempts to authenticate over the host interface, it's entirely possible the authentication will in turn be performed against an external account provider (like LDAP or Active Directory). There's no restriction to only using local accounts.
|
|
|
|
Post by f31816 on May 15, 2020 9:29:15 GMT
The HostInterface specification v1.2 has the content for it can support optional support no authentication. (https://www.dmtf.org/sites/default/files/standards/documents/DSP0270_1.2.0.pdf)
From my understanding, this must against the privilege registry due to the no authentication user doesn't have role.
Please help to confirm is that a bug in HostInterface specification?
|
|
|
|
Post by mraineri on May 15, 2020 15:40:02 GMT
This was brought up some time ago and should be addressed in version 1.2.0 of the HostInterface resource. A property called "AuthNoneRoleId" was added to configure what role is applied to a client that is not performing authentication. So, you can limit local users to "ReadOnly" if the use case is for them to simply poll the device, or you can go so far as to set it to "Administrator" if you really trust the local users on the system for having full access to the service.
|
|
|
|
Post by f31816 on Jun 19, 2020 8:09:39 GMT
For question 2,
If I am going to define the Redfish API set with the abilities for getting host data and stored into DB.
For the case, running an agent on host machine to collect host information(memory, process,...) and pushing the data by redfish API via Host Interface.
Logically, redfish API treat POST as create for collection resource.
So utilize the existing URIs with HTTP Post for create new resource is reasonable if not defined POST from Redfish specification. (Same logic can be applied into PATCH/DELETE)
Question 1. Is possible to utilize the existing Redfish URIs or need to have OEM URIs for pushing data?
Question 2. If yes, how the special user(data provider)/privilege be part of privilege registry? Create another OEM privilege?
|
|
|
|
Post by mraineri on Jun 22, 2020 17:32:42 GMT
So, at this time, specifically for your example with MemoryCollection and ProcessorCollection, Redfish currently does not allow anyone to perform POST operations on those resources to create Memory or Processor resources. The current language in the spec doesn't allow implementations to open that for new capabilities (you can restrict capabilities, but you cannot add capabilities).
This sort of functionality is generally handled in an implementation specific manner by system firmware (BIOS/UEFI), but we've been silent in this space so far. Generally implementations have proprietary methods for registering processors and memory, and they do not use the Redfish model directly to fill in these details.
|
|
