[Building Sakai] Hybrid

Ian Boston ieb at tfd.co.uk
Thu Mar 10 06:57:00 PST 2011


On 10 Mar 2011, at 11:19, N. Matthijs wrote:

> Hi everyone,
> 
> I'm sure you've all seen in the v1 plan that the ability to
> embed an S2 tool inside of an S3 page is part of what
> we're trying to deliver by June. The design team is already
> creating designs for how to select a tool to embed, and I'm
> now trying to get an idea of how much technical work still
> needs to happen in this area (SAKIII-541).
> 
> As far as I understand, basic LTI already gives us the ability
> to embed a tool inside of Sakai 3. However, for this to actually
> work, we also have to synchonize membership and roles
> between S3 worlds and S2 (ghost) sites, which is something
> that hasn't been done so far.
> 
> First of all, is this understanding correct or do we need to do
> more/less work than what I described. Secondly, does
> someone have a good idea of how long it would take to do
> this remaining work?

This is hard
Some of the issues.
Permissions in Sakai 2 are represented as functions on individual tools, a role is a configuration of those functions and a role is given a symbolic name
Membership in Sakai 2 is a member of a role in a realm (group)

In Sakai OAE permissions are represented as Access Control Lists applied to content, operations on that content being performed by the tool. 
A role is a symbolic name representing the association between a user or group and the world (using new terminology)

So to make this work you will need.
1. A template in Sakai2 that matches the functions and roles of users in Sakai OAE
2. When a Tool is placed in Sakai OAE, Sakai OAE will need to create a site using that template.
3. For each role in the Sakai OAE find all the users, expanding all the groups to get to all the users and add those users as direct members of the Sakai 2 site.

thats the setup

when and of the groups (or groups that the groups are a member of ) changes, you need to synchronise the entire memberships list on the Sakai 2 site.


Its the update step that is going to be painful and hard to code, since on every group update we will need to traverse all connected authorizables and then update all sites where they are mentioned which could in some cases be most of the Sakai 2 sites in the system, ghost or otherwise. At places like UI I will guess thats into the 10Ks of sites so expect a Group membership update to become rather expensive, and impractical.


--------------------------

An alternative approach is not to update membership and get the servers to trust each other including the trust that if Sakai OAE says the request is from User X for Site A on the Sakai 2 instance, then the Sakai 2 instance believes that and does not need User X to explicitly be a member of Site A on the Sakai 2 instance. We had a patch at cambridge that allows this pattern about 4 years ago (non listed dynamic group membership based on authentication attributes), and there might be something similar in the current Sakai 2 release. It required modification to the Realms SQL.

Ian

> 
> Thanks in advance,
> Nicolaas
> 



More information about the sakai-dev mailing list