Sakai Hierarchy Framework Changes Overview (not implemented)

Editor's Notes

• #2: This document describes and expands up the notion of Sakai Section/Sub Group Awareness and is expected to be the following work once sections are fully supported in the framework.
• #5: We are adding hierarchy to the framework - to decide how each framework capability is used in each tool is up to the designers of the tools over time as each tool is considered.
• #8: Over time, tools will be redesigned and decisions will be made w.r.t. Whether or not the tool is to be section aware.
• #9: In this example, EECS220 is a single site, EECS280 is a single site with multiple sections and EECS240 has two sub-sites. All three of the main sites are sub-sites within the Computer Science site.
• #10: This document does not purport to design any tool changes - this document only show what tool changes are possible given the anticipated framework changes. It will be up to the designers of each tool to decide how or if they want to adapt the tool in the presence of hierarchy.
• #11: You will see the sites you have access to will appear in the navigation bar regardless of their position in the hierarchy - the portal will simply look across all sites and ask the AUTHZ question - “which sites does the current use have the ability to visit?”
• #12: In a tool like Schedule we may choose to provide options as to whether the display will include readable items from sub-sites - perhaps there will be a user selectable depth and possibly an option to look all the way down the tree of sub sites for readable schedule items.
• #13: A tool like Resourses naturally displays a tree of information. The Resources area for each sub-sites appears as a folder in the site. The user naturally navigates up and down the tree. By entering the sub-site content folder, it does not mean that the users has “switched sites” (I.e. tool bar will not change to reflect the sub site tool configurations) - it simply means the the resource tool associated with this placement is looking at the resources in the sub site.
• #15: Now we switch gears from what is required GUI-wise and how course management API is related to the framework, we will look at how the framework will work.
• #16: Objects like Announcement or Calendar entries are stored and owned by their Manager (Service). Each tool placement within a site knows which site it is part of - this is the “context” of that placement. When the tool is executing in a context, the current context value. Each object (like an announcement) records which site/context it is part of. When the service is looking up the announcements for a site, it uses these context indicator to gather up the announcements associated with the site indicated in the context. Each Site/Context has an associated Realm where there are users granted permission sets (access or maintain) which represent a set of basic application permissions (annc.read, sched.write, etc.) As each announcement (A1, A2) is read, the permission to do so is checked using a realm which is directly associated with each site.
• #17: The Context (N20) will be separated from the Site (S15). The Site (tools, placements, configurations) is just one object associated with the context/Node. The Context is simply a node in the hierarchy. If this context has a site, it will be associated to the the context. The arrow directions indicate that it is the Site’s responsibility to store its association with the node. The “current site” is the site object that is associated with the current Node/Context. The replacement for “Realm” is a set of grants to the context. A grant can be done from an individual, group, or group/role combination. In the above example “G50/Learner” is members of group G50 with the “Learner” role and this set is being granted the “access” permission set. A permission set is simply a nice handle for a set of low level atomic permissions. In OSID terms, this would be “function set” and “functions”. A key aspect of permission sets is that they are contextualized by contextNode (I.e. the “access” set is different for each Context). The site maintainer can make new permission sets. It is also possible to grant an individual permission/function in addition to a permission/function set.
• #18: The site’s context node lives in a hierarchy. In this example, Node N20 has three children (N17, N18, N19). This is a configuration where there is one course site, and three “sub-contexts”. There are three sections/groups associated with the course (G50, G51, G52). In the course the instructor group (G49) has maintain and the others have “access”. Each sub context is set up to serve one of the sections. N17 grants maintain to the instructor group (G49) and maintain to the TA’s in G50 and access permission of the Learners in G50. Note that there is no access control inheritance between nodes (indicated by the circle with the “X” in it) - so the instructor group is granted maintain permission in each of the sub-contexts (N17, N18, N19). Also note that the TA role is granted maintain in each of the sub-contexts while they were granted access permission in N20 (the course site). Because the entire group G50
• #19: So far, all of the node to node links have blocked inheritance because we have needed to give less power at a child node than at a parent node. Node N17 is an example of this. Note that because inheritance is blocked, we had to copy the G49 (instructor) grant to node N17. If we allow a node to be a folder, we can add some file Entities (C91 and C92) as children of N20. Like any other entity, we can add fine-grained authorization such as allowing C91 to be publicly viewable. Since N22 is not blocked, it inherits the grants from N20. Similarly C92 inherits permissions from N20. C94, N21, and C95 all inherit from N17 (but not N20 because of the block). N23 is blocked from inheriting from N22 (or N20), so we copy the G49 (instructor group) maintain permission down. Below N23 we create two folders. N26, we add a grant allowing Agent 99 to create and view content. Since there is no block between N26 and N23, G49 also has maintain permission on N26. N26 is effectively a drop box for Agent 99. Looking at N24, G49 has maintain, but Agent 007 has the maintain permission set. If maintain includes site.maintain, then user could actually create a Sakai site hanging off N24. This last use case is not currently a 2.1 requirement but only included to show the flexibility of the data model.
• #20: If we add the capable to mark a grant as un-blockable (indicated in red above), it reduces the need to copy the “very powerful” instructor grants to the various nodes below a block. Another term for this concept is an “admin” grant. If you notice, every time we added a block, we immediately added a grant of “maintain” to G49. If our intent is for G49 to have maintain from N20 on down, lets just indicate this on the grant.. This eliminates the grants at N17, N18, N19, and N23 and significantly simplifies the instructor’s maintenance responsibility each time a new node is made with a block indication. This also allows tools to make nodes with blocked inheritance automatically as part of a wizard without having to figure out which of the grants above are to be copied to newly created sub-nodes which block inheritance. This also allows the trivial addition of a whole new group of guest instructors for weeks 4-6 of the class (G63) and then remove the permission at the end of week 6. This allows us to have less grants and reduces unnecessary copying of permissions and also reduces the need to patch permissions when some aspect of the course permission structure needs to change.
• #21: Continuing, we can imagine granting broad capabilities to department or college level administrators. By making these grants non-blockable, power flows down regardless of the block indicators. N15 is a departmental node where a departmental administrator's group (G86) is given “access” permission for all nodes/courses/sites within the department. We could even place a site S11 (add some tools) at Node N15 and grant “maintain” to the G87 group. Because of the blocks, the G87 group has no power beyond Node N15 while G86 has broad access power at N15 and below. At node N1, Group G85 is given some very broad powers over the whole tree. It is not blockable at all :)
• #22: As each node is added to the hierarchy, the transitive closure is computed (Orange links) so that all parents of a node can be determined in a single database query. As the transitive closure is being computed, once a block is encountered, all remaining transitive links as one goes up the tree are marked as blocked. Note that there is no transitive closure computed for an entity like content blob C93. Nor do any fine-grained object permissions participate in transitive closure computation. By not requiring any transitive closure for every entity, we significantly reduce the size of the transitive closure tables.
• #23: From C93, we can get the entire parent tree and for those parents marked as blocked, drop the “not-un-blockable” grants. This yields all of the applicable grants in a single sub-select. Permission sets can be expanded to permissions and group membership can be expanded as well. The permissions will be filtered down to “content.read” and we simply check to see if there are any direct or group membership, or group/role grants which enable content.read. With proper database design, this can all be done in a single query. (See Appendix S)
• #25: This is not really SQL - it is an outline of the needed SQL.
• #26: If you look at adding node N29 which would be added *with* inheritance, we simply add the N29->N22 row and make a copy of the N22 rows changing the child to N29. All of the block settings for N22 are already correct for N29. If you look at adding node N23 which would be added without inheritance, we simply add the N23->N22 rows and make a copy of all of the N22 rows marking them all them all “block” while changing the child row from N22 to N23. Because if the new node is blocked to its immediate parent - it is blocked all the way up - regardless of the parent is blocked.
• #27: We assume that Grantees resolves into Agents and Function Sets resolve simply into functions without showing the table detail to accomplish the joins. Also the mapping from permission set (and associated filtering) is not shown. Also it needs to be clear that permission sets are contextualized to the nodes they are associated with (I.e. each node can separately define “access”)
• #28: Looking for the permissions on C93, we first look for any direct permissions and find the A99 permission. We union this with any permissions granted on the transitive parents (N23, N22, N20, and N15) of the C93’s designated nodes. We filter these permissions based on whether the node relationship is blocked and whether the grant is blockable. In the case where the grant is blockable and the inheritance is blocked (G50 and G86) the grants fall out of the join.
• #29: C94 is a bit trickier and will require some subtle design on the JOIN query to do it all in a single join. The fun comes in around Node 20 and the G50 access. Because of the C94 -> N22 -> N20 path is “inherit” we need to apply the G50 “access” grant to C94. We must be careful *not* to throw the grant away because the C94 -> N17 -> N20 has a “block”. As long as the JOIN is written to accumulate permissions and do the block/blockable filtering logic separately on each intermediate tuple generated by the join, this should be feasible. There may be other challenging multi-linked situations which may need working through.