Uploaded image for project: 'Sakai'
  1. Sakai
  2. SAK-24188

Support clean passthrough of user and site credentials from a trusted consumer

    Details

    • Type: Task
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: BasicLTI
    • Labels:
      None

      Description

      An email I sent to Chuck Severance about the proposed feature:
      -----------------------------

      I'm working on an integration between uPortal and Sakai, in that a portlet on the uPortal end can make a request to Sakai and render the Sakai tool in uPortal.

      However, in order for this to fully work, I need the information about userId's and sites to be untouched, so that a user in uPortal can launch a tool in a site that they choose. At present, on first request, a new user and a new site is created, prefixed with the oauth_consumer_key, eg my.anu.edu.au:292832126.

      For instance;

      In Sakai:

      eid=steve
      userId=0cec13cb-3999-47d7-81f7-78582ffa4aa9
      siteId=9ec48d9e-b690-4090-a300-10a44ed7656e

      In uPortal:
      eid=steve
      The user would then set/choose the siteId and select the tool (get this info via web service calls)
      There would be another web service call to get the userId from Sakai or just send the eid in the request, although the spec says it shouldn't contain identifying information, but I am not sure this matters a great deal over SSL.

      I'm happy to make changes to the Basic LTI ProviderServlet in Sakai to support this, and it would be in a way that doesn't impact the existing functionality. I am thinking perhaps an additional parameter in the POST request that tells the servlet not to modify the incoming information if that parameter is present. I will then submit the modifications as patches.

      That way we can achieve a full integration between uPortal and Sakai, sharing user's and sites. This will make the uPortal a bit Sakai specific, but I think thats ok in order for us to achieve a nice integration.

        Gliffy Diagrams

          Attachments

            Issue Links

              Activity

                People

                • Assignee:
                  steve.swinsburg Steve Swinsburg
                  Reporter:
                  arwhyte Anthony Whyte
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  1 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved:

                    Git Source Code