[Building Sakai] [sakai-nakamura] Re: Hybrid

[Ian Boston]

I dont think I quite understand 1

Does 1 mean that the *only* way a OAE based user could access a S2 Tool would be if it had been provisioned as a BLTI launch, and that it would not be possible for an OAE user to access a OAE page that displayed all the tools from a S2 Site as the site was configured ?

If BLTI only allows a user to launch an individual tool from the remote system, then I dont think (IIUC) that it covers the use case required, but I could so easily be wrong.
Ian

On 11 Mar 2011, at 15:56, Speelmon, Lance wrote:

> What Ian said about provisioning is right and will be needed as an institution gets closer to a production hybrid implementation. However we do have an alternative for this sprint if we want to use it.  The S2 basiclti provider performs auto-provisioning of sites, users, and roles on demand if we do not put it into trusted mode.  This would mean:
> 
> 1) The ability for users to access S2 tools through either the OAE portal *OR* the S2 portal would be lost (i.e. the lti auto-provisioned users could only access S2 tools through the OAE basiclti widget placements). 
> 
> 2) LTI supports two roles, instructor and student, and the OAE LTI service needs to be able to accurately determine to which role the current user should be assigned. There is a TODO in the code for this and IIRC the only outstanding TODO for OAE's LTI consumer to be fully compliant with spec.
> 
> IMHO, these might be the right compromises to make now as it would support pilot activities well.  We would still need to deal with the trusted mode / non-LTI-auto-provisioned case, but might be better slotted for a future time period.  WDYT?  L
> 
> On Mar 10, 2011, at 7:57 AM, Ian Boston wrote:
> 
>> 
>> 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
>>> 
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups "Sakai Nakamura" group.
>> To post to this group, send email to sakai-kernel at googlegroups.com.
>> To unsubscribe from this group, send email to sakai-kernel+unsubscribe at googlegroups.com.
>> For more options, visit this group at http://groups.google.com/group/sakai-kernel?hl=en.
>> 
>