- 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.
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.
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.