Redfish: Design User authorization.

Ratan Gupta ratagupt at linux.vnet.ibm.com
Tue Feb 26 14:39:44 AEDT 2019


Hi Ed,

Please find my responses

Ratan


On 25/02/19 10:42 PM, Tanous, Ed wrote:
>> Hi Ed,
>>
>> This mail is regarding the authorization support on Redfish.
>>
> Thanks for pushing forward on this.  I think the best first step would be to review the patchset that's already in progress that's adding some infrastructure to do a lot of the things you're proposing.  If you're proposing an alternative approach than the existing review, and I misunderstood, apologies.
>
> https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/15813
>
> I suspect the questions we need to answer are:
> 1. How do we determine a user's role?
*we can get the user role/privilege by calling the D-bus method on 
phosphor-user-manager.*

*Gerrit commit is up for the same.*

*https://gerrit.openbmc-project.xyz/#/c/openbmc/phosphor-user-manager/+/18132/
*

> 2. Given that privilege is required to service every request, do we need to cache it, or can we go to dbus for every request?
Once we get the user role/privilege, we will add the user role in the 
session object itself

during creation of the session so no need to make D-bus call for every 
request.

> 3. How is the cache invalidated?
Session would be invalidated during logout or session timeout.
>
> I think the bulk of the implementation will be filling out the method here:
> https://github.com/openbmc/bmcweb/blob/a24526dcf9ad8de2f0bd9dbd5fc746a130351a22/redfish-core/include/privileges.hpp#L229
>
> And moving roles away from the static implementation, as you've already determined.
>
> Do you have any intention to implement PrivilegeRegistry?
No, the intention is to call the get User Info function and add the User 
role into the session, so for each HTTP request we know the user 
privilege and compare it with the entity privilege.
>
> Looking forward to seeing your work here.
>
> -Ed
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20190226/b6882e83/attachment.htm>


More information about the openbmc mailing list