[Building Sakai] support for Admin Lite users

Tue Feb 15 11:01:44 PST 2011

Ah, ok, so the changes would mostly be limited to the sakai core tools then.

-AZ

On Tue, Feb 15, 2011 at 1:40 PM, Zhen Qian <zqian2004 at gmail.com> wrote:
> 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"
>
>

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