|
|
Post by AMI_shirleyh on Dec 8, 2020 11:42:13 GMT
Bootstrap accounts shall be usable only on the host interface
Query 1 : Do we need to show Bootstrap Accounts in GET Account Collection or GET Instance for OOB Users ?
Query 2 : In ManagerAccount Schema, it would be helpful if there is an Account Type for Bootstrap HI Accounts.
"AccountTypes": {
"enum": [
"Redfish",
"SNMP",
"OEM"
]
|
|
|
|
Post by mraineri on Dec 8, 2020 15:07:43 GMT
For question 1, yes, there are potential administrative use cases where an OOB administrator might need to clean those sorts of accounts.
For question 2, a boot strap account is a Redfish account. So, you should be able to make that sort of mapping. But as I'm typing this it might make sense to differentiate a bootstrap account from other accounts in this manner for the sake of identifying them in an interoperable manner. We'll need to discuss this aspect further.
|
|
|
|
Post by AMI_shirleyh on Dec 9, 2020 4:48:06 GMT
So from your reply I understand that BootStrap Account is similar to normal accounts and the Administrator can perform all HTTP Methods as the normal Redfish account namely PATCH,DELETE once created. Please confirm.
Also for differentiation, either we can have Account Type as Redfish-HI or any other new attribute like BootStrap with a Boolean value.
We need this to delete all the BootStrap Accounts on Reset of a Service/Host.
Thanks
|
|
|
|
Post by mraineri on Dec 10, 2020 14:19:43 GMT
Yes, your understanding is correct; and administrator can perform normal HTTP operations on the account just like any other account.
Since "AccountTypes" really maps to the different services/protocols the account can use, I'm thinking a boolean property to show it's a bootstrap account might be a better approach.
|
|
|
|
Post by mrrobert on Feb 15, 2023 3:58:45 GMT
Understand about "Bootstrap accounts shall be usable only on the host interface": The Bootstrap accounts are just able to use Redfish API via Host Interface and can't use OOB interface.
For example: Create a bootstrap account (<bootstrap_acc>:<bootstrap_pwd>) at Account number 2
- OOB request will be prohibited: curl -X GET --user <bootstrap_acc>:<bootstrap_pwd> -H "Content-Type: application/json" --insecure https://<BMC_IP>/redfish/v1/AccountService/Accounts/2
- Host Interface request will be allowed: curl -X GET --user <bootstrap_acc>:<bootstrap_pwd> -H "Content-Type: application/json" --insecure https://<HostInteface_IP>/redfish/v1/AccountService/Accounts/2
Is my understanding correct?
|
|
|
|
Post by mraineri on Feb 15, 2023 13:58:21 GMT
That's correct; since the requestor of the credentials is entirely inside the system, the credentials have no business being used out of the box. This is to help minimize a potential attack surface from outside the box.
|
|
|
|
Post by mrrobert on Feb 16, 2023 1:15:28 GMT
|
|
|
|
Post by AMI_Mani on Feb 22, 2023 7:24:30 GMT
That's correct; since the requestor of the credentials is entirely inside the system, the credentials have no business being used out of the box. This is to help minimize a potential attack surface from outside the box. Again we don't have privilege or account type to distinguish whether user is from bootstrap account when getting OOB request. Based on implementation we need do extra process for identifying bootstrap account in OOB request. Do we have any way or plan in future for identifying bootstrap account using standard way. What error message needs to return when trying bootstrap account for OOB request. Thanks, Mani |
|
|
|
Post by mraineri on Feb 22, 2023 13:42:58 GMT
The Redfish Specification defines the interface layer; how you do work within your solution to support the functionality is entirely up to you.
Like with other authorization errors, HTTP 401 would be the status code with some message simply stating "invalid credentials" is all you'd want to show. Like with any other authorization errors (even beyond Redfish), exposing details about why it failed authorization is a security weakness.
|
|
