[Building Sakai] Resources and how permissions are implemented
Jim Eng
jimeng at umich.edu
Mon Jun 24 14:26:30 PDT 2013
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20130624/46ab7f78/attachment.html
More information about the sakai-dev
mailing list