xAPI & OAuth

[Handorf, Chris]

Hello xAPI Spec enthusiasts!

I have been studying the xAPI spec as well as the LMS launch document at:

https://github.com/RusticiSoftware/launch/blob/master/lms_lrs.md

I think I understand both in great detail now but I am very stuck on the OAuth part.  

Assume I am working with the following 2 URLS:

http://lms.com/activity.html      /* a Tin Can content object sitting on an LMS */

http://lrs.com                          /* the LRS */

I also have a user, Sally Glider, that has an account on both the LMS and LRS.

I want Sally to be able to log into the LMS, click a link to launch the activity,

and I want that activity to be able to record Statements in the LRS.  The LMS and LRS

have a trusted relationship and maybe Sally's credentials are even the same for both.  

This would be easy to do with HTTP Basic Auth assuming the LMS knows Sally's

credentials for the LRS.  After Sally logs into the LMS the LMS would provide a link for 

her to click on that looks like this:

http://lms.com/activity.html

      ?endpoint=http://lrs.com

      &actor={ "name" : ["Sally Glider"], "mbox" : ["mailto:sa...@glider.com"] }

      &auth=Basic%20c2FsbHk6bG92ZXNHbGlkZXJz       

      

However, I don't see this is a viable solution for an enterprise LMS because this

URL will appear in a web browser's history or in other network log files and it

is all too trivial to decode the above token and determine that Sally's LRS credentials

(and maybe her bank account too) are "sally" / "lovesGliding".  This isn't acceptable

security for an enterprise LMS.

So I assume I need to use OAuth here.  The launch document has this to say:

    "If the activity being launched has an associated registered OAuth application 

     with the LMS, the LMS should not include an “auth” parameter in the launch link. 

     The Activity Provider / OAuth application is expected to authenticate using OAuth, 

     which may involve asking the learner to re-authenticate."

     

So the LMS provides Sally with an activity link with no auth token:

http://lms.com/activity.html

      ?endpoint=http://lrs.com

      &actor={ "name" : ["Sally Glider"], "mbox" : ["mailto:sa...@glider.com"] }

Sally clicks on that link and the Activity is loaded into her web browser and is ready

to send Statements to the LRS.  What happens next?  What is the workflow at this 

point?  How does the activity code that is running in Sally's browser establish an OAuth authenticated session with the LRS so it can securely store Statements there?  Does it 

call OAuth service endpoints on the LRS?  Does it instead make a call to the LMS to 

obtain a token?  If so how does it even know what the LMS URL is because the 

activity.html file might even live outside the LMS on a different server?  Sally is already 

logged into the LMS so hopefully no re-authentication is necessary. The picture is very 

blurry for me here.  Can anyone provide guidance?

Many thanks in advance.

Chris Handorf

Mobile Solutions Development Manager

Pearson Inc. 3075 W. Ray Rd., Suite 200, MS/405

Chandler, AZ 85226

Office: 480-457-6185

Cell:   480-766-9977

[Andrew Downes]

Hi Chris,
This is exactly the issue I've been looking at myself recently so I'll post a full answer later.

For now a question - is your activity using client side or server side tracking?

Andrew

[Ben Clark]

Hi Chris,

Some very similar questions recently came up on stack exchange, please have a look and see if this helps.

On OAuth: http://stackoverflow.com/questions/24195947/best-practice-with-tincan-lrs-lms-launching-and-oauth/24212579#24212579

On a better way to use Basic Auth: http://stackoverflow.com/questions/24235539/tin-can-launch-auth-parameter/24250425#24250425

Thanks,

-Ben

To unsubscribe from this group and stop receiving emails from it, send an email to xapi-spec+...@adlnet.gov.

[Handorf, Chris]

Thank you for the links Ben.  I will look through them more today but I can already see that Basic Auth could use a token rather than username/password.

Andrew, in response to your question all of my Activities are using client side tracking so the Statements are originating from the web browser and will ideally be sent directly to the LRS (not through the LMS).  I'm looking forward to your full answer.

Chris Handorf

Mobile Solutions Development Manager

Pearson Inc. 3075 W. Ray Rd., Suite 200, MS/405

Chandler, AZ 85226

Office: 480-457-6185

Cell:   480-766-9977

[Dave Smith]

