* Authorization of LDAP users in bmcweb:
@ 2019-09-27 18:59 RAJESWARAN THILLAIGOVINDAN
2019-09-30 21:29 ` Ed Tanous
0 siblings, 1 reply; 7+ messages in thread
From: RAJESWARAN THILLAIGOVINDAN @ 2019-09-27 18:59 UTC (permalink / raw
To: openbmc
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).
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
-> 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?
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.
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.
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.
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Authorization of LDAP users in bmcweb:
2019-09-27 18:59 Authorization of LDAP users in bmcweb: RAJESWARAN THILLAIGOVINDAN
@ 2019-09-30 21:29 ` Ed Tanous
[not found] ` <03510b52-dbdc-5365-570e-1b2c89a20f09@linux.vnet.ibm.com>
0 siblings, 1 reply; 7+ messages in thread
From: Ed Tanous @ 2019-09-30 21:29 UTC (permalink / raw
To: openbmc
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Re: Authorization of LDAP users in bmcweb
[not found] ` <03510b52-dbdc-5365-570e-1b2c89a20f09@linux.vnet.ibm.com>
@ 2019-10-03 13:30 ` RAJESWARAN THILLAIGOVINDAN
2019-10-09 17:55 ` Ed Tanous
0 siblings, 1 reply; 7+ messages in thread
From: RAJESWARAN THILLAIGOVINDAN @ 2019-10-03 13:30 UTC (permalink / raw
To: openbmc
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Authorization of LDAP users in bmcweb
2019-10-03 13:30 ` Re: Authorization of LDAP users in bmcweb RAJESWARAN THILLAIGOVINDAN
@ 2019-10-09 17:55 ` Ed Tanous
2019-10-16 11:13 ` RAJESWARAN THILLAIGOVINDAN
0 siblings, 1 reply; 7+ messages in thread
From: Ed Tanous @ 2019-10-09 17:55 UTC (permalink / raw
To: RAJESWARAN THILLAIGOVINDAN, openbmc@lists.ozlabs.org
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Authorization of LDAP users in bmcweb
2019-10-09 17:55 ` Ed Tanous
@ 2019-10-16 11:13 ` RAJESWARAN THILLAIGOVINDAN
2020-03-31 19:20 ` Alexander Amelkin
0 siblings, 1 reply; 7+ messages in thread
From: RAJESWARAN THILLAIGOVINDAN @ 2019-10-16 11:13 UTC (permalink / raw
To: Ed Tanous, openbmc@lists.ozlabs.org
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Authorization of LDAP users in bmcweb
2019-10-16 11:13 ` RAJESWARAN THILLAIGOVINDAN
@ 2020-03-31 19:20 ` Alexander Amelkin
2020-04-03 10:16 ` RAJESWARAN THILLAIGOVINDAN
0 siblings, 1 reply; 7+ messages in thread
From: Alexander Amelkin @ 2020-03-31 19:20 UTC (permalink / raw
To: openbmc
16.10.2019 14:13, RAJESWARAN THILLAIGOVINDAN пишет:
>
> On 09-10-2019 23:25, Ed Tanous wrote:
>> 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.
That was a wise decision. Although it didn't help me here, it did
clarify some things.
What I would like to know is: is LDAP authentication fully working in
master now?
We're trying to configure it with Intel-BMC/openbmc/intel for wolfpass
target and it looks like LDAP support is somehow incomplete.
I configure binding to the server and try to authenticate with an LDAP
user in WebUI, but I get a message in journalctl that requirement "user
in group redfish" is not met by the user, and an "Invalid username or
password" appears in the web browser. I don't see any means in WebUI to
include any remote users to 'redfish' group. Adding the user to an LDAP
group 'redfish' doesn't help (why would it?).
Trying to log in to shell also fails without any diagnostics, just
"authentication failure".
After reading the user_management.md I would expect the following scenario:
1. I enter credentials for LDAP binding
2. I list LDAP groups with their respective OpenBMC privileges
3. I log in with an LDAP user without any errors and get the privilege
according to the LDAP/OpenBMC group mapping set up in 2)
Currently it doesn't work like that for me.
So the question is: is it Intel-BMC/openbmc repo that is not up to date
or is it LDAP support in openbmc/openbmc also incomplete? Or am I doing
anything wrong?
Thank you for any help.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Authorization of LDAP users in bmcweb
2020-03-31 19:20 ` Alexander Amelkin
@ 2020-04-03 10:16 ` RAJESWARAN THILLAIGOVINDAN
0 siblings, 0 replies; 7+ messages in thread
From: RAJESWARAN THILLAIGOVINDAN @ 2020-04-03 10:16 UTC (permalink / raw
To: Alexander Amelkin, openbmc
LDAP authentication commit is :
https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/27952 and it has
been merged to the master.
Thanks,
T.Rajeswaran
On 01-04-2020 00:50, Alexander Amelkin wrote:
> 16.10.2019 14:13, RAJESWARAN THILLAIGOVINDAN пишет:
>>
>> On 09-10-2019 23:25, Ed Tanous wrote:
>>> 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.
>
> That was a wise decision. Although it didn't help me here, it did
> clarify some things.
>
> What I would like to know is: is LDAP authentication fully working in
> master now?
>
> We're trying to configure it with Intel-BMC/openbmc/intel for wolfpass
> target and it looks like LDAP support is somehow incomplete.
>
> I configure binding to the server and try to authenticate with an LDAP
> user in WebUI, but I get a message in journalctl that requirement
> "user in group redfish" is not met by the user, and an "Invalid
> username or password" appears in the web browser. I don't see any
> means in WebUI to include any remote users to 'redfish' group. Adding
> the user to an LDAP group 'redfish' doesn't help (why would it?).
>
> Trying to log in to shell also fails without any diagnostics, just
> "authentication failure".
>
> After reading the user_management.md I would expect the following
> scenario:
>
> 1. I enter credentials for LDAP binding
> 2. I list LDAP groups with their respective OpenBMC privileges
> 3. I log in with an LDAP user without any errors and get the privilege
> according to the LDAP/OpenBMC group mapping set up in 2)
>
> Currently it doesn't work like that for me.
>
> So the question is: is it Intel-BMC/openbmc repo that is not up to
> date or is it LDAP support in openbmc/openbmc also incomplete? Or am I
> doing anything wrong?
>
> Thank you for any help.
>
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2020-04-03 10:16 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-09-27 18:59 Authorization of LDAP users in bmcweb: RAJESWARAN THILLAIGOVINDAN
2019-09-30 21:29 ` Ed Tanous
[not found] ` <03510b52-dbdc-5365-570e-1b2c89a20f09@linux.vnet.ibm.com>
2019-10-03 13:30 ` Re: Authorization of LDAP users in bmcweb RAJESWARAN THILLAIGOVINDAN
2019-10-09 17:55 ` Ed Tanous
2019-10-16 11:13 ` RAJESWARAN THILLAIGOVINDAN
2020-03-31 19:20 ` Alexander Amelkin
2020-04-03 10:16 ` RAJESWARAN THILLAIGOVINDAN
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.