Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 43 Next »

JIRA: SAK-131: Add Role based SU security

This request to add Role-based SU security encompasses two parts:

  1. a role-based specification of who may use superuser (SU) access and what the limitations of SU access are based on the user's original role, and
  2. allows the portal to recognize that the user is in an SU role and provide a UI mechanism (link or button) for the user to leave SU and return to their own role without having to log out and log in again.

The story details of these separate tasks are listed as:

SAK-354: Add Role based SU security
SU tool uses Security(Service).isSuperUser() to determine who can SU. This should be modified to use agent - function - target ....

IT Express - can su - students
IT Express - can su - faculty
IT Express - cannot su - admin

SAK-367 - CharonPortal Tracking of assumed Id's with 'Return to...'
part two of two
2) CharonPortal patch: - assumed identities tracked with 'Return to <Eid>' link next to Logout link
create special url ('/realuser') that the portal will use to reload any existing previous usage session

Test for sub-story SAK-354: add realm based security to SuTool

This test plan covers the sub-story SAK-354: add realm based security to SuTool ONLY

Description:
This modification to the SU Tool is intended to allow users who do not have sakai SuperUser access to SU other users, e.g., allow IT Express personnel to SU without having admin access. On Start up, the tool looks for or creates a security realm (reference: realms tool).... by default the realms name is '!su.can_su_realm' but it can be modified by editing the tool registration file.

Administrators should add roles to this realm which have the appropriate security function (or permission). This function name is 'su.can_su' by default (but can be changed by an administrator by editing the tool registration file).

The template permission matrix with an example of source, function, target, and results:

source

function

target

result

user A

can SU

user B

true/false

Definitions: Types of users

SuperUser = any user who the ability to edit Realms within Administration Workspace (i.e., a SmartSite admin user)
Priv User = users who are added to a role in the 'SU Realm' which has the 'Can SU' security function (i.e., an IT Express user assigned to this role)
Standard User = any user who is not a SuperUser, and who

  1. has not been added to a role in the 'SU Realm' which has the 'Can SU' security function, or
  2. has been added to a role in the 'SU Realm' which does not have the 'Can SU' security function

What is expected:

Test #

source

function

target

result

Test 3

SuperUser

can SU

SuperUser

false

Test 7a

SuperUser

can SU

Priv User

true

Test 3

SuperUser

can SU

Standard User

true

Test 5

Standard User

can SU

SuperUser

false

Test 7b

Standard User

can SU

Priv User

false

Test 4

Standard User

can SU

Standard User

false

Test 6a

Priv User

can SU

SuperUser

false

Test 6b

Priv User

can SU

Standard User

true

Test 6c

Priv User

can SU

Priv User

true

