[Building Sakai] support for Admin Lite users

[Zhen Qian]

Hi, all: 

In UMich, we are looking for ways to provide tier-1 help desk staff a set
of functionalities that will allow them to perform the tasks they are
expected to do, without exposing functionality reserved for the use of
staff higher up in the chain with full admin rights. The requirement is
documented inside umich-232 [1].

The problem details and suggested approaches are listed below. We'd like to
know if there is any common interest in the community, and it would be
great to get feedbacks and get the community involved. Any
ideas/concerns/suggestions of design or coding would help a lot. 

REQUIREMENTS:

A separate site will be created for AdminLite user. 

Those tools should not be added to the site: Aliases, MOTD, Resources,
On-Line, Memory, Site Archive, Job Scheduler, iTunesU, Site Info, Config
Viewer, iTunesU Admin

Those tools should be added into the site: Worksite setup, Users, Sites,
Realms, Become User

UI modification should be done to those added tools, like all
the New/Add
links should be hidden; as default no full list view is shown to AdminLite
users and they can only search for target site; not all site attributes are
editable by AdminLite users; AdminLite user can become users other than
super admins; etc. 

For details of requirements, please see the attached pdf file in UMICH-232.

KNOWN APPROACHES:

Similar topics has been raised in the community before, e.g. give super
user rights to junior admins explicitly for tools like user memberships,
and sitestats tools, etc. Kara Stiles from rSmart groups suggested to add
necessary permission sets to !site.helper realm for junior admin role and
allow them accessing those tools [2]. Both User Membership tool and
SiteStats tool have their own permissions defined, but not for other admin
tools like Sites and Realms, hence this approach works for former tools,
but not the latter ones.

Another alternative is AdminX tool, which has been used by different
schools. It can be run on a different
server or within Sakai itself. When
running as client mode, couple of sites can be attached to the client, and
user can be add to the client with admin role and only manages all the
attached sites. User can also be added as helpdesk user, and then have
access to all sites like normal sakai admin user. The admin users differ
here in terms of "how many sites they can manage", but not "the level of
admin permission they have on those sites". Even though AdminX is a cool
project, it is no longer actively maintained/supported. We need to port the
concerpts there back into Sakai.

SUGGESTED APPORACHES:

Here we suggest two alternative approaches to address the permission
problem:

Approach 1: 

Add two new functions isAdminUser() and isAdminUser(String userId) into
SecurityService.java (true if the user is of admin role to "adminlite" or
"!admin" site, see following). The old isSuperUser() and isSuperUser(String
userId) functions remain unchanged.

Pros: supports for an extra admin level;
Cons: a new security check is
introduced.

Approach 2:

Add new permissions to those admin tools, assign those new permissions to
"adminlite" role inside !site.helper realm, and change those admin tools to
recognize the new permission and give AdminLite users limited access.

Pros: No new authz function is introduced; Cons: new permission is added
and requires for db changes and conversions.

Admin Tools Changes:

Many tools in Admin tool set checks for isSuperUser() first. Replace it
with isAdminUser() (Approach 1) or checks for proper permission ( Approach
2) to allow adminlite access;

Many tools show a list of objects as default. However, in AdminLite mode,
we only want to allow adminLite user access by search first. So the list
view will be hidden.

We want to restrict "Admin Lite" user to edit certain properties of the
site (e.g. skin, title, etc) or realm (e.g. provider id). A possible
solution is to add one new config property into tool registration file. For
example, the
following attribute is added into sakai.sites.xml file: . Then
only "title" and "skin" fields are shown as changeable for AdminLite user,
while others are shown READONLY.

Change the Become User tool code so that is would recognize the fact that
"Admin user can become user to other normal users, but cannot su to super
admin user"

A list of patches are attached to UMICH-232 [1] and are ready to be
reviewed.

Concerns:

We already got those concerns raised locally here.

1. Sakai was designed with only one type of admin type in mind, and
isSuperUser() was used in many places in Sakai code base. Will the
acception of new tool permissions or new isAdminUser() check introduce any
security concerns?

2. Couple of patches are needed for legacy admin tools, which will sit on
branches first. It is a problem for maintaining those patches with releases
before they can be accepted and merged back to trunk. 

3. Need to come up with complete coverage of QA test for those admin tools.
AdminLite
users should be prevented getting into !admin site, have no
update access to those READONLY site/realm attributes, cannot change admin
user's password, etc.

4. Will AdminLite user be restricted to modify sites using
webservices/entitybroker?

5. There is still no support for "local admin user can only edit subset of
sites".

-------------------------------------------------------------

Any comments/thoughts are welcomed. If necessary, I will start with a new
wiki page for this.

Thanks,

- Zhen

------------------------------------

[1] https://jira.sakaiproject.org/browse/UMICH-232
[2] http://permalink.gmane.org/gmane.comp.cms.sakai.devel/38931
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20110215/dc86da82/attachment.html