[Building Sakai] Resources and how permissions are implemented
Kara Stiles
kstiles at brutuspartners.com
Fri Jun 28 08:54:49 PDT 2013
For some implementations, I've helped folks create content storage sites,
which are basically just project sites with an extra role in them. These
content storage sites are used as a central location for an individual
instructor's resources. Resources can be made public in these sites and
embedded elsewhere as Jim suggests in his last email, but if you want to
add a *little bit* of extra protection, you could create a .auth role in
the content storage site and give that role the content.read permission,
thereby ensuring that if a user wants to see a resource that is stored in
content storage site they must have
1. A login to your Sakai instance AND
2. The direct link to the resource (either embedded in an html page or an
assessment question, etc.)
This doesn't completely solve the issue of assessment questions and
students "figuring out" how to get the absolute URL of a resource an
sending it to their friends, but it sure makes site duplication clean-up
easier for embedded resources.
Thanks,
Kara
On Thu, Jun 27, 2013 at 4:48 PM, Jim Eng <jimeng at umich.edu> wrote:
> One concern we've heard is with images or other entities being accessible
> outside of the assessment or assignment (for example, being discovered by
> students before an exam and compromising the exam in some way). If that's
> not an issue, it might work to attach the images and then just make the
> images public. Is that a possibility?
>
> It does sound like your solution might be good, but it adds complexity to
> code that is already complex, so it may not be sustainable over time.
>
> I will see if I can think of any other approaches. Maybe someone else on
> this list might have suggestions.
>
> Jim
>
>
> On Jun 27, 2013, at 4:16 PM, David Wafula Wanyonyi <
> DavidWafula.Wanyonyi at wits.ac.za> wrote:
>
> I got distracted abit ...now back to this.
> One specific use case could be summarized below:
> Some of our lecturers, who own more than one course, when they insert
> images in Tests n Quizzes, occasionally, reference an image from a
> different course they own. Now students, who often belong only to one of
> the courses at a time end up with questions that have missing images and
> stuff. So we correct this ...usually by getting them to create a copy of
> the images into respective courses.
> As you can imagine, these sites usually cannot be nested.
> So we are trying to allow them to share resources within courses in a bit
> of an 'easier' way. We do have other small customizations to Resources but
> these we are handling them just fine.
>
> We are in the process of implementing an option to share a specific
> resource between sites by adding a radiobutton under "Availability and
> Access" in resource details. When selected, a list of the course they have
> write persmissions appears, and they check the desired options.
>
> We thought of a quick way to do this under the hood: just duplicate the
> resource into the selected sites. This does work. But obviously doesn’t
> synch whenever the resource is changed in one site.
> Then i thought of the realms route ..and ya, the progress there is little
> slow.
>
> Thanks.
>
> ------------------------------
> *From:* Jim Eng [jimeng at umich.edu]
> *Sent:* Monday, June 24, 2013 11:26 PM
> *To:* David Wafula Wanyonyi
> *Cc:* dev sakai
> *Subject:* Re: [Building Sakai] Resources and how permissions are
> implemented
>
> David,
>
> That's a good question. Can you say more about the use-cases in which you
> want to support sharing resources across more than one site.
>
> In theory, it would be possible to share resources in different ways and
> make them available to groups of users in different places, but creating a
> user interface to support that might be problematic.
>
> Resources were originally a little more restricted than they are now.
> People described a use case in which an instructor wants to share a set of
> resources from one section of a class with students in another section.
> That was one of the reasons for showing the "Other sites" twizzle at the
> bottom of the resources page. An instructor might open up one site's
> resources folder there, select the resources to be shared, copy them and
> paste them into the second site. But of course, if the resources might
> change and they need to remain in sync from one site to another, that might
> not work.
>
> If there's some case that requires sharing resources (and possibly other
> entities?) from one site to another, maybe you could use nested sites, in
> which the shared resources would be in the parent site and other resources
> would be in the child sites. Would something like that work?
>
> If nothing I've mentioned seems like it will help, explain the issue a
> little more. There must be something that relates two or more sites. If
> you were designing a user interface that would allow an instructor (or
> someone else) to share resources across sites, how would you present the
> choice to that person? What options would you want the person to have?
> Would they be copying the resources from somewhere, or linking to the
> originals (e.g. is there a need to maintain a link back to the originals so
> the files seen in the site change if the originals do)?
>
> Thanks.
>
> Jim
>
>
>
> On Jun 24, 2013, at 5:06 PM, David Wafula Wanyonyi <
> DavidWafula.Wanyonyi at wits.ac.za> wrote:
>
> Jim, thanks so much for the detailed response.
> So from what I understand now, a site is an authorization group, and such
> a group has to have members with roles. The roles have functions , which
> are the basic authorization units.
>
> So say to make a resource from Site A shareable across Site B , we start
> with something like:
>
> 1. String
> originalRef=serverConfigurationService.getAccessUrl()+resourceId; //this
> ref points to site A...right? so not sure where to go on with this
> 2. AuthzGroup
> authzGroupOfSiteB=authzGroupService.getAuthzGroup(ref);
> 3. Role role = site.getRole(AuthzGroupService.AUTH_ROLE);
> 4. role.allowFunction(AUTH_RESOURCE_READ);
> 5. authzGroupService.save(site);
>
> As can see from the above code, i have one problem:
>
> How to get value of 'ref' in line 2 . I believe this value has to be
> associated with Site B as well as resourceId....am just not sure how to get
> the two together.
>
> Or if there is a better way of doing all of this.
>
> Thanks.
>
>
>
> ------------------------------
> *From:* Jim Eng [jimeng at umich.edu]
> *Sent:* Monday, June 24, 2013 3:57 PM
> *To:* David Wafula Wanyonyi
> *Cc:* dev sakai
> *Subject:* Re: [Building Sakai] Resources and how permissions are
> implemented
>
> Hi David,
>
> I can give a general overview that will be hazy on some details.
>
> Content Hosting implements a pattern for permissions used throughout
> Sakai. Permissions queries are answered by a central service (I'll refer
> to that as the Authz Service, but that may not be quite right). The Authz
> Service makes a callback to the "entity producer" (in this case, the
> Content Hosting Service) to get a list of "realms" that should be checked
> to determine whether a particular user (almost always the current logged-in
> user) has a permission with respect to an entity (in this case a
> content-collection or a content-resource). So like other entity producers,
> the Content Hosting Service has a method that is called by the Authz
> Service to get a list of realms that will be checked to determine access to
> the entity.
>
> If I remember correctly, that method is declared here:
>
>
> http://source.sakaiproject.org/release/kernel/1.1.2/apidocs/org/sakaiproject/entity/api/EntityProducer.html#getEntityAuthzGroups(org.sakaiproject.entity.api.Reference,%20java.lang.String)
>
> And you can find the implementation by searching for
> "getEntityAuthzGroups" in this file:
>
>
> https://source.sakaiproject.org/svn/kernel/trunk/kernel-impl/src/main/java/org/sakaiproject/content/impl/BaseContentService.java
>
> The implementation of this method is simpler in most other sakai entity
> producers. In Content Hosting, it is complicated by the fact that CHS
> manages a hierarchy of content-collections and content-resources. At any
> level of the hierarchy, access can be inherited from above, redefined to
> include additional permissions with respect to a folder and its contents,
> restricted to particular groups, etc.
>
> Layered on top of permissions are additional settings that allow folders
> and files to be hidden from those who would otherwise have access.
>
> In the simplest case, if an instructor adds a file to the resources folder
> in a brand new course site without restricting or enlarging access in any
> way, the getEntityAuthzGroups would return three realm id's -- one for the
> folder, one for the site's top resources folder, and one for the site
> itself. The permissions check would indicate that the new file's
> permissions are inherited from the site's resources folder, which are
> inherited from the site itself. That's where the site id comes in. If we
> are trying to answer the question, "can this user access this file?" the
> answer is the same as "does this user have read-access in this site?"
>
> In a more complicated case, suppose an instructor created three groups of
> students within a new course site and then created a resources folder for
> each group and restricted access to one group in each of those folders.
> Now, if the instructor adds a file to the folder for Group1, the realms
> passed back might be for the file, the Group1 folder and Group1 itself (I
> say "might be" because it's been a long time since I looked at that code
> and I'm not sure this is a full description). In this case, we find that
> the file inherits its permissions from the Group1 resources folder, and
> that that folder is restricted to Group1. So if we are trying to answer the
> question, "can the current user access this file?" we find that the answer
> is the same as "does this user have read-access in the 'Group1' authz
> group?"
>
> I may be forgetting something essential here, but I think that gives a
> general overview.
>
> Maybe somebody else can get more specific, but if not, I'm hoping this
> gives a roadmap to find what you are looking for.
>
> Jim
>
>
>
>
> On Jun 24, 2013, at 4:39 AM, David Wafula Wanyonyi <
> DavidWafula.Wanyonyi at wits.ac.za> wrote:
>
> Dear team,
> Please clarify something for me:
> When an instructor in a site uploads a file in Resources, internally
> permissions are applied to the resource.
> What service/methods are used to implement these permissions in the code?
>
> Looking at the code the closest i came to understand how it works: siteId
> is possibly becomes the AuthzGroupID and AuthzGroupService is used to
> apply these permissions. Not sure how this is achieved if that is the case.
> And then there is BaseContentService, but this seems to delegate actual
> permissions implementation somewhere else ?
>
> We are in process of implementing local custom additions to Resources,
> some which include ability to share a resource between selected sites. If
> we get the permissions right, we are going to supply a patch for sharing
> resource between sites for 2.9.x
>
> Regards,
> david
>
> This communication is intended for the addressee only. It is confidential. If you have received this communication in error, please notify us immediately and destroy the original message. You may not copy or disseminate this communication without the permission of the University. Only authorised signatories are competent to enter into agreements on behalf of the University and recipients are thus advised that the content of this message may not be legally binding on the University and may contain the personal views and opinions of the author, which are not necessarily the views and opinions of The University of the Witwatersrand, Johannesburg. All agreements between the University and outsiders are subject to South African Law unless the University agrees in writing to the contrary.
>
> _______________________________________________
> 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"
>
>
> This communication is intended for the addressee only. It is confidential. If you have received this communication in error, please notify us immediately and destroy the original message. You may not copy or disseminate this communication without the permission of the University. Only authorised signatories are competent to enter into agreements on behalf of the University and recipients are thus advised that the content of this message may not be legally binding on the University and may contain the personal views and opinions of the author, which are not necessarily the views and opinions of The University of the Witwatersrand, Johannesburg. All agreements between the University and outsiders are subject to South African Law unless the University agrees in writing to the contrary.
>
>
> This communication is intended for the addressee only. It is confidential. If you have received this communication in error, please notify us immediately and destroy the original message. You may not copy or disseminate this communication without the permission of the University. Only authorised signatories are competent to enter into agreements on behalf of the University and recipients are thus advised that the content of this message may not be legally binding on the University and may contain the personal views and opinions of the author, which are not necessarily the views and opinions of The University of the Witwatersrand, Johannesburg. All agreements between the University and outsiders are subject to South African Law unless the University agrees in writing to the contrary.
>
>
>
> _______________________________________________
> 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/20130628/5ebd3bf8/attachment.html
More information about the sakai-dev
mailing list