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
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.
Modifying other users' passwords (other than your own)
Modifying other users' details and preferences (other than your own)
Viewing/Modifying Server Configuration Settings
Manage agent plugins that the server has deployed
Update the license
Adding/Changing Metric and Alert Templates
View/Manage Affinity Groups
View/Manage Partition Events
The legacy jsp Authorization tag isn't doing what it should be for non-resource based pages. Its authorizing things it should not.
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).
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.
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.
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.
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.
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.
* 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.
|--> Postgres [Customer Data]
| --> Database
becomes more generically
|--> 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.
All sub tasks have been attended to and jira created for issues uncovered.
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-1848