Preparation

  • Requires initial SU Tool Setup in Realms if this is a new system.
  • SuperUser access is required for Administration Workspace changes
  • A test site with the SU Tool installed (see #SU Tool Setup to set up a course)
  • At least two non-SuperUser accounts in the test site (e.g., sakaiinst user or a non-SuperUser test partner)
  • Knowledge of 1-2 other SuperUser logins

Test Series

Assumption

Default realm name and default security function name in tool reg file

Test 1 - Validate that SU Tool can be created upon access by SuperUser

Login as admin, access the Realms tool, and delete the the realm entitled '!su.can_su_realm'.
Select the test site that contains the SU Tool.
Type the name of any non-admin or admin user and select 'Become User' button (the latter case will fail the su, but should achieve the desired results for this test.)
If necessary, log out and re-login as an admin user.
Return to Realms tool and search for the above realm name.

Expected result: '!su.can_su_realm' will be created if missing the first time the tool is opened by a SuperUser.

Test 2 - Validate that SU Tool can be created upon access by Standard User

Login as admin, access the Realms tool, and delete the realm entitled '!su.can_su_realm'.
Log out and re-login as a non-admin user in the test site with the SU Tool.
Type the name of any non-admin or admin user and select 'Become User' button (the latter case will fail the su, but should achieve the desired results for this test.)
If necessary, log out and re-login as an admin user.
Return to Realms tool and search for the above realm name.

Expected result: '!su.can_su_realm' will be created if missing the first time the tool is opened by a Standard User.

Test 3 - Validate SuperUser can SU other users except another SuperUser

Login as admin and select the test site that contains the SU Tool.
Type in the name of another SuperUser and select 'become user'.

Expected result: 'unauthorized' - SuperUsers cannot su a SuperUser account

Select the up arrow (Reset function.)
Type in the name of a Standard User and select 'become user'.

Expected result: success

Test 4 - Validate Standard User cannot SU another Standard User

Login as a Standard User and select the test site that contains the SU Tool.
Type in the name of another Standard User and select 'become user'.

Expected result: 'unauthorized' - Standard users cannot su another standard user account with out the correct permissions

Test 5 - Validate Standard User cannot SU SuperUser

Login as a Standard User and select the test site that contains the SU Tool.
Type in the name of a SuperUser and select 'become user'.

Expected result: 'unauthorized' - Standard users cannot SU a SuperUser account.

Test(s) 6

Prep for 6a, 6b and 6c
  1. Login as admin and access the Realms tool and select the realm entitled '!su.can_su_realm'.
  2. From the Edit Realm screen, select the Add Role link and type in a Role Id name (for example, 'Can SU'.)
  3. Check the checkbox next to 'su.can_su' permission for that role and then Save.
  4. From the Edit Realm screen, select Grant Ability.
  5. Type in the name of a non-SuperUser in the test site, select the role name you created, and then Save.
  6. Repeat the previous step. You now have 2 non-SuperUsers with SU access - they are 'priveleged' users.

Test 6a - Validate Priveleged User cannot SU SuperUser

Logout and re-login as one of the Priveleged User.
Select the test site that contains the SU Tool.
Select SU Tool and type in the name of SuperUser and select 'become user'.

Expected result: 'unauthorized' - Privileged users cannot SU a SuperUser account.

6b - Validate Priveleged User can SU Standard User

Reset the SU Tool (by using the up arrow.)
Type in the name of another standard user and select 'become user'.

Expected result: success

6c - Validate Priveleged User can SU another Priveleged User

Logout and re-login as one of the Priveleged User.
Select the test site that contains the SU Tool.
Type in the name of the other Priveleged User and select 'become user'.

Expected result: success

Test 7a - Validate SuperUser can SU Priveleged User

Logout and re-login as SuperUser.
Select the test site that contains the SU Tool.
Select SU Tool and type in the name of one of the Priveleged Users and select 'become user'.

Expected result: success

7b - Validate Standard User cannot SU Priveleged User

Logout and re-login as Standard User.
Select the test site that contains the SU Tool.
Type in the name of one of the Priveleged Users and select 'become user'.

Expected result: 'unauthorized' - Standard users cannot SU a Privileged account.

Test 8

Prep for 8
  1. Login as admin and access the Realms tool and select the realm entitled '!su.can_su_realm'.
  2. From the Edit Realm screen, select the Add Role link and type in a Role Id name (for example, 'Cannot SU'.)
  3. Do not check any permissions and Save.
  4. Return to the Edit Realm screen for '!su.can_su_realm'. Select one of the newly added Priveleged users.
  5. From the Edit Realm screen, select Remove All.
  6. From the Edit Realm screen, select Grant Ability.
  7. Type in the name of the same Priveleged User you removed and then select the new role name you created and Save. You have now added a user to a role that does not include the can_su security function.

8 - Validate Priveleged User without can_su in Role cannot SU successfully

Logout and re-login as Priveleged User with new 'Cannot SU' role.
Select the test site that contains the SU Tool.
Type in the name of one of the Priveleged Users and select 'become user'.
Reset and type in the name of s SuperUser and select 'become user'.
Reset and type in the name of a Standard User and select 'become user'.

Expected results - all 3 attempts: 'unauthorized' - Standard users cannot SU a Privileged account.

SU Tool Setup

To setup the SU Tool in a particular course or project, login as an admin and follow these steps:

  1. In Administration Workspace and select the Sites tool. Select the course desired.
  2. Select the Pages button; on the new screen select the New Pages link.
  3. Enter SU Tool under Title and select the Tools button.
  4. Select the New Tool link.
  5. Select 'Admin: Become User (sakai:su)' from the list and then the Save button.
  • No labels