[Building Sakai] QWuick question about basic lti

[Charles Severance]

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/20130215/699c6413/attachment.html