[Building Sakai] support for Admin Lite users

Thu Apr 14 10:54:21 PDT 2011

Hi, all:

As a followup to this previous email thread, I have created KNL-708 "support
for lite administration role" with a tentative patch file.

The admin lite users are considered (for now) as with system-wide admin
rights, but lite admin-function-set. We want to address the departmental
admin or school affiliates concept later on (as requested in SAK-20412).

In the proposed patch file, two new functions are added:

SecurityService.isSuperAdminUser() - returns true if the current user has
site.upd in "!admin" site;
SecurityService.isSuperAdminUser(String userId) - returns true if the given
user has site.upd in "!admin" site;

The existing implementation of isSuperUser() is changed, so that:

SecurityService.isSuperUser() - returns true if
SecurityService.isSuperAdminUser()
returns true, or current user has site.upd in "!adminlite" site;
SecurityService.isSuperAdminUser(String userId) - returns true if
SecurityService.isSuperAdminUser(String
userId) returns true, or given user has site.upd in "!adminlite" site;

There is no change to other existing Sakai tools and services.

Under UMICH-232, a new tool named AdminLite (id="sakai.adminlite") has been
implemented. The source code can be find here:
https://source.sakaiproject.org/contrib//umich/adminlite/trunk/. Basically
the tool is a combination of four existing admin tools: Sites, Realms, Users
and Become User, but in a function-lite view.

In order to use this tool, one need to create a project site with site id
"!adminlite", add "Admin Lite" tool into this site, and add all those admin
lite users in with site.upd permission on.

I'd appreciate anyone take a look at the kernel patch and try out the new
AdminLite tool. Any comments are greatly welcomed!

Thanks,

- Zhen

On Tue, Feb 15, 2011 at 5:33 PM, Steve Swinsburg
<steve.swinsburg at gmail.com>wrote:

> Hi Zhen,
>
> So as to minimise disruption to existing tools and services, I would
> support Option 1, so long as the types of admin users can still be
> distinguished. So add a new method to SecurityService, isAdminUser() and
> isAdminUser(String userId) but it should only check the adminlite
> site/realm.
>
> There would then be the following methods:
>
> SecurityService.isAdminLite() - returns true if current user has admin role
> in adminlite site
> SecurityService.isAdminLite(String userId) - returns true if given user has
> admin role in adminlite site
> SecurityService.isSuperUser() - remains unchanged, checks current user has
> admin role in !admin site.
> SecurityService.isSuperUser(String userId) - remains unchanged, checks
> given user has admin role in !admin site.
>
> Tools can then continue to use the isSuperUser methods and gradually
> provide additional support for the new level of admin as required, ie
> introduce the second check if required. Keeping the two groups separate is
> important for more flexibility.
>
> An example is Profile2 which supports the isSuperUser check and allows
> those users to edit other people's profiles. It might be that we don't want
> the AdminLite users editing those people's profiles, so we would need to
> distinguish between the two admin groups.
>
> Alternatively, rather than a new realm, can we just add new roles to the
> !admin realm and check those?
>
> Also, is AdminLite a name set in stone? What about Support or Helpdesk as
> alternatives.
>
> cheers,
> Steve
>
>
> On 16/02/2011, at 5:03 AM, Zhen Qian 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"
>
>
>
> _______________________________________________
> 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/20110414/d67371e2/attachment.html 