Bug 654766

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.

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.

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.

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,