[Building Sakai] support for Admin Lite users

Tue Feb 15 10:40:22 PST 2011

Aaron:

You are right. All the admin tools involved need change.  For UMich, the set
include Sites, Realms, Users, Become Users, and admin view of Worksite Setup
tool.

We decide other admin tools won't be appropriate for Admin Lite after all.
For example, AdminLite users shouldn't be allowed to clean cache using
Memory tool, or adding announcement to MOTD, etc.

Thanks,

- Zhen

On Tue, Feb 15, 2011 at 1:16 PM, Aaron Zeckoski <azeckoski at unicon.net>wrote:

> 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
> _______________________________________________
> 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"
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20110215/611d4a06/attachment.html 