* Mapping LDAP group to user roles
@ 2018-08-21 12:13 Tom Joseph
2018-08-21 15:21 ` Tanous, Ed
0 siblings, 1 reply; 8+ messages in thread
From: Tom Joseph @ 2018-08-21 12:13 UTC (permalink / raw)
To: OpenBMC Maillist
Hello,
We have a requirement to assign role to the LDAP users, so certain
operations can be restricted for users without admin permissions.
The proposal is to assign role for the LDAP groups. The LDAP user will
inherit the role assigned to the LDAP group.
To start off the plan is to have two roles, the admin role and the user
role. The role will be consumed by the
phosphor-rest-server and screen the REST api based on HTTP verbs.The
user role will permit only REST API's with GET verb.
The admin role will permit all the HTTP verbs.
With this in background, i am proposing a D-Bus API to implement the
LDAP group to role mapping. The CreateGroupRole method
can be used to create a mapping between the LDAP group and the role.
This will create the object with the group name like
/xyx/openbmc_project/ldap/<group_name> which will implement the
GroupEntry interface that has the role attribute.
Let me know the thoughts about this proposal.
https://gerrit.openbmc-project.xyz/#/c/openbmc/phosphor-dbus-interfaces/+/12027/
Regards,
Tom
^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: Mapping LDAP group to user roles
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
0 siblings, 1 reply; 8+ messages in thread
From: Tanous, Ed @ 2018-08-21 15:21 UTC (permalink / raw)
To: Tom Joseph, OpenBMC Maillist
>
> We have a requirement to assign role to the LDAP users, so certain
> operations can be restricted for users without admin permissions.
>
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
It would make it much easier to see what changes you're proposing. Given what already exists, your proposal is a little confusing, as there's already a mechanism to get group membership, and defined the user roles. Are you proposing changing the existing interfaces to the new group collection type interface? You're proposing two user roles, but we already have documented 4 user roles. Is your proposal to delete two of them?
I think all of these questions would be answered if you could update the document above with your proposed changes.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Mapping LDAP group to user roles
2018-08-21 15:21 ` Tanous, Ed
@ 2018-08-23 13:20 ` Tom Joseph
2018-08-23 16:29 ` Tanous, Ed
0 siblings, 1 reply; 8+ messages in thread
From: Tom Joseph @ 2018-08-23 13:20 UTC (permalink / raw)
To: Tanous, Ed, OpenBMC Maillist
On Tuesday 21 August 2018 08:51 PM, Tanous, Ed wrote:
>> We have a requirement to assign role to the LDAP users, so certain
>> operations can be restricted for users without admin permissions.
>>
> 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/
>
> It would make it much easier to see what changes you're proposing. Given what already exists, your proposal is a little confusing, as there's already a mechanism to get group membership, and defined the user roles. Are you proposing changing the existing interfaces to the new group collection type interface? You're proposing two user roles, but we already have documented 4 user roles. Is your proposal to delete two of them?
>
> I think all of these questions would be answered if you could update the document above with your proposed changes.
In phosphor-rest-server the requirement is to add two privilege roles,
the admin and the user role. So the interface has two roles proposed.
This can be extended in the future to include other privilege roles.
^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: Mapping LDAP group to user roles
2018-08-23 13:20 ` Tom Joseph
@ 2018-08-23 16:29 ` Tanous, Ed
2018-08-28 14:55 ` Tom Joseph
0 siblings, 1 reply; 8+ messages in thread
From: Tanous, Ed @ 2018-08-23 16:29 UTC (permalink / raw)
To: Tom Joseph, OpenBMC Maillist
> >>
> > 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.
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Mapping LDAP group to user roles
2018-08-23 16:29 ` Tanous, Ed
@ 2018-08-28 14:55 ` Tom Joseph
2018-08-28 15:42 ` Thomaiyar, Richard Marian
0 siblings, 1 reply; 8+ messages in thread
From: Tom Joseph @ 2018-08-28 14:55 UTC (permalink / raw)
To: Tanous, Ed, OpenBMC Maillist
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Mapping LDAP group to user roles
2018-08-28 14:55 ` Tom Joseph
@ 2018-08-28 15:42 ` Thomaiyar, Richard Marian
2018-08-29 11:51 ` Ratan Gupta
0 siblings, 1 reply; 8+ messages in thread
From: Thomaiyar, Richard Marian @ 2018-08-28 15:42 UTC (permalink / raw)
To: Tom Joseph, Tanous, Ed, OpenBMC Maillist
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
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Mapping LDAP group to user roles
2018-08-28 15:42 ` Thomaiyar, Richard Marian
@ 2018-08-29 11:51 ` Ratan Gupta
2018-08-29 17:13 ` Thomaiyar, Richard Marian
0 siblings, 1 reply; 8+ messages in thread
From: Ratan Gupta @ 2018-08-29 11:51 UTC (permalink / raw)
To: Thomaiyar, Richard Marian, Tom Joseph, Tanous, Ed, OpenBMC Maillist
Hi Richard,
On Tuesday 28 August 2018 09:12 PM, Thomaiyar, Richard Marian wrote:
> 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?
I agree on it.
>
> 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?
If I am getting it correctly that you proposed that implementation logic
of getting the roles of user in the user manager interface by
introducing the D-bus Method getUserInfo().
The flow for the getUserInfo() would be as follows
1) Check that the user is local and if local then get the role from the
local user D-bus object.
2) if user is not local user(ldap user) then get the role through the
group -- Role mapping.
a) getgrnam_r will get the ldap user group name as the libc
would be using the libnss_ldap
b) once we have the group name then we can get the priviledge
role for that ldap user via the D-bus API.
I agree with this proposal to put this logic inside the app which
implements the manager interface.
I am wondering what the getUserInfo API would return as part of user
info, Would it be
1) Group Name
2) Privilege
Should we include the UserEnabled and the UserAccountLockedState as part
of user info? would it be useful?
I am asking as if user password has been expired or account locked or
new password required would have been handled through pam account
management which is part of authentication.
What is your view on this?
Are you planning to implement the above D-bus api(GetUserInfo) or can we
help here?
>
> 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
>>
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Mapping LDAP group to user roles
2018-08-29 11:51 ` Ratan Gupta
@ 2018-08-29 17:13 ` Thomaiyar, Richard Marian
0 siblings, 0 replies; 8+ messages in thread
From: Thomaiyar, Richard Marian @ 2018-08-29 17:13 UTC (permalink / raw)
To: Ratan Gupta, Tom Joseph, Tanous, Ed, OpenBMC Maillist
On 8/29/2018 5:21 PM, Ratan Gupta wrote:
> Hi Richard,
>
> On Tuesday 28 August 2018 09:12 PM, Thomaiyar, Richard Marian wrote:
>> 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?
> I agree on it.
Had a discussion with Ed, and Ed agrees about the problem of listing all
the LDAP user accounts. At the same time, he is thinking about listing
out the Logged in LDAP user accounts?
Another interesting question which he raised was, how we are going to
track this user in the security login logs, so that we will be able to
trace back on which user performed what action?
(I have not yet investigated how to do this, but thought to share, so
that you can also think about this).
>>
>> 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?
> If I am getting it correctly that you proposed that implementation
> logic of getting the roles of user in the user manager interface by
> introducing the D-bus Method getUserInfo().
>
> The flow for the getUserInfo() would be as follows
>
> 1) Check that the user is local and if local then get the role from
> the local user D-bus object.
>
> 2) if user is not local user(ldap user) then get the role through the
> group -- Role mapping.
> a) getgrnam_r will get the ldap user group name as the libc
> would be using the libnss_ldap
> b) once we have the group name then we can get the priviledge
> role for that ldap user via the D-bus API.
>
> I agree with this proposal to put this logic inside the app which
> implements the manager interface.
>
> I am wondering what the getUserInfo API would return as part of user
> info, Would it be
>
> 1) Group Name
> 2) Privilege
>
> Should we include the UserEnabled and the UserAccountLockedState as
> part of user info? would it be useful?
> I am asking as if user password has been expired or account locked or
> new password required would have been handled through pam account
> management which is part of authentication.
>
I am not sure, whether we will be able to get the userEnabled and
UserAccountLockedState from LDAP server, but if we are able to then i
think we can list down those too. (along with one more param, as ldap /
local user).
Also, Do you thought about how to determine whether the user is ldap /
local ? 1. Are we going to check the <domain>/<username> as ldap ? 2.
Any account which succeeds in pam_authenticate, and not in local user
database is ldap user?
> What is your view on this?
>
>
> Are you planning to implement the above D-bus api(GetUserInfo) or can
> we help here?
I am fine with either way, but my first priority is to merge existing
code (clear out the backlog).
Regards,
Richard
>>
>> 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
>>>
>>
>
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2018-08-29 17:13 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
2018-08-29 11:51 ` Ratan Gupta
2018-08-29 17:13 ` Thomaiyar, Richard Marian
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.