Authorization of LDAP users in bmcweb:

[Ed Tanous]

It should be noted, when the LDAP user management document changes were
pushed, this topic was one of the first question I asked, given that
it's a difficult problem.

https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/12091

"How do you map LDAP users to BMC users?  Does LDAP create the users, or
simply log them in?"

The answer I was given was:
"The privilege roles map to the existing user privilege roles mentioned
in this document."

Maybe it's my misunderstanding that the above statement meant the intent
was to map it to the same interfaces that existed, but that was how I
read it.

That review was later abandoned, and so far as I'm aware no changes have
superseded that review for the LDAP case.

-Ed


On 9/27/19 11:59 AM, RAJESWARAN THILLAIGOVINDAN wrote:
> We would like to discuss the following points raised in the gerrit
> commit 23538 (https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/23538).
> 
> 1. Why is LDAP any different than non-ldap in phosphor-user-manager?  Do
> LDAP users not get registered with the system?  That seems odd.
> 
> LDAP users are not managed by OpenBMC. Unlike local users, privileges
> are assigned directly to the LDAP user.
> For LDAP user, it is a two step process:
> - Get the Group Name
> - Look for the privilege for the group
> 
> For local users
> - Each user is directly part of group(priv-admin/priv-user/priv-callback).

Both of these are internal to the system, and don't really have anything
to do with the dbus interfaces.  So far as bmcweb is concerned (today)
these could be stored as files, or could be bypassing the local users
altogether, or could be running through something that enforced 2
factor.  So long as the interfaces are maintained, the rest of the
system doesn't care.

> 
> Why D-Bus objects are not created for LDAP users?
> 
>    There is no use-case for it. Few reasons are listed below:
>    -> LDAP is used for authentication and not for user management
>    -> If we show LDAP users, OpenBMC admin cannot do anything for those
> users

The use case is exactly what I'm pointing out:  Applications in the
system that need to understand a users role, and possibly expire
sessions if any of the settings change.
That's fine that they logged in from outside the system, but having a
session for a user that we have no way to control or verify sounds
dangerous.  Also, certain daemons maintain user sessions through a
reboot;  How would you recommend we verify that the ldap credentials are
still valid through a reboot?  Should we just ignore that in this case?

>    -> LDAP notifications are not there. So, we cannot update the LDAP
> user object.
> https://www.openldap.org/lists/openldap-technical/201008/msg00175.html
> https://lists.arthurdejong.org/nss-pam-ldapd-users/2019/msg00035.html
>       We can look for sync option by using some other opensource tool;
> but do we require that much complexity?

I'm not asking for an LDAP notification, nor was I ever.  I'm asking why
we can't come up with a standard interface for users, so the client code
doesn't have to have specific code to support every single login type we
might want.
I'm really not following why this is more complex.  We're building
effectively 2 methods into the same interface (LDAP, and local).
Nothing in the system would have to change except for the
LDAP/user-management daemon itself.  That seems simpler to me?  Maybe
I've missed something?

> 
> 2. All of the matches you've listed seem to already be present in
> bmcweb.  I'm confused what exactly you're adding.
> 
> We have added matches only for local users, who have D-Bus objects>
> For LDAP users, D-Bus objects are not created. Hence, they will not be
> found in the live user-role map.

I see this as an issue, and breaking the interface guarantees of the
User dbus interface.

> 
> For LDAP users, we need to make the call for getpw, getgr, getgr_name
> using (ldap_nss module)
> which internally makes a call to the LDAP and get the group name.
> 
> OpenBMC manages LDAP role group and privileges and a D-Bus object is
> created for each such role group. Like live user-role map for local
> users, we need a live role group - privilege map for LDAP users.

I'll mention again.... The thing I'm not liking here is that you've
taken an interface that works perfectly fine, and should be able to
handle what you're trying to do, and essentially created an alternative
one, now it's been alluded to (but hasn't happened yet) that someone
will attempt to push code to the individual daemons that specializes
LDAP (IMO unnecessarily).
> 
> 3. The above makes me think that we're logging in users that don't
> necessarily have a username on the system, which seems really contrary
> to the design, where PAM is used to interchange user privileges.  What
> you suggest above seems to be breaking that?
> 
> I am sorry that I could not understand what you mean by "PAM is used to
> interchange user privileges". PAM is used only for authentication.
> 
> For getting the privileges, we shall call getpw_nam and getgr_id. For
> local users, these APIs are not used as D-Bus object has this info.

See above, you're breaking the existing interface.  Is there a reason
that phosphor-user-manager can't call getpw_nam and getgr_id when those
dbus requests for roles come in?  Isn't that what it does already?

If we wanted to drop the dbus role interface  entirely in leiu of PAM I
could probably get behind it, but as-is, we're just unnecessarily
bifurcating for (I suspect) the sake of making things easier.

> 
> For LDAP users, we call getpw, getgr, getgr_name using (ldap_nss module)
> which internally calls LDAP and get the results.
> 
> The user management application provides the method GetUserInfo() to get
> the local and LDAP user privileges. This method abstracts how the
> privileges are stored and retrieved. This is as per the user-management
> design.
> 
> We have discussed this in the community call around a year back.
> 

I don't recall discussing that we would be pushing LDAP specific login
routines into each individual node that needs to be able to log in.

If I were to summarize this;  It seems like we're duplicating the roles
system here, both in PAM and in DBus, and now we have conflicts because
LDAP seems to only want to use PAM, and not expose the DBus roles at
all, and bmcweb (today) is based on dbus to expire sessions properly and
track user role changes through the system.  Saying we're not going to
publish the DBus interface in the LDAP case means there's now 2
authorization flows that we need to maintain and track.

If we really want to only use PAM for authorization, we should drop the
dbus interfaces entirely.