Authorization of LDAP users in bmcweb

[Ed Tanous]

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.

> 
> 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.

> 
> [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?


> 
> [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.

> 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.....
Local user created on the fly?
Local fixed user ("ldap_user" for example)?
Local group?
Dbus item?

4. User is instantiated with the given privilege (admin/operator/user)
and retains their credentials until the session expires.

Have you walked through the above flow for SSH?  What user does bash get
started when logging into the SSH console in your design?


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.


> 
> 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.

> 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 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.