Authorization of LDAP users in bmcweb

Wed Oct 16 22:13:42 AEDT 2019

On 09-10-2019 23:25, Ed Tanous wrote:
> On 10/3/19 6:30 AM, RAJESWARAN THILLAIGOVINDAN wrote:
>> I am sorry that the current implementation is as per the LDAP authorization
>> flow described in the design document :
>> https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/12091.
>> Unfortunately, this design document has been abandoned.
> I'm struggling a little here.  Pointing at an abandoned review that I've
> already left comments on that were unanswered and abandoned is causing
> me to repeat a little.  If that is truly the flow that you want, please
> unabandon that patch, and update it with what you're suggesting below.
The owner of this patch has restored and assigned it to me. I have 
re-based and
uploaded the next patch set.
>> I am still seeing gap between our understanding. I am sorry that I
>> didn't explain it properly
>> to you before. Ifmy explanation is still not clear, I would like to have
>> a webex meeting with you.
> I'd rather we discuss on the mailing list, so others can have input, and
> we've documented our conversation for archival later.  I appreciate the
> offer though.
I understand and agree with you that mailing list help us to document the
discussions. We shall have a webex meeting and then document the 
discussions in the
mailing list for future reference.
>> [Local User Management - A D-Bus object for each local user]
>> The user management module provides a way to create, delete, or modify a
>> local user.
>> When a new local user is created,a corresponding D-Bus object is
>> created. At the time of creating
>> a local user, the role of the user has to be defined.Subsequently, when
>> a local user is modified to
>> change the role, this D-Bus object is updated. When the user is deleted,
>> thecorresponding D-Bus object
>> is deleted.
> Correct me if I'm wrong, but all of this is what's documented in the
> user_management.md file, no changes, correct?
>
correct. It is as per the user management design document. I referred it 
here to
highlight the difference.
>> [LDAP Group Management - A D-Bus object for each LDAP Group. Only
>> members of this group has the
>> required privileges]
>> The LDAP user management is done at organization level from the LDAP
>> server. The applications, like bmcweb,
>> can make use of LDAP user management for authentication. When LDAP is
>> enabled in bmcweb, then LDAP users can
>> login to bmcweb. After login,to perform any task, they need privilege
>> which comes with role. As roles are
>> application specific, role management for LDAPusers are done by the
>> application itself.
> I found the disconnect.  That statement is where we disconnect.  Role
> management needs to be owned in one place in the BMC, not in every
> single daemon.  bmcweb has a mapping from BMC role (admin/operator/user)
> to privileges, but at the end of the day, the users role is owned by the
> system (in this case phosphor-user-manager), not bmcweb.
I am sorry that I could not understand your concerns regarding the role 
management
for LDAP users. Do you see an issue with role management for LDAP users 
at LDAP
group level ?

>> As there may be thousands
>> of LDAP users, role management at LDAP user level will bedifficult. By
>> defining role at LDAP group level, we can
>> simplify the operation. Also, organizations can make use of
>> theirexisting LDAP group to define the role.
> All of this sounds great, and useful to organizations that have a
> deployed LDAP presence.
>
>> So,
>> bmcweb user management module provides a way to add, remove, or modify
>> LDAP groups.When a LDAP group is added,
>> a corresponding D-Bus object is created. Here, we assume that LDAP group
>> has been already created
>> in the LDAP server. At the time of adding a LDAP group, the role of that
>> group has to be defined.
>> Subsequently, when the groupis modified to change the role, this D-Bus
>> object gets updated.
>> When the LDAP group is removed, then the corresponding D-Busobject is
>> also deleted. The LDAP group created
>> in the LDAP server will continue to exist.
> I'm struggling a little to read this, as you've jumped directly into
> implementation, skipping completely over the flow of how a user would
> authorize.
>
> 1. User provides credentials to Redfish/IPMI/Rest/SSH
> 2. BMC queries LDAP server, and validates credentials are valid
> 3. BMC queries users LDAP group membership, and maps the roles to a.....
Correct. The above three steps are performed.
> Local user created on the fly?
No. We don't create local user for LDAP accounts.
> Local fixed user ("ldap_user" for example)?
No. Can you please explain what we can do by creating a local
fixed user?
> Local group?
> Dbus item?
Yes. Local groups corresponding to the LDAP groups are created and a 
role is assigned at
the group level.
>
> 4. User is instantiated with the given privilege (admin/operator/user)
> and retains their credentials until the session expires.
As per the initial design, the role was stored in the user session 
object with an
intention to retain the credentials until the session expires. I think, 
now, it has
been changed. I have investigated the BMC stack implemented by Super 
Micro and
AMI. In both cases, the role change is not applied to the existing 
session. I think it
is up to the application to decide.
> Have you walked through the above flow for SSH?  What user does bash get
> started when logging into the SSH console in your design?
LDAP users are not allowed to login via ssh as login is restricted to 
the 'priv-admin' group.
OS will see only the LDAP group.
> My point is that LDAP is definitely not the last remote
> authentication/authorization mechanism that's coming.  Setting the
> precedent that we need to add code to every single external facing
> daemon seems like a problem.
I understand. The existing implementation takes care of ipmi, Redfish, 
and Webserver. The
only missing thing is ssh.
>> The bmcweb user management module provides a common function to get the
>> information of the give user.
>> This user can bea local or LDAP user. This function, internally makes a
>> synchronous D-Bus call.
> This statement is incorrect.  bmcweb manages a cache of user/role
> mappings, and keeps it up to date by watching for changes, so that when
> a request comes in, no dbus call is required.
> Relevant code:
> https://github.com/openbmc/bmcweb/blob/ca0c93bb09587903a6dd43926799a967f10bafcd/include/sessions.hpp#L32
>
> Also, to my knowledge there are no synchronous DBus calls in bmcweb.
I am sorry that I was not clear here. I meant that 
phosphor-user-management application
provides a function called getUserInfo() :
https://github.com/openbmc/phosphor-user-manager/blob/7c6e7cffaf061aabfe5489ef52442e2f7cbd0fb7/user_mgr.cpp#L938
This function can be used to get the group name and the role for the 
given user. The user can be a local or LDAP user.  This function
makes a synchronous D-Bus call. I am not sure whether we can call that 
function in bmcweb. The caller of this function need not
worry whether the user is a local or LDAP user.
>> Hence, we could not make use of this function inthe bmcweb code.
>>
>> I hope the above justifies for the existence of two types of D-Bus
>> object based on local or LDAP user. The
>> authentication for both local and LDAP user is done by PAM module.
> It doesn't for me.  I've read the above statements several times, and
> I'm seeing no reason why the existing interface makes any difference.
>
> What it really sounds like is that you'd rather authorization be handled
> completely by the PAM module, and not DBus, which sounds completely
> reasonable to me, and probably simpler than the dbus stuff we have now,
> but if you're going to do it that way, I'd like to see the local user
> authorization moved that direction as well so we're not duplicating the
> authorization schemes in every single daemon.
I am sorry that the PAM module is used only for authentication of local 
and LDAP user.
For authorization, D-Bus is used.
>> I have also investigated BMC stack implemented by SuperMicro and AMI.In
>> both cases, for LDAP users,
>> the role is defined at LDAP group level. This is similar to what we are
>> doing in bmcewb now.
>> Also, we see a use-case for the customers to make use of their existing
>> LDAP group to define the role.
> At no point have I debated the user impact of the feature as a whole, I
> think it would be a great addition, I'd just like to see it built in a
> sustainable way.