|You should NOT be mixing the administration of RHQ and LDAP authorization models.|
Before LDAP Authorization was added to RHQ, the original RHQ security model, could be explained as a set of role permissions with associated
- authenticated user(s) designated by the RHQ username
- rhq group(s) defining resource visibility.
In that model the RHQ administrator was then tasked with creating/updating/managing all users/roles/group details and associations manually via UI or some level of scripting. When the option of having LDAP authorization was added to RHQ, it was built upon the existing authorization model and additionally could now pass authentication/authorization requests to an external LDAP server where legacy user and authorization group mappings may already have been defined. LDAP Authorization is achieved by:
- designating/creating an RHQ role solely for LDAP purposes
- assigning external LDAP groups to that role to be checked for runtime authorization verification
- assigning local RHQ groups, which specify RHQ resources of interest for LDAP users
- finally further LDAP specific user and role associations are to be left to be automatically handled by the LDAP Authorization mechanism.
|When the RHQ Administrator enables LDAP Authorization this indicates to the server to automatically handle all LDAP user<->role associations.|
|If the RHQ Administrator manually edits any generated LDAP user accounts then this is in conflict with the choice of enabling LDAP authorization.|
The RHQ administrator is responsible for manually creating/maintaining all RHQ user accounts, groups and roles and their associations via UI or scripting to effectively define the authentication and authorization model of the RHQ domain.
The LDAP administration model differs from the pure RHQ administration model specifically in the area of role->user assignment. With LDAP administration, the RHQ administrator still has to define/designate a regular RHQ role for LDAP purposes and must associate relevant external LDAP groups and local RHQ groups to that "LDAP Role". However, with correct LDAP user->group association being defined/maintained in the external LDAP server only then the RHQ Administrator no longer has all the relevant information to keep LDAP related user authorization information synchronized properly without first contacting the external LDAP server before each edit. User -> Role association is instead designed to be automatically updated by the LDAP Authorization Module of the RHQ server for relevant "LDAP Roles" each time an LDAP user logs into the RHQ system. Meaning that with LDAP user login that the designated "LDAP Role" is purged of old RHQ user account associations that are not longer authorized and updated with the RHQ account that is authorized.
To successfully use both LDAP and RHQ authorization mechanisms together you should do RHQ administration as you always have except where it concerns LDAP specific roles and users. After correct setup of the "LDAP Role" then all Role->User associations should automatically be synchronized without RHQ Administration intervention. For the RHQ Administrator to subsequently attempt to administer "LDAP" user accounts associations that the LDAP Authorization Module have automatically created is incorrect operation for the RHQ Administrator. In other words, if the RHQ Administrator has enabled LDAP authorization for LDAP user accounts then that same RHQ Administrator should not subsequently try to carry out administration on those same accounts. These are contradictory actions.
If you've decided that you would like all authentication and authorization to be handled by the rules of external LDAP server instead of the RHQ administration model, then it may be beneficial to remove all RHQ non-administration accounts. This minimizes the chances of confusing the RHQ and LDAP administration models.
I want to maintain my old RHQ administration mechanism and authorize some LDAP users to access RHQ resources.
This is the most likely case, but requires that you understand how both RHQ and LDAP authorization models work and to also avoid mixing both administration models(as described here) as it can lead to confusing authorization synchronization states. This means that the RHQ Administrator should operate as they always have except when dealing with role->user mappings for those RHQ roles that they have designated as "LDAP only". In that case, for LDAP specific RHQ roles, the maintenance of the "Assigned Users" list for the chosen role should not be edited at any time by the RHQ Administrator.