This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 604733 - Views of Roles and Users are out of date for rhqadmin
Views of Roles and Users are out of date for rhqadmin
Status: CLOSED NOTABUG
Product: RHQ Project
Classification: Other
Component: No Component (Show other bugs)
3.0.0
All Linux
low Severity medium (vote)
: ---
: ---
Assigned To: Simeon Pinder
Mike Foley
:
Depends On:
Blocks: rhq_triage jon24-ldap
  Show dependency treegraph
 
Reported: 2010-06-16 11:50 EDT by Jeff Weiss
Modified: 2014-11-09 17:50 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
c7e6d2b, RHDS8.1
Last Closed: 2014-05-29 16:32:24 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Jeff Weiss 2010-06-16 11:50:22 EDT
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.
Comment 1 Simeon Pinder 2010-06-16 13:02:24 EDT
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.
Comment 2 Jeff Weiss 2010-06-16 13:46:15 EDT
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?
Comment 3 Simeon Pinder 2010-06-16 14:56:50 EDT
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.
Comment 4 Jeff Weiss 2010-06-16 15:04:45 EDT
"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.
Comment 5 Corey Welton 2010-09-24 09:15:02 EDT
joseph - have another solution in mind here?

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