[Building Sakai] support for Admin Lite users

Tue Feb 15 10:16:09 PST 2011

This looks promising but it looks like this would require a
refactoring of all existing tools (core and contrib) which use the
isSuperUser check (which is quite a lot of them).

Does that sound right or am I missing something?

-AZ

On Tue, Feb 15, 2011 at 1:03 PM, Zhen Qian <zqian at umich.edu> wrote:
> 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
>
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org
> with a subject of "unsubscribe"
>

-- 
Aaron Zeckoski - Software Engineer - http://tinyurl.com/azprofile