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

Fri Mar 11 14:28:29 PST 2011

This is what I was referring to in my original email about web services.

a. can be accomplished via web services and recreating the site structure as a 'world'.
b. can be accomplished via Basic LTI launches to each tool in that site.

regards,
Steve

On 12/03/2011, at 6:47 AM, Speelmon, Lance wrote:

> I believe your description of #a is what came out of sprint 101:
> https://confluence.sakaiproject.org/display/3AK/Backlog+5+Summary+--+The+ability+to+see++and+access+Sakai2+sites+from+within+Sakai3
> 
> If so, then #a has no reliance on LTI whatsoever and no provisioning concerns - so I think we can remove that part of the discussion from the table.
> 
> The only place where LTI gets involved is in #b.  From IU's perspective, #a is far more important in the near term than #b (and I think that is what I hear Oliver saying as well).  Thanks, L
> 
> 
> On Mar 11, 2011, at 2:16 PM, Ian Boston wrote:
> 
>> I will have to defer to those who really know what use case we are trying to solve, although I was under the impression that it was the ability to 
>> 
>> a) present a Sakai 2 site as World (to use the new terminology) in OAE
>> and
>> b) present a Sakai 2 tool as a widget in OAE.
>> 
>> IIUC you are saying a) cant be done with LTI, but b) can provided there are no more than 2 roles.
>> 
>> Could someone who knows exactly what the requirements from the URG and stakeholders are on this issue comment ?
>> Alan, Nico, John or anyone from the URG ?
>> 
>> ----
>> 
>> I accept you analysis of risk mitigation, but if it doesn't do what the users want, then risk mitigation becomes moot, so I think we should really get the requirements clear first.
>> Ian
>> 
>> On 11 Mar 2011, at 19:02, Speelmon, Lance wrote:
>> 
>>> So #1 means that *practically* speaking, the only way to access the tools would be via the OAE lti consumer widget.  Primarily because the user would not know their eid or their password to log into the S2 portal.
>>> 
>>> The reason I think this may be acceptable for pilots is:
>>> 
>>> A) The use case that drives us LTI in the first place is one where we are mixing and matching OAE widgets and S2 tools on the same OAE page - this means you are now *relying* on OAE to deliver functionality and risk mitigation may be moot at this point.  That is if OAE were down, being able to access one or two S2 tools via S2 portal may not have enough value on their own.
>>> 
>>> B) Where risk mitigation is critical for pilots, they will be using the OAE portal to front-end S2.  Now being able fail-over to the S2 portal does have a lot of value and is a viable fallback (e.g. with similar skins casual users might not even notice that they have fallen back to the S2 portal because the site presentation is so similar).
>>> 
>>> C) The places where LTI-auto-provisioned sites will not suit our needs is when for example when an SIS/ERP system needs to pull in final grades from the GB. Making sure the SIS key matches to a S2 site becomes important.  While critically important in full production, I wonder how many pilots will be concerned with this use case.  (Thinking out loud, but we might even be able to solve this matching case with a site property or other similar way...)
>>> 
>>> D) The other place where LTI-auto-provisioned will not suit is when deployments require more than two S2 site roles.  Again, I would to test the assertion that pilot deployments will not need this level of sophistication.  WDYT?
>>> 
>>> Thanks, L
>>> 
>>> 
>>> On Mar 11, 2011, at 11:59 AM, Ian Boston wrote:
>>> 
>>>> 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.
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 
> 
> -- 
> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20110312/7f43692e/attachment.html 