Description of problem: When rhqadmin adds an LDAP group to a role, and then navigates to the Admin/Security/Users page, and clicks on one of the users in the LDAP group, the user's page still shows he's not a part of the role. Only when that user logs in will rhqadmin's page show the correct data. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Create a group (mygroup) and add a user to it (myuser) in LDAP 2. Log in as myuser in RHQ and complete the registration 3. Log out, log in as rhqadmin 4. go to Admin/Security/Roles. Create a new role (myrole). 5. Add the ldap group mygroup to the role. 6. go to Admin/Security/Users/myuser Actual results: Myuser is not a member of the role myrole Expected results: Myuser should be displayed as a member of the role myrole. Additional info: If you then log out, log in as myuser, and go to the Admin/Security/Users/myuser page, you'll see the correct data. Then if you log out, log in as rhqadmin, and go back to the same page it will still be correct. The discrepancy is NOT resolved by simply logging out/in as rhqadmin. The user myuser has to log in.
This is currently a limitation in how the ldap-group authorization mapping works. It has been discussed that the correct solution to these type of auth/z state synchronization problems, between rhq and external ldap server, is to have scheduled jobs constantly running to periodically synchronize the states. While this specific problem is not about synchronization between the two servers, it is about synchronization of authorization permissions with newly created roles, the problem is related and should be handled when the server synchronization problem is addressed. Currently synchronization only occurs when an ldap user logs in. It was decided that full synchronization with quartz jobs was out of scope for the 2.4 release. See Charles Crouch and Joe Marques for more details. A lingering concern about the server state synchronization problem is what to do about ldap users that never log into rhq. Currently we only create and synchronize accounts when a user logs in similar to lazy-initialization/synchronization. With full synchronization, ldap group authorization membership changes could potentially translate into rhq group membership updates even when no ldap users are logged into the rhq system. I mention it here so that is also considered.
I don't think quartz jobs solves this problem. The data would still appear out of date to rhqadmin for an unacceptably long time. It needs to sync on-demand. If it is quick enough to be done at login time, I would think it could be done other times as well. What if we synchronize also when the Admin Roles/Users page is requested (or user details page which displays his roles). I think that would solve the problem, wouldn't it?
That's not a bad suggestion since the administration pages should only be visited by a user with clear intentions of administrating RHQ. This is still somewhat of an edge case as that same administrator should also be aware that ldap authorization relationships are managed at runtime and only after a given ldap user has successfully logged into rhq should they expect role population to be correctly synched. I think this is a decent enhancement request. Given the proximity to 2.4 I think we should have Charles check this out if you think it's important enough for inclusion in JON 2.4. It will require a small amount of change to initiate full role refresh for populated ldap accounts. I haven't yet investigated code effort for such a think though.
"that same administrator should also be aware that ldap authorization relationships are managed at runtime and only after a given ldap user has successfully logged into rhq" Only if a) we documented this, and b) the admin read and remembered that tidbit. Even then, he still can't be sure if his changes took or not. He can't actually log in as the ldap user himself.
joseph - have another solution in mind here?