Authorization of LDAP users in bmcweb

Thu Oct 3 23:30:17 AEST 2019

Ed,

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

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

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

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

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.

Yours sincerely,
T.Rajeswaran
>
> 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.