This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 535119 - (RHQ-1848) test authorization on all new pages
test authorization on all new pages
Status: CLOSED NEXTRELEASE
Product: RHQ Project
Classification: Other
Component: Tests (Show other bugs)
unspecified
All All
urgent Severity medium (vote)
: ---
: ---
Assigned To: Simeon Pinder
http://jira.rhq-project.org/browse/RH...
: Task
Depends On: RHQ-1859 RHQ-1860 RHQ-1861 RHQ-1862 RHQ-1863 RHQ-1864 RHQ-1865 RHQ-1866 RHQ-1867 RHQ-1868 RHQ-1869
Blocks:
  Show dependency treegraph
 
Reported: 2009-03-25 12:22 EDT by John Mazzitelli
Modified: 2009-11-10 16:22 EST (History)
0 users

See Also:
Fixed In Version: 1.2
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
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 John Mazzitelli 2009-03-25 12:22:00 EDT
We need one person to go through the UI and test authorization features, especially for the new/refactored pages.

Here's what I do to test:

1) create a user "none" that has no roles/permissions
2) create a user "good" that has 1 role with 1 permission (the one you are testing)
3) Install three browsers :) - so you can keep 3 users simultaneously logged in and not forced to switch by logging out and logging in as different users
4) Browser 1 - log in as "none"
5) Browser 2 - log in as "good"
6) Browser 3 - log in as "rhqadmin"

Now just go through the pages you want to test and make sure each user can see what they are allowed to see
Comment 1 John Mazzitelli 2009-03-27 08:28:05 EDT
Here's what the security permissions allow you to do. I'm going to keep editing this comment and adding things as I test and found out what really is under authz.

MANAGE_SECURITY:

Adding/Modifying users
Adding/Modifying roles
Modifying other users' passwords (other than your own)
Modifying other users' details and preferences (other than your own)

MANAGE_SETTINGS:

Viewing/Modifying Server Configuration Settings
Manage agent plugins that the server has deployed
Update the license
 
MANAGE_INVENTORY

Adding/Changing Metric and Alert  Templates
View/Manage Servers
View/Manage Agents
View/Manage Affinity Groups
View/Manage Partition Events

VIEW_RESOURCE

MODIFY_RESOURCE

DELETE_RESOURCE

CREATE_CHILD_RESOURCES

MANAGE_ALERTS

MANAGE_MEASUREMENTS

MANAGE_CONTENT

CONTROL

CONFIGURE
Comment 2 John Mazzitelli 2009-03-27 08:46:52 EDT
The legacy jsp Authorization tag isn't doing what it should be for non-resource based pages. Its authorizing things it should not.
Comment 3 John Mazzitelli 2009-03-27 09:14:01 EDT
svn rev3545 fixes the authorization tag so global permissions are checked properly. to test, create a user that has MANAGE_INVENTORY permission only, and go to Administration page - you should no longer be able to see any of the setting links and you also should not be able to go to any of the server setting pages (such as the Server Configuration page).
Comment 4 Simeon Pinder 2009-04-03 09:40:18 EDT
SUMMARY:
A crucial part of any authz testing that has not been mentioned up to this point is the REQUIRED definition of a resource group that must subsequently be attached to the defined roles for any meaningful authorization to occur. Solution for authz testing is to create 'Everything' group and attach it to all users before proceeding with authz testing.

DETAILED:
In other words, the JON/JOPR code has correctly separated the notions of a) Groups of resources from b) the Roles defining the permissions to access any said group.  This separation is correct for those system/resource administrators but has the following noticeable effects:

i)  there is an massive amount of fine grained control over levels of authorization access(i.e. modification ability as defined by roles) and visibility access(i.e. as defined by groups).  
ii) groups can actually be used and reused by more than one role.  Users who are not System/Resource Administrators may never appreciate this functionality fully.  
iii) the separation of concerns for Groups and Roles is initially unintuitive to anyone who is not familiar with this approach to fine grained control.  Most lay users inextricably attach the Role(permissions) and Group(resource aggregation) into one title i.e. Sys Admin Role, Database Administrator, Financial Analyst, Systems Developer, Middleware Manager, etc.
iv) this results in the separate steps to create groups of assets and then subsequently create roles attached to those groups before typical authorization can occur.

SOLUTION: For this authorization testing, create a base group that includes all of the discovered resources i.e. Everything for this testing as we must first see the resources(requires membership in this group) before our subsequent fine grained control through role restrictions can occur.   
   
Comment 5 Simeon Pinder 2009-04-08 14:08:02 EDT
When creating Groups, Roles and the Users controlled by them, the following order seems to work with the least pain and redirection.

1) Create the 'Everything' Group. 
   a) Go to Resources -> Platforms and click on 'New Group' link. Name the group, go 'Mixed Resources' and go recursive.

Rinse and repeat as many times as necessary ...
2) Create [desired role] with appropriate permissions and at the end add the 'Everything' Group to the role
3) Go to Administration -> Security -> Users and create the 'New User' and select the previously defined 'Role' to assign to the current user. 

Once you get this motion down it's less disjoint to do typical authorization. 
Comment 6 John Mazzitelli 2009-04-08 14:11:49 EDT
Of course, you need to have some resources in inventory that are not in any group (or in a group that is not in any role for your user)  to ensure you are actually filtering out resources. If your test user sees resources that aren't in any group, that would be bad and would constitute a test failure.
Comment 7 Simeon Pinder 2009-04-14 01:45:03 EDT
Due to recent refactoring of the group authorization mechanism, the following additional test conditions need to be added to each of the authz test cases already described:

# Hierarchical/tree groups where group visibility does not apply to the entire tree can now be tested.  In other words, recursive groups B and C below need to be tested to make sure that access to C and below only does NOT give an unauthorized user explicit access/details to B or other portions of the hierarchy unnecessarily.  Non-recursive group definitions also have to be tested to ensure visibility is significantly restricted.

 -> A
    |---> B
          |--> C     
              |--> D

* With restricted visibility, portions of the tree that the user does not have access to are supposed to be listed as (locked) with generic descriptions.

Linux Agent                                                          
      |--> Postgres [Customer Data]
         | --> Database 

becomes more generically

Linux (locked)                                                          
      |--> Postgres Server (locked)
         | --> Database 

Note: I don't know how global perms are supposed to affect the group visibility authz testing as I thought global perms confer a certain amount of group visibility by default. Should ping mazz for his take on this.
Comment 8 Simeon Pinder 2009-04-16 12:38:32 EDT
All sub tasks have been attended to and jira created for issues uncovered.
Comment 9 Red Hat Bugzilla 2009-11-10 15:47:59 EST
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-1848

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