[Building Sakai] Resources and how permissions are implemented
David Wafula Wanyonyi
DavidWafula.Wanyonyi at wits.ac.za
Thu Jun 27 13:17:11 PDT 2013
Thanks Mathew...
________________________________
From: Matthew Jones [matthew at longsight.com
Sent: Monday, June 24, 2013 11:17 PM
To: David Wafula Wanyonyi
Cc: Jim Eng; dev sakai
Subject: Re: [Building Sakai] Resources and how permissions are implemented
Re: #2. There is no defined way to do site hierarchy that was ever officially committed to Sakai.
https://jira.sakaiproject.org/browse/SAK-17159
The only thing that got close was a site property which you can set in Site Info->Link to parent site. But it doesn't look like that code was ever actually committed to kernel, it only exists in site-manage to set the property, and portal to look up the property.
https://jira.sakaiproject.org/browse/SAK-17001
https://jira.sakaiproject.org/browse/KNL-422
So you'd probably want to do that (KNL-422) unless you just were going to reference on this property and use that. :/
On Mon, Jun 24, 2013 at 5:06 PM, David Wafula Wanyonyi <DavidWafula.Wanyonyi at wits.ac.za<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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.
_______________________________________________
sakai-dev mailing list
sakai-dev at collab.sakaiproject.org<mailto: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<mailto:sakai-dev-unsubscribe at collab.sakaiproject.org> with a subject of "unsubscribe"
<table width="100%" border="0" cellspacing="0" cellpadding="0" style="width:100%;">
<tr>
<td align="left" style="text-align:justify;"><font face="arial,sans-serif" size="1" color="#999999"><span style="font-size:11px;">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. </span></font></td>
</tr>
</table
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20130627/f47dbb57/attachment.html
More information about the sakai-dev
mailing list