Bug 654766 - Should have the ability to override or add Roles to a user with an LDAP Authorization Group Role
Summary: Should have the ability to override or add Roles to a user with an LDAP Autho...
Alias: None
Product: RHQ Project
Classification: Other
Component: Core Server
Version: 4.1
Hardware: Unspecified
OS: Unspecified
medium vote
Target Milestone: ---
: ---
Assignee: RHQ Project Maintainer
QA Contact: Corey Welton
Keywords: FutureFeature
Depends On:
Blocks: jon3
TreeView+ depends on / blocked
Reported: 2010-11-18 18:54 UTC by dsteigne
Modified: 2018-11-14 14:16 UTC (History)
3 users (show)

Clone Of:
Last Closed: 2011-05-13 17:42:46 UTC

Attachments (Terms of Use)

Description dsteigne 2010-11-18 18:54:04 UTC
Description of problem:
Currently, if LDAP Authentication and Authorization is enabled and you have a user who is automatically assigned a role via his LDAP Group rhqadmin cannot assign this user a new role.  It gets removed and the user is put back in the LDAP Group role assignment every time he logs in.

If this is as planned, then please make this a Request for Enhancement.

Version-Release number of selected component (if applicable):

How reproducible:
Every time

Steps to Reproduce:
1.Setup LDAP Authorization/Authentication
2.Setup a Role(MinRole) with minimal permissions and assign an LDAP Group
3.Login as an LDAP User (User1) from the above LDAP Group
4.User1 is automatically given the MinRole Role
5.You want this user to have full JON permissions, but you don't want anyone else in that same LDAP Group to have them.
6.login as rhqadmin.  Navigate to Administration>Security>Users, User1 and add a Full Permissions Role.
7. Login as User1. Logout
8. Login as rhqadmin and look at User1, the Full permissions role is removed.
9. No matter what the users role is it's overwritten with the default LDAP group role

Actual results:

Expected results:

Additional info:

Comment 1 Larry O'Leary 2011-03-24 20:34:02 UTC
This seems like a valid RFE but from a security perspective, may not be a very good idea. The point of using LDAP to authenticate a user and map a user's LDAP groups to RHQ roles allows for user administration outside of RHQ. If we allow LDAP users to be mapped to roles outside of LDAP, it introduces a user administration complexity and potential security risk. Although we could probably implement this feature with all the UI and documentation WARNINGS, I would suggest that the user instead use LDAP groups to perform the mappings. In other words, have LDAP groups created which can be mapped to defined RHQ roles and then have the LDAP user added to such LDAP groups. This would allow a single point of user administration without the worry of "Where else do I need to update this user's groups and roles?"

So, without this feature you would do one of the following:

1) Create a separate group in LDAP to assign to the role for authentication of LDAP users
2) Create a separate local login and map these local users to roles for any RHQ users who need access in this manner

As a measure to prevent such a configuration, we should prevent LDAP users from being assigned to local roles and inform the user that instead, they should map the user's LDAP group(s) to local roles.

Comment 2 Charles Crouch 2011-05-10 05:25:28 UTC
I'm setting this to a high priority so that it gets triaged. I'm in Larry's camp in that I don't think this feature request would help people use ldap authz effectively and securely with JON. But I want Simeon to review this issue and the attached cases and also comment. 

If there are things we can do to make our current process more robust then we could certainly look at those.

Comment 3 Simeon Pinder 2011-05-12 13:31:51 UTC
Initially the RHQ Role -> User assignment worked exactly as they are requesting which allowed the RHQ system administrator to come in later and modify a given LDAP user to have additional RHQ role assignments (unrelated to LDAP groups in any way).  This flexibility came at the expense of the i)administration and ii)security complexities described while introducing synchronization concerns as well.  

The current functionality is cleaner and more correct as Role->User authorization is all handled purely by i)RHQ Administrator OR ii)by the external LDAP Server administrator.  This makes sense to concentrate authorization responsibility in one domain to remove synchronization issues and limit security concerns when updates are required.

When the RHQ administrator enables LDAP authorization this indicates that the RHQ admin is giving all responsibility for LDAP users and groups to the LDAP server administrator.  The next time an LDAP user logs into RHQ the server synchronizes the RHQ authorization settings with the ones defined in the LDAP domain.  For the RHQ administrator to subsequently log in and update user->role mapping for any given LDAP user contradicts the earlier intent of LDAP domain authorization.

The simplest fix in cases like these would be to: 
i)Use/create a different LDAP group on the external LDAP server. Ex. RHQ Admins
ii)Assign those ldap users requiring additional access to this 'RHQ Admins' group in addition to the default authorization group assignments on the LDAP server.
iii)Have the RHQ Administrator create a new role 'LDAP RHQAdmin rights' and assign the new LDAP group 'RHQ Admins' and add any appropriate permissions and RHQ group assignments desired.

When changes need to occur to 'RHQ Admins' due to LDAP user authorization updates these will be automatically synchronized by the RHQ server.  The RHQ permissions and visibility are additive so that an LDAP user 'tester' with two LDAP group assignments will now correctly get the combined visibility and permissions of the combine RHQ role mappings.   

Unless there is some additional use case that I did not get I think we should leave this as working as expected.

Comment 4 Charles Crouch 2011-05-13 17:42:46 UTC
As per Simeon's comments this is not a beneficial feature as far as complexity and security goes. The use cases can be completed using ldap groups and the existing functionality,

Note You need to log in before you can comment on or make changes to this bug.