Mapping LDAP group to user roles

[Ratan Gupta]

Hi Richard,

On Tuesday 28 August 2018 09:12 PM, Thomaiyar, Richard Marian wrote:
> Ed / Brad / Tom / Ratan,
>
> 1. REDFISH can't manage LDAP user accounts. i.e. It will be beyond the 
> scope of REDFISH and won't list any LDAP user accounts (REDFISH can 
> implement LDAP privilege mapping configuration though)  --> Agree?
I agree on it.
>
> 2. Authentication must happen only using pam_authenticate (For 
> security purpose), and for authorization can use
>
>                 a). getgrnam_r to get the group & privilege
>
>                 b). use D-Bus API get property to get the group & 
> privilege role of the user
>
>                 c). Maintain 1:1 mapping with application through 
> signal handler to do user sync, which can be used directly (IPMI Code 
> under review does this logic).
>
>     Problem with option #a is it requires individual way to map group 
> & privilege, hence it was not recommended, and suggestion was to use 
> #b or #c. But with ldap user accounts #b & #c can't be used as there 
> is no local user object and hence thinking about introducing a generic 
> D-Bus API (under Manager) to return user Info say GetUserInfo --> 
> which accepts user name as argument, and returns back groups & 
> privilege of the user (irrespective of whether the user is local / 
> ldap), in this way applications doesn't need to use different flow to 
> query ldap / local user account information and can use one single flow?
If I am getting it correctly that you proposed that implementation logic 
of getting the roles of user in the user manager interface by 
introducing the D-bus Method getUserInfo().

The flow for the getUserInfo() would be as follows

1) Check that the user is local and if local then get the role from the 
local user D-bus object.

2) if user is not local user(ldap user) then get the role through the 
group -- Role mapping.
        a) getgrnam_r will get the ldap user group name as the libc 
would be using the libnss_ldap
        b) once we have the group name then we can get the priviledge 
role for that ldap user via the D-bus API.

I agree with this proposal to put this logic inside the app which 
implements the manager interface.

I am wondering what the getUserInfo API would return as part of user 
info, Would it be

1) Group Name
2) Privilege

Should we include the UserEnabled and the UserAccountLockedState as part 
of user info? would it be useful?
I am asking as if user password has been expired or account locked or 
new password required would have been handled through pam account
management which is part of authentication.

What is your view on this?


Are you planning to implement the above D-bus api(GetUserInfo) or can we 
help here?
>
> Note: This method must be implemented, so that it can internally use 
> the LDAP privilege mapper config to determine the privilege that has 
> to be applied to user, and can pass supported groups as ssh, redfish & 
> web (or can implement ldapGroupMapper too if needed).
>
> Any thoughts about this flow?
>
> Regards,
>
> Richard
>
>
> On 8/28/2018 8:25 PM, Tom Joseph wrote:
>>
>> On Thursday 23 August 2018 09:59 PM, Tanous, Ed wrote:
>>>>> It would be great if you could document your proposal as a patch 
>>>>> to the
>>>> existing user management document here:
>>>>> https://github.com/openbmc/docs/blob/master/user_management.md
>>>> https://gerrit.openbmc-project.xyz/#/c/openbmc/docs/+/12091/
>>> This is a great start, but a lot of detail seems to be missing. You 
>>> don't mention anything of the two user roles you mentioned in your 
>>> original email.  Has that changed?  I don't see any mention of the 
>>> dbus interface, has that changed?  I don't see that you've modified 
>>> any of the login flows in the document, but the LDAP section talks 
>>> about authorizing users via DBus, which certainly should include 
>>> changes to the flow diagrams.
>> Thanks Ed for the feedback. The D-Bus interface is updated to support 
>> all the privilege roles supported by OpenBMC. The document ha sonly 
>> the user creation flows. Richard mentioned he has the login flows 
>> updated in the downstream and he will upstream it. So I will update 
>> the authorization flow on top of that.
>>
>> Documentation:
>> https://gerrit.openbmc-project.xyz/#/c/openbmc/docs/+/12091/
>>
>> D-Bus Interface:
>> https://gerrit.openbmc-project.xyz/#/c/openbmc/phosphor-dbus-interfaces/+/12027/ 
>>
>>> It would be great if you could take another pass at this, and see if 
>>> you could add a little more detail to your proposal.
>>>
>>> Thanks,
>>>
>>> -Ed
>>
>