[Building Sakai] Resources and how permissions are implemented
Matthew Jones
matthew at longsight.com
Mon Jun 24 14:17:21 PDT 2013
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> 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.
> **
>
>
> _______________________________________________
> 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/20130624/4643743a/attachment.html
More information about the sakai-dev
mailing list