|
|
Post by garyliu on Jan 4, 2023 18:23:56 GMT
In Redfish_1.3.0_PrivilegeRegistry.json, there is the PATCH privilege for EventDestination
{
"Entity": "EventDestination",
"OperationMap": {
"PATCH": [
{
"Privilege": [
"ConfigureManager"
]
},
{
"Privilege": [
"ConfigureSelf"
]
}
]
}
}It means the Privilege ConfigureManager or ConfigureSelf can patch EventDestination
However, the description of "ConfigureSelf" in schema Privileges.json is "Can change the password for the current user account and log out of their own sessions."
Why the stander privilege registry allow ConfigureSelf to PATCH EventDestination?
How to determine if the event destination belongs to current user?
|
|
|
|
Post by mraineri on Jan 4, 2023 19:04:34 GMT
A user that created an event destination can modify their own event destination, hence why "ConfigureSelf" is listed. The expectation is the service will keep track of who created the event destination internally, and if the user performing the PATCH request matches, then they are allowed to perform the request. Administrators with the "ConfigureManager" privilege has full access to all event destinations for managing.
Ultimately how to do this determination is up to you as an implementer.
|
|
|
|
Post by Caffrey on Jan 5, 2023 19:15:03 GMT
The case we have now is to use Administrator account to create a subscription "/redfish/v1/EventService/Subscriptions/1" then use ReadOnly account who has ConfigureSelf privilege to PATCH it. I think from privilege map we can only know that "ConfigureSelf" shall allow PATCH operation for destination URI but cannot know the rule you mention "The expectation is the service will keep track of who created the event destination internally". I think ConfigureSelf might apply for account resource only. Creation (POST) privilege already defined properly which means only account has proper privilege can create it or modify it.
Please kindly help to confirm again.
{
"Entity": "EventDestination",
"OperationMap": {
"GET": [
{
"Privilege": [
"Login"
]
}
],
"HEAD": [
{
"Privilege": [
"Login"
]
}
],
"PATCH": [
{
"Privilege": [
"ConfigureManager"
]
},
{
"Privilege": [
"ConfigureSelf"
]
}
],
"POST": [
{
"Privilege": [
"ConfigureManager"
]
},
{
"Privilege": [
"ConfigureSelf"
]
}
],
"PUT": [
{
"Privilege": [
"ConfigureManager"
]
},
{
"Privilege": [
"ConfigureSelf"
]
}
],
"DELETE": [
{
"Privilege": [
"ConfigureManager"
]
},
{
"Privilege": [
"ConfigureSelf"
]
}
]
}
},
|
|
|
|
Post by mraineri on Jan 7, 2023 15:34:40 GMT
That's the intent of the "ConfigureSelf" privilege; it requires context for who is performing the operation on the resource in that they are only allowed to perform operations on their own resources, such as modifying their own password, their own event destinations, tasks for their own long-running operations, etc. Because "/redfish/v1/EventService/Subscriptions/1" was created by a different user, it doesn't map to the ReadOnly user in question since it's not a resource created by themself.
We can certainly add to the description for ConfigureSelf to highlight this further.
|
|
|
|
Post by Caffrey on Jan 10, 2023 0:26:58 GMT
Got it. Thanks for providing the valuable input. That will be great if can add some more description for this.
|
|
