From: "Thomaiyar, Richard Marian" <richard.marian.thomaiyar@linux.intel.com>
To: Tom Joseph <tomjose@linux.vnet.ibm.com>,
"Tanous, Ed" <ed.tanous@intel.com>,
OpenBMC Maillist <openbmc@lists.ozlabs.org>
Subject: Re: Mapping LDAP group to user roles
Date: Tue, 28 Aug 2018 21:12:41 +0530 [thread overview]
Message-ID: <7b6b2198-4725-e487-12ad-bf18cb4297b5@linux.intel.com> (raw)
In-Reply-To: <1ab96997-92ac-87fb-7d45-795d5747e4aa@linux.vnet.ibm.com>
Ed / Brad / Tom / Ratan,
1. REDFISH can't manage LDAP user accounts. i.e. It will be beyond the
scope of REDFISH and won't list any LDAP user accounts (REDFISH can
implement LDAP privilege mapping configuration though) --> Agree?
2. Authentication must happen only using pam_authenticate (For security
purpose), and for authorization can use
a). getgrnam_r to get the group & privilege
b). use D-Bus API get property to get the group &
privilege role of the user
c). Maintain 1:1 mapping with application through
signal handler to do user sync, which can be used directly (IPMI Code
under review does this logic).
Problem with option #a is it requires individual way to map group &
privilege, hence it was not recommended, and suggestion was to use #b or
#c. But with ldap user accounts #b & #c can't be used as there is no
local user object and hence thinking about introducing a generic D-Bus
API (under Manager) to return user Info say GetUserInfo --> which
accepts user name as argument, and returns back groups & privilege of
the user (irrespective of whether the user is local / ldap), in this way
applications doesn't need to use different flow to query ldap / local
user account information and can use one single flow?
Note: This method must be implemented, so that it can internally use the
LDAP privilege mapper config to determine the privilege that has to be
applied to user, and can pass supported groups as ssh, redfish & web (or
can implement ldapGroupMapper too if needed).
Any thoughts about this flow?
Regards,
Richard
On 8/28/2018 8:25 PM, Tom Joseph wrote:
>
> On Thursday 23 August 2018 09:59 PM, Tanous, Ed wrote:
>>>> It would be great if you could document your proposal as a patch to
>>>> the
>>> existing user management document here:
>>>> https://github.com/openbmc/docs/blob/master/user_management.md
>>> https://gerrit.openbmc-project.xyz/#/c/openbmc/docs/+/12091/
>> This is a great start, but a lot of detail seems to be missing. You
>> don't mention anything of the two user roles you mentioned in your
>> original email. Has that changed? I don't see any mention of the
>> dbus interface, has that changed? I don't see that you've modified
>> any of the login flows in the document, but the LDAP section talks
>> about authorizing users via DBus, which certainly should include
>> changes to the flow diagrams.
> Thanks Ed for the feedback. The D-Bus interface is updated to support
> all the privilege roles supported by OpenBMC. The document ha sonly
> the user creation flows. Richard mentioned he has the login flows
> updated in the downstream and he will upstream it. So I will update
> the authorization flow on top of that.
>
> Documentation:
> https://gerrit.openbmc-project.xyz/#/c/openbmc/docs/+/12091/
>
> D-Bus Interface:
> https://gerrit.openbmc-project.xyz/#/c/openbmc/phosphor-dbus-interfaces/+/12027/
>
>> It would be great if you could take another pass at this, and see if
>> you could add a little more detail to your proposal.
>>
>> Thanks,
>>
>> -Ed
>
next prev parent reply other threads:[~2018-08-28 15:42 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-21 12:13 Mapping LDAP group to user roles Tom Joseph
2018-08-21 15:21 ` Tanous, Ed
2018-08-23 13:20 ` Tom Joseph
2018-08-23 16:29 ` Tanous, Ed
2018-08-28 14:55 ` Tom Joseph
2018-08-28 15:42 ` Thomaiyar, Richard Marian [this message]
2018-08-29 11:51 ` Ratan Gupta
2018-08-29 17:13 ` Thomaiyar, Richard Marian
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7b6b2198-4725-e487-12ad-bf18cb4297b5@linux.intel.com \
--to=richard.marian.thomaiyar@linux.intel.com \
--cc=ed.tanous@intel.com \
--cc=openbmc@lists.ozlabs.org \
--cc=tomjose@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.