Bug 604733

Summary:	Views of Roles and Users are out of date for rhqadmin
Product:	[Other] RHQ Project	Reporter:	Jeff Weiss <jweiss>
Component:	No Component	Assignee:	Simeon Pinder <spinder>
Status:	CLOSED NOTABUG	QA Contact:	Mike Foley <mfoley>
Severity:	medium	Docs Contact:
Priority:	low
Version:	3.0.0	CC:	dajohnso, jshaughn, spinder
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:	c7e6d2b, RHDS8.1
Last Closed:	2014-05-29 20:32:24 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	565628, 577267

Description Jeff Weiss 2010-06-16 15:50:22 UTC

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 17:02:24 UTC

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 17:46:15 UTC

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 18:56:50 UTC

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 19:04:45 UTC

"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 13:15:02 UTC

joseph - have another solution in mind here?