Sakai Hierarchy Framework Changes Overview
•Download as PPT, PDF•
0 likes•445 views
- The document discusses proposed changes to the Sakai framework to introduce the concepts of hierarchy between sites and sections (groups) within sites. - This would allow sites to be connected in parent-child relationships and for permissions and content to flow down the hierarchy. It would also allow additional groups to be created within sites. - Tools would need to be designed to optimally make use of these new capabilities, either ignoring hierarchy, rolling up/down content, or being fully aware of hierarchy. The framework changes would enable both hierarchy and sections to be implemented before redesigning tools.
Recommended
Recommended
More Related Content
Similar to Sakai Hierarchy Framework Changes Overview
Similar to Sakai Hierarchy Framework Changes Overview (20)
More from Charles Severance
More from Charles Severance (20)
Recently uploaded
Recently uploaded (20)
Sakai Hierarchy Framework Changes Overview
- 1. Sakai Hierarchy Framework Changes Overview Draft - 09-29-2005 Charles Severance csev@umich.edu
- 3. Comparison • Sections are additional groups/rosters *within* a Sakai site • Hierarchy is the relationship between sites, and can be used to describe the relationship between other entities in the Sakai system (sites, files, folders)
- 4. Tool Impact on Hierarchy • Like Sections, tools can be written which are completely unaware of hierarchy - these tools simply operate in a “Site” and effectively ignore any parent, child, or other sites. – Content/Resources - Likely to be very aware and affected greatly by hierarchy – Chat tool will probably ignore hierarchy • Deciding how to use/present hierarchy is a decision left up to the the tool designer.
- 5. What is a “Site”? • It is “one tab” across the top of the Sakai GUI • It is a set of pages and tools which operate “together” in a context. • The concept of a site does not change across these framework improvements • However Sites become more capable and flexible as these new framework capabilities are added.
- 6. Sakai Site - 2.0 Site: EECS280 Roster Tool List Chat Info … The roster (realm) contains both membership and permission information. The roster can be fed externally or internally. Message Folder File File Annc
- 7. Sakai Site - 2.1 - Sections Site: EECS280 Roster Tool List Chat Info … We add sub-rosters or Sections. Some of the entities/objects/tools will be changed to set permissions and reflect sections as part of their security. Other entities will not be section aware in 2.1 and their security will be determined by the Roster/Realm for the whole site. Message Folder File File Sec A Sec B Annc
- 8. Sakai Site - Hierarchy Hierarchy allows sites to become “connected” in various parent and child relationships. Permission and inheritance can flow down the hierarchy depending on the configuration of the site’s relationship with its parent. Site: EECS280 Rr Tool Chat Info … Sec Sec Site: EECS220 Rr Tool Chat Info … Site: EECS240 Rr Tool Chat Info … Site: Computer Science Rr Tool Chat Info … Site: EECS240-LEC 1 Rr Tool Chat Info … Site: EECS240-LEC 2 Rr Tool Chat Info …
- 9. Possible Tool Changes • Each tool must be carefully designed as to how it will be affected by hierarchy • Several approaches for a tool – Ignore Hierarchy (Chat tool) – Roll - up or down objects below based on some configuration of the tool (Schedule) – Make tool fully aware of hierarchy - make hierarchy an implicit part of the tool (Resources)
- 10. Hierarchy in the Portal QuickTime™ and a TIFF (Uncompressed) decompressor are needed to see this picture. Sites EECS280 .. Up to Computer Science EECS280-LEC1 EEGS280-LEC2 EECS280-LEC1 EECS280-LEC2
- 11. Rolling up Hierarchy in a Tool QuickTime™ and a TIFF (Uncompressed) decompressor are needed to see this picture. Schedule EECS280 Include schedule items from sub-sites in schedule All sub-sites Depth EECS280-LEC1 EECS280-LEC2 Options 2
- 12. Implicit Hierarchy in a Tool QuickTime™ and a TIFF (Uncompressed) decompressor are needed to see this picture. Resources EECS280 Syllabus (folder) Properties | Add Item | Delete Images (folder) Properties | Add Item | Delete xyz.ppt Properties | Add Item | Delete EECS280-LEC1 (Sub Site) Properties | Add Item | Delete EECH280-LEC2 Properties | Add Item | Delete Other Sites Search Repositories EECS280-LEC1 EECS280-LEC2
- 13. Summary • SubSites (Hierarchy) and Sections (Groups) are complimentary notions • The Sakai framework Authorization, and Site APIs will support both hierarchy between sites and grouping within sites • Tool modifications will need to be designed to make ideal use of these capabilities from an end-user perspective. • It would probably be a good idea to make the framework changes for both hierarchy and sections and then redesign the tools once - considering both issues at the same time.
- 15. Realm: 15 Site Manager Announcement Manager Calendar Manager S15 S16 A1 A2 C1 A3 C2 Thread Context:S15 S15 | S16 ANNC A1 A2 Sched csev access annc.read sched.read annc.read annc.write sched.read sched.write maintain dogle ggolden Realm: 16 josh access annc.read sched.read annc.read annc.write sched.read sched.write maintain oliver ray Sakai 2.0 ANNC Sched ANNC Home
- 17. N1 N15 N16 N20 N17 N19 S15ANNC Sched G50 access G49 maintain access access G49 maintain N18 G50/TA G50/Learner maintain access Nodes and Grants in a Hierarchy G51 G52 G49 maintain G52/TA G52/Learner maintain access
- 18. N20 N17 G50 access G49 maintain G49 maintain G50/TA G50/Learner maintain access Flexible Inheritance N22 C91 C92 N23 C94 N21 C95 C93 N24 N26 G49maintain A007 A99 content.read content.write maintain G-Anon content.read
- 19. N20 N17 G50 access G49 maintain G49 G50/TA G50/Learner maintain access Non- Blockable (or admin) Grants N22 C91 C92 N23 C94 N21 C95 C93 N24 N26 G49 A007 A99 content.read content.write maintain G-Anon content.read G63maintain
- 20. N1 N15 N16 N20 N17 N19 S15ANNC Sched G50access G49 maintain access access N18 G50/TA G50/Learner maintain access “unBlockable in every way…” G51 G52 G52/TA G52/Learner maintain access G86 access G85 *.* G87 S11 ANNC Sched maintain
- 22. N15 N20 G50access G49 maintain access Can Agent A45 read Content Blob C93? G51 G86access N22 N29 C93A99 content.read A45
- 23. References • XACML Working Group – http://www.oasis-open.org/committees/tc_home.php? wg_abbrev=xacml • XACML 2.0 - Hierarchy and Roles – http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0- rbac-profile1-spec-os.pdf • IMS Enterprise – http://www.imsglobal.org/enterprise/entv1p1/imsent_infov1p1.html • WEBDAV Access Control – http://www.ietf.org/rfc/rfc3744.txt – http://webdav.org/specs/rfc3744.pdf
- 24. Appendix S - SQL Layout
- 25. Inheritance Table N15 N20 N17 N22 N23N29 SAKAI_INHERIT Child Parent Block N20 N15 B N17 N20 B N17 N15 B N22 N20 N N22 N15 B N29 N22 N N29 N20 N N29 N15 B N23 N22 B N23 N20 B N23 N15 B
- 26. Grant Table N15 N20 N17 G50 access G49 maintain G50/TA maintain G86access N22 N23N29 C95 A99 content.read C93 C94 * The grants are slightly changed from earlier examples to show more detail SAKAI_GRANTS Grantee Function or F-Set Node or Entity Blockable A99 content. read C93 Yes G50/TA maintain N17 Yes G50 access N20 Yes G40 maintain N20 No G86 access N15 Yes CONTENT_ENTITY GUID Node C94 N17 C94 N22 C95 N29 C93 N23
- 27. Looking for C93 SAKAI_GRANTS Grantee Function or F-Set Node or Entity Blockable A99 content. read C93 Yes G50/TA maintain N17 Yes G50 access N20 Yes G40 maintain N20 No G86 access N15 Yes CONTENT_ENTITY GUID Node C94 N17 C94 N22 C95 N29 C93 N23 SAKAI_INHERIT Child Parent Block N20 N15 B N17 N20 B N17 N15 B N22 N20 N N22 N15 B N29 N22 N N29 N20 N N29 N15 B N23 N22 B N23 N20 B N23 N15 B
- 28. Looking for C94 SAKAI_GRANTS Grantee Function or F-Set Node or Entity Blockable A99 content. read C93 Yes G50/TA maintain N17 Yes G50 access N20 Yes G40 maintain N20 No G86 access N15 Yes CONTENT_ENTITY GUID Node C94 N17 C94 N22 C95 N29 C93 N23 SAKAI_INHERIT Child Parent Block N20 N15 B N17 N20 B N17 N15 B N22 N20 N N22 N15 B N29 N22 N N29 N20 N N29 N15 B N23 N22 B N23 N20 B N23 N15 B
Editor's Notes
- 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.
- 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.
- Over time, tools will be redesigned and decisions will be made w.r.t. Whether or not the tool is to be section aware.
- 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.
- 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.
- 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?”
- 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.
- 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.
- 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.
- 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.
- 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.
- 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
- 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.
- 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.
- 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 :)
- 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.
- 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)
- This is not really SQL - it is an outline of the needed SQL.
- 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.
- 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”)
- 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.
- 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.