[Building Sakai] QWuick question about basic lti

[Charles Severance]

Just as a follow up, I decided that we should not even send this value on all BLTI launches - so I created a JIRA to make it so ext_sakai_session is only sent when requested.

https://jira.sakaiproject.org/browse/BLTI-211

See the JIRA for details.

/Chuck

On Feb 15, 2013, at 10:48 AM, Charles Severance wrote:

> In general, the reason for
> 
> ext_sakai_session
> 
> Was to give folks using link tool and SakaiSigning.jws a path forward to convert away from LinkTool based tools to Basic LTI.  LinkTool signed session's approach security is weaker than LTI faced with a man-in-the-middle attack (which is rare but worrisome).  So we as a community should move away from LinkTool and move away from signed sessions and SakaiSigning.jws.
> 
> So as folks have said, how you use it is only documented in the LinkTool documentation.
> 
> It was never intended as a general purpose capability that was part of LTI - just a transition crutch to let people move from LinkTool. 
> 
> I would not expect any future LTI directions in services to follow the LinkTool pattern at all - if we build new services they will behave more like this:
> 
> https://source.sakaiproject.org/svn/basiclti/trunk/basiclti-docs/resources/docs/sakai_basiclti_api.doc
> 
> LTI tends not to support a model of "act as user while a session is active" but prefers a model of "acts as site owner within an approved context (course) irrespecitve of the presence of a session".  A model of "acts as user for the duration of a limited life session" is generally pretty weak (and is the foundation of OAuth 2.0):
> 
> http://vimeo.com/52882780  (warning: this video contains expletives and is not family friendly)
> 
> Three-legged OAuth 1.0 (as practiced by the Oxford mobile portal) supports a model of "Acts as user until token is revoked" - and this work well too.  But LTI is moving increasingly towards the "acts as site owner in contexts where permission is granted".
> 
> Probably more than you wanted to know - but the ideas is that ext_sakai_session is *not* the future - it is from the past.
> 
> /Chuck
> 
> On Feb 14, 2013, at 5:17 PM, Matthew Jones wrote:
> 
>> More specifically, it uses a hex encoded blowfish cipher encrypted on the secretKey which is auto generated when the server comes up in the sakai.home/sakai.rutgers.linktool.privkey file.
>> 
>> However the questions was asked and never answered about why this was still used. I think the question about sending a (separate) session id encrypted with the key that is exchanged makes sense to me.
>> http://old.nabble.com/-Building-Sakai--basic-lti-and-sakai-session-id-tt32511936.html#a32511936
>> 
>> For linktool, you had to use the SakaiSigning.jws webservice to get the real session id. Which really isn't always convenient, unless you control the end point.
>> https://source.sakaiproject.org/svn/linktool/trunk/linktool.txt
>> https://confluence.sakaiproject.org/display/CONF06/Linking+External+Tools+with+Sakai
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20130218/5ccc98b2/attachment.html