Sakai Hierarchy Framework Changes Overview Draft 09292005

1
Sakai Hierarchy Framework Changes OverviewDraft
- 09-29-2005

• Charles Severance
• csev_at_umich.edu

2
Relating Sections and Hierarchy
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
Annc
Message
Tool List Chat Info
File
Folder
File
The roster (realm) contains both membership and
permission information. The roster can be fed
externally or internally.
7
Sakai Site - 2.1 - Sections
Site EECS280
Sec A
Sec B
Roster
Annc
Message
Tool List Chat Info
File
Folder
File
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.
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
sites relationship with its parent.
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
EECS280
EECS280-LEC1
EECS280-LEC2
.. Up to Computer Science EECS280-LEC1
EEGS280-LEC2
Sites
11
Rolling up Hierarchy in a Tool
EECS280
EECS280-LEC1
EECS280-LEC2
Include schedule items from sub-sites in
schedule All sub-sites Depth
Options
Schedule
2
12
Implicit Hierarchy in a Tool
EECS280
EECS280-LEC1
EECS280-LEC2
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
Resources
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.

14
Framework Implementation Technical Details
15
Sakai 2.0
Announcement Manager
Calendar Manager
S15 S16
A1
A1 A2
Sched
A2
C2
C1
ANNC
A3
Thread ContextS15
Site Manager
S15
S16
Sched
Home
ANNC
ANNC
Realm 15
Realm 16
csev
josh
ggolden
ray
dogle
oliver
16
Grant Capabilities in 2.0
A30
S15
Sched
ANNC
A31
Grant Capabilities in 2.1
A30
A31
Student
S15
Sched
contextNode
ANNC
N20
A32
Student
G40
A33
annc.write
TA
A15
G50/TA
G50/Learner
17
Nodes and Grants in a Hierarchy
N1
G49
G50
maintain
access
N15
G51
access
N16
G52
N20
S15
access
Sched
ANNC
G49
G49
maintain
maintain
N17
N19
N18
G50/Learner
G52/Learner
access
access
maintain
G50/TA
maintain
G52/TA
18
FlexibleInheritance
G49
maintain
N20
G50
access
C92
G49
G-Anon
maintain
content.read
N17
N22
C91
G50/Learner
access
C93
G50/TA
maintain
C94
G49
N21
N23
maintain
C95
N26
N24
A007
content.read content.write
maintain
A99
19
Non-Blockable(or admin)Grants
G49
G63
maintain
maintain
N20
G50
access
C92
G49
G-Anon
content.read
N17
N22
C91
G50/Learner
access
C93
G50/TA
maintain
C94
G49
N21
N23
C95
N26
N24
A007
content.read content.write
maintain
A99
20
unBlockablein every way
N1
G86
G85
.
access
S11
Sched
G87
ANNC
G49
N15
maintain
G50
access
maintain
N16
G51
N20
S15
Sched
access
ANNC
access
G52
N17
N19
N18
G50/Learner
G52/Learner
access
access
maintain
G50/TA
maintain
G52/TA
21
Block-awareTransitive Closure
N15
N20
N17
N22
N23
N29
C93
A99
content.read
22
Can Agent A45 read Content Blob C93?
G86
A45
N15
access
G49
maintain
G50
access
N20
access
G51
N22
N29
C93
A99
content.read
23
References

• XACML Working Group
• http//www.oasis-open.org/committees/tc_home.php?w
  g_abbrevxacml
• XACML 2.0 - Hierarchy and Roles
• http//docs.oasis-open.org/xacml/2.0/access_contro
  l-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
26
Grant Table
The grants are slightly changed from earlier
examples to show more detail
27
Looking for C93
28
Looking for C94