I got teased (lightly) at last week’s xAPI event in Orlando for lamenting about the fact that all the “good stuff” that is being done with the xAPI is all being done in JavaScript. To that end, I will ask that question in this thread.

 

Chris, since your scenario has the user logging into and launching the activity from the LMS, why do you feel it is necessary to track that event from the web browser. If the activity reports back to the LMS, and the LMS tracks that action to the LRS, then the whole problem of client-side authentication to the LRS is avoided.

 

I was just wondering…

 

Dave Smith

Brindle Waye

[Handorf, Chris]

Hi Dave,

You're right it would be possible for the Activity to send Statements back to the LMS to verify Session information and then have the LMS send the Statement on to the LRS perhaps using its own credentials when updating the LRS.

However, I wanted to avoid that situation for a few different reasons.  First it would be additional load on the LMS (which could already be supporting millions of users).  Also, I still really like the "S" part of SCORM which is Shareable so I want to make sure that any Activity I create would play nicely on any LMS supporting Tin Can.  I wasn't sure that I could count on every LMS supporting this approach (I guess if the LMS passes the endpoint it could always make the endpoint itself?).  Finally, an Activity could actually be generating Statements for multiple LRSs simultaneously.  A student might want Statement data sent not only to the preferred LRS of the LMS, but also to an external personal LRS.

After using SCORM for a few years I like the thought of wrestling the data away from the LMS as much as possible.

Chris Handorf

Mobile Solutions Development Manager

Pearson Inc. 3075 W. Ray Rd., Suite 200, MS/405

Chandler, AZ 85226

Office: 480-457-6185

Cell:   480-766-9977

[Andrew Downes]

Hi Chris,
This is an area I've been looking into myself and the conclusion I've come to (with a little help Russell and Ben) is that OAuth is the wrong approach for client side JavaScript tracking. If you must track client side, the goal is to make Basic authentication as secure as possible, whilst accepting that whatever you do, you have to provide the credentials to the client. Client side tracking isn't for anything high stakes.

The approach I'm looking at is that the LMS would interact with the LRS directly server side. It'll send certain information about the learner such as language preference and store a list of active attempts. At the point of launch, it will use its own credentials to request a fresh set of credentials from the LRS for each launch. These credentials will have restricted permissions and an expiry date, so if/when they do fall into the wrong hands, the scope of the damage is limited.

I've made a start at implementing this in learning locker and created a test client here:

https://github.com/garemoko/learninglocker/tree/multi-cred-api

https://github.com/garemoko/basic_credentials_example_client

Andrew

"Handorf, Chris" <chris....@pearson.com> wrote:

[Russell Duhon]

Hi Chris,

Part of this is the minimal nature of the existing launch spec (which I want to emphasize isn't actually part of the actual Experience API specification -- the launch 'spec' is already effectively about a half-dozen half-interoperable minor variants among the different authoring tools due to interpretation/implementation differences that make it hard to consistently launch content).

It would definitely be possible to create a launch spec that brings security in line with to better than SCORM and does not require the server exec any package code (though it would require server side processing). The main move required is a switch to statement templates in the config, which the content then references (possibly with some simple operators for tokens sent from the client to fill in booleans and whatnot and reduce the needed number of templates). So instead of saying anything about success or failure, the client would just send one or a small number of opaque tokens to the server, which would send statements on that basis.

It could even be arranged to avoid using the LMS as a channel (and bypass the load issues) if there was an out of band API also specified for server to LRS communication to set everything up. Then you'd need an LRS and launching server (I'm intentionally not saying LMS) that both understood how to behave, but you'd avoid another problem (as you've identified).

Really, there's a huge opening for someone to create a rapid authoring tool that adheres to a secure, portable launching mechanism for Experience API content. I bet you'd get a number of LMSs and other systems to play, what with how problematic the current launching options are (and sadly CMI5 so far doesn't make inroads on the real issues).

To return to the present, yes, today it is not possible to use rapid authoring tools to create Experience API content that is both portable and secure. I'd be interested in participating in efforts to change that, but there'd need to be a broad group of participants for it to work (or a really, really good spec).

Sincerely,
Russell Duhon
CTO, Saltbox
Makers of WaxLRS

[Andrew Downes]

The templates idea sound interesting Russell, though my understanding of what you're saying seems to be over complex and adding an extra system. It may well be that I'm misunderstanding you though. Attached is a diagram to illustrate my understanding. Let me know where I've misunderstood!

[Russell Duhon]

Hi Andrew,

No, the communication would happen with the LMS/launching server. Or, with the addition of a small number of APIs for trust exchange between LMS and LRS it should be possible to make it so all content communication is with the LRS (except for an initial setup call or two with the LMS), just as it is now (but using special APIs for statements instead of core Experience API, that proxy into the core Experience API).

Sincerely,
Russell

On Thu, Jun 26, 2014 at 2:03 PM, Andrew Downes <mrdo...@hotmail.com> wrote:

The templates idea sound interesting Russell, though my understanding of what you're saying seems to be over complex and adding an extra system. It may well be that I'm misunderstanding you though. Attached is a diagram to illustrate my understanding. Let me know where I've misunderstood!

[Andrew Downes]

And for completeness, here's a diagram of what i was suggesting above. 

[Andrew Downes]

Ok so it sounds like actually your 'all content comms with the LRS' option is very similar to the 2nd diagram I posted?

Or do you mean something more like the attached? 

[Russell Duhon]

Yes, it's similar to the 2nd one you posted, it just preserves flexibility in statement content (the content can talk about any activities it wants) while adding more security over it (it isn't possible to just change success false to success true and maybe tweak a score value, as all that's handled server-side).

Cheers,

Russell

On Thu, Jun 26, 2014 at 2:16 PM, Andrew Downes <mrdo...@hotmail.com> wrote:

Ok so it sounds like actually your 'all content comms with the LRS' option is very similar to the 2nd diagram I posted?

Or do you mean something more like the attached? 

To unsubscribe from this group and stop receiving emails from it, send an email to xapi-spec+...@adlnet.gov.

[Andrew Downes]

hmm...very interesting. 

I wonder if there's any tie in between templates and the recipes concept. 

[Handorf, Chris]

I went dark for a few days to catch up on some work and digest the CMI-5 spec as well as some of the responses I received.  Andrew, your 2nd diagram is interesting.  The LRS and LMS have a trusted relationship, the LMS requests a token from the LRS and passes it to the JS Activity.

A couple of comments on this:

• An activity could easily generate multiple statements so rather than a single use token maybe a session token might be more useful? (but it open a larger potential security issue)
  
• There could be some problems with keeping an LRS Session and LMS Session in sync (like what if the LRS session times out while the LMS session is still valid?).

My thoughts seem to be going back to routing all Statements back through the LMS for security.  What I really hate about this is it is feeling like SCORM all over again.  The LMS owns the data not the Learner.  The LRS could even be hidden behind a firewall where the learner couldn't get to it.

I'm looking forward to hearing the discussion in tomorrow's meeting.  

Chris Handorf

Mobile Solutions Development Manager

Pearson Inc. 3075 W. Ray Rd., Suite 200, MS/405

Chandler, AZ 85226

Office: 480-457-6185

Cell:   480-766-9977

On Thu, Jun 26, 2014 at 2:23 PM, Andrew Downes <mrdo...@hotmail.com> wrote:

hmm...very interesting. 

I wonder if there's any tie in between templates and the recipes concept. 

To unsubscribe from this group and stop receiving emails from it, send an email to xapi-spec+...@adlnet.gov.

[Andrew Downes]

Hi Chris,

Thanks for your thoughts on this. I don't kbow that much about cookies myself but it sounds like an interesting idea. My main concerns with cookies are:

1. Legal restrictions in Europe on use of cookies could be annoying.

2. The main authoring tools currently look for credentials and user data in the query string. It might be challenging to get them to change and even if we can, there will already be content made in the current tools.

I'm very open to hear arguments why cookies are better than query string though.

On single use - I didn't mean single statement, but single launch. These credentials might be valid for a particular set of actors, verbs and activity ids and have a set expiry timestamp. What I envisage is that the person setting up the course in the LMS will choose a duration for the credentials to expire after when setting up each course. They will need to balance security with usability when setting these up.

I don't think I'm going to make it onto the call today, but I'm not too sure what's going to happen today so we shall see! I hope it's a helpful discussion anyway.

Andrew