{"_id":"5864d2e079ce642d00f0ff56","__v":0,"user":"5706dce42138ed0e0060f8ab","parentDoc":null,"version":{"_id":"5864d2df79ce642d00f0fec7","project":"56439dfe9eebf70d00490d54","__v":4,"createdAt":"2016-12-29T09:09:51.074Z","releaseDate":"2016-12-29T09:09:51.074Z","categories":["5864d2df79ce642d00f0fec8","5864d2df79ce642d00f0fec9","5864d2df79ce642d00f0feca","5864d2df79ce642d00f0fecb","5864d2df79ce642d00f0fecc","5864d2df79ce642d00f0fecd","5864d2df79ce642d00f0fece","5864d2df79ce642d00f0fecf","5864d2df79ce642d00f0fed0","5864d2df79ce642d00f0fed1","5864d2df79ce642d00f0fed2","5864d2df79ce642d00f0fed3","5864d2df79ce642d00f0fed4","5864d2df79ce642d00f0fed5","5864d2df79ce642d00f0fed6","5864d2df79ce642d00f0fed7","5864d2df79ce642d00f0fed8","5864d2df79ce642d00f0fed9","5864d2df79ce642d00f0feda","5864d2df79ce642d00f0fedb","5864d2df79ce642d00f0fedc","5864d2df79ce642d00f0fedd","5864d2df79ce642d00f0fede","598aa64f4b6e990019b7a2d2","599bc76bc03fa2000f83db2a","599bcc3c3c5bf7000f3434fc"],"is_deprecated":false,"is_hidden":false,"is_beta":true,"is_stable":true,"codename":"","version_clean":"2.0.0","version":"2"},"project":"56439dfe9eebf70d00490d54","category":{"_id":"5864d2df79ce642d00f0fedd","version":"5864d2df79ce642d00f0fec7","project":"56439dfe9eebf70d00490d54","__v":0,"sync":{"url":"","isSync":false},"reference":false,"createdAt":"2016-08-01T18:10:26.684Z","from_sync":false,"order":24,"slug":"lti-single-sign-on","title":"LTI Single Sign On"},"updates":[],"next":{"pages":[],"description":""},"createdAt":"2016-12-22T06:29:15.690Z","link_external":false,"link_url":"","githubsync":"","sync_unique":"","hidden":false,"api":{"results":{"codes":[]},"settings":"","auth":"required","params":[],"url":""},"isReference":false,"order":2,"body":"Whilst LTI® is not primarily designed as a SSO mechanism, some of the data it passes in a launch request are about the user. Moreover, LTI works on the basis of a trust relationship between the systems which is established by means of a key and a secret - much simpler than providing access to a common identity server.  In LTI a user is authenticated by a primary system (such as an LMS) and then can be passed to another system (internal or external) by way of a signed launch message.  The system receiving this message can verify its authenticity by inspecting the signature and then implicitly trust the data it carries; there is no need for the user to be authenticated a second time or for their identity to be checked against another system.  This approach can make LTI a low cost alternative to implementing SSO between systems.\n\n(Source: [Learning Tools Interoperability® as a SSO Mechanism](https://www.imsglobal.org/learning-tools-interoperability-sso-mechanism))\n\nThis section describes the data items that are passed as part of the POST data when a Basic LTI launch is performed.  Very few of the fields are technically required however Gooru LTI needs some fields to be present in the request.  Some fields in the launch request will be gathered for tracking and others may need highly detailed and precise information to perform high-stakes activities and reliably and securely return high-stakes results from those activities.\n\nConsumer systems should provide as much data as possible in each launch to maximize the chance that the Gooru LTI will have the data it needs to function properly. Consumer systems may have sandboxing features that limit the sending of certain Basic LTI data elements.  Gooru LTI is prepared to work with partial information – either because the consumer does not have the information or the consumer has been configured not to share the information with Gooru.\n[block:callout]\n{\n  \"type\": \"info\",\n  \"title\": \"Endpoints\",\n  \"body\": \"Production : http://ltisso.gooru.org/api/nucleus-lti/v1/launch\\nQA: https://nucleus-qa.gooru.org/api/nucleus-lti/v1/launch\"\n}\n[/block]\n\n[block:callout]\n{\n  \"type\": \"warning\",\n  \"body\": \"You need a `consumer_key` and `shared_secret` to be able to launch LTI request. Normally, this keys will be the same `client_id` and `client_key` provided by Gooru. You can contact support:::at:::gooru.org to obtain one.\",\n  \"title\": \"Consumer Key / Shared Secret\"\n}\n[/block]\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Launch Parameters\"\n}\n[/block]\n###lti_message_type=basic-lti-launch-request \n[Required]\nThis indicates that this is a Basic LTI Launch Message.  This allows a Gooru to accept a number of different LTI message types at the same launch URL.\n \n###lti_version=LTI-1p0\n[Required]\nThis indicates which version of the specification is being used for this particular message.\n\n###oauth_consumer_key=b289378-f88d-2929-lmsng.school.edu\n###oauth_signature_method=HMAC-SHA1\n###oauth_timestamp=1244834250\n###oauth_nonce=1244834250435893000\n###oauth_version=1.0\n###oauth_signature=Xddn2A%2BjzwjgBIVYkvigaKxCdcc%3D\nOAuth is a security mechanism designed to protect POST and GET requests.  This parameters only applies to protecting launch and other LTI messages that are being serialized and sent using POST. All parameters are required.\n\n###resource_link_id=class:<class_id>,unit:<unit_id>,assessment:<assessment_id>\n[Required]\nThis will be used to pass the class/content details from the consumer to Gooru LTI.\n\nRedirect base URLs will be manually configured in Gooru LTI DB based on the role of the user. Consumer need to provide the URL to which Gooru LTI will redirect from Launch request. Redirect URL should accept the content ids (e.g. class id, assessment id etc.) so that they can passed to player. This URL may contain placeholders for various ids what we need to pass to the player.\n E.g. https://nucleus-qa.gooru.org/player/$$assessment\nWhere, $$assessment is placeholder which will be replaced by actual assessment id received.\n\nGooru LTI will append ‘access_token’ to this URL which can be use to bring up the assessment/collection player for logged in user session. \n\n###launch_presentation_return_url=http://nucleus-qa.gooru.org/\n[Optional]\nThis URL is used in case of any issue in launch request.\n\n###lis_person_name_given=Jane\n###lis_person_name_family=Public\n###lis_person_contact_email_primary=user@school.edu\n[Optional]\n\nThese fields contain information about the user account that is performing this launch.  The names of these data items are taken from LIS. \n\n###roles=Instructor\n[Optional]\n\nA comma-separated list of URN values for roles.  If this list is non-empty, it should contain at least one role\n\n###user_id=0ae836b9-7fc9-4060-006f-27b2066ac545\n[Required]\n\nUniquely identifies the user.  This should not contain any identifying information for the user.  Best practice is that this field should be a TC-generated long-term “primary key” to the user record – not the “logical key\"\n\n###lis_result_sourcedid=83873872987329873264783687634\n[Optional]\n\nThis field contains an identifier that indicates the LIS Result Identifier (if any) associated with this launch. This field should be present in order to receive the score back to the consumer via Outcomes.  \n\n###tool_consumer_instance_guid=lmsng.school.edu\n[Optional]\n\nThis is a unique identifier for the TC.  A common practice is to use the DNS of the organization or the DNS of the TC instance.  If the organization has multiple TC instances, then the best practice is to prefix the domain name with a locally unique identifier for the TC instance.\n\n###tool_consumer_instance_name=SchoolU\n[Optional]\n\nThis is a user visible field – it should be about the length of a column.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Launch Responses\"\n}\n[/block]\nThis section captures the details on various responses that LTI launch request can send.\n[block:callout]\n{\n  \"type\": \"success\",\n  \"title\": \"ON Success\",\n  \"body\": \"On successful launch request processing, API will return `HTTP Response 303 - See Other` with proper redirect URL in `Location` header\\nRedirect URL will be formed based on the `launch_presentation_return_url` present in the request by replacing proper parameters in the URL. Gooru LTI will also append `access_token` URL parameter to the return URL which denotes the logged in user.\"\n}\n[/block]\n\n[block:callout]\n{\n  \"type\": \"danger\",\n  \"title\": \"ON Failure\",\n  \"body\": \"In case of failure to process the launch request, API will return `HTTP Response Code 303 - See Other` with proper redirect URL in `Location` header.\\nRedirect URL will be formed by adding a parameter called `lti_errormsg` that includes some detail as to the nature of the error.  The `lti_errormsg` value should make sense if displayed to the user.  If the tool has displayed a message to the end user and only wants to give the consumer a message to log, use the parameter `lti_errorlog` instead of `lti_errormsg`.\"\n}\n[/block]","excerpt":"This page contains details about LTI Launch request.","slug":"lti-launch","type":"basic","title":"LTI Launch"}

LTI Launch

This page contains details about LTI Launch request.

Whilst LTI® is not primarily designed as a SSO mechanism, some of the data it passes in a launch request are about the user. Moreover, LTI works on the basis of a trust relationship between the systems which is established by means of a key and a secret - much simpler than providing access to a common identity server. In LTI a user is authenticated by a primary system (such as an LMS) and then can be passed to another system (internal or external) by way of a signed launch message. The system receiving this message can verify its authenticity by inspecting the signature and then implicitly trust the data it carries; there is no need for the user to be authenticated a second time or for their identity to be checked against another system. This approach can make LTI a low cost alternative to implementing SSO between systems. (Source: [Learning Tools Interoperability® as a SSO Mechanism](https://www.imsglobal.org/learning-tools-interoperability-sso-mechanism)) This section describes the data items that are passed as part of the POST data when a Basic LTI launch is performed. Very few of the fields are technically required however Gooru LTI needs some fields to be present in the request. Some fields in the launch request will be gathered for tracking and others may need highly detailed and precise information to perform high-stakes activities and reliably and securely return high-stakes results from those activities. Consumer systems should provide as much data as possible in each launch to maximize the chance that the Gooru LTI will have the data it needs to function properly. Consumer systems may have sandboxing features that limit the sending of certain Basic LTI data elements. Gooru LTI is prepared to work with partial information – either because the consumer does not have the information or the consumer has been configured not to share the information with Gooru. [block:callout] { "type": "info", "title": "Endpoints", "body": "Production : http://ltisso.gooru.org/api/nucleus-lti/v1/launch\nQA: https://nucleus-qa.gooru.org/api/nucleus-lti/v1/launch" } [/block] [block:callout] { "type": "warning", "body": "You need a `consumer_key` and `shared_secret` to be able to launch LTI request. Normally, this keys will be the same `client_id` and `client_key` provided by Gooru. You can contact support@gooru.org to obtain one.", "title": "Consumer Key / Shared Secret" } [/block] [block:api-header] { "type": "basic", "title": "Launch Parameters" } [/block] ###lti_message_type=basic-lti-launch-request [Required] This indicates that this is a Basic LTI Launch Message. This allows a Gooru to accept a number of different LTI message types at the same launch URL. ###lti_version=LTI-1p0 [Required] This indicates which version of the specification is being used for this particular message. ###oauth_consumer_key=b289378-f88d-2929-lmsng.school.edu ###oauth_signature_method=HMAC-SHA1 ###oauth_timestamp=1244834250 ###oauth_nonce=1244834250435893000 ###oauth_version=1.0 ###oauth_signature=Xddn2A%2BjzwjgBIVYkvigaKxCdcc%3D OAuth is a security mechanism designed to protect POST and GET requests. This parameters only applies to protecting launch and other LTI messages that are being serialized and sent using POST. All parameters are required. ###resource_link_id=class:<class_id>,unit:<unit_id>,assessment:<assessment_id> [Required] This will be used to pass the class/content details from the consumer to Gooru LTI. Redirect base URLs will be manually configured in Gooru LTI DB based on the role of the user. Consumer need to provide the URL to which Gooru LTI will redirect from Launch request. Redirect URL should accept the content ids (e.g. class id, assessment id etc.) so that they can passed to player. This URL may contain placeholders for various ids what we need to pass to the player. E.g. https://nucleus-qa.gooru.org/player/$$assessment Where, $$assessment is placeholder which will be replaced by actual assessment id received. Gooru LTI will append ‘access_token’ to this URL which can be use to bring up the assessment/collection player for logged in user session. ###launch_presentation_return_url=http://nucleus-qa.gooru.org/ [Optional] This URL is used in case of any issue in launch request. ###lis_person_name_given=Jane ###lis_person_name_family=Public ###lis_person_contact_email_primary=user@school.edu [Optional] These fields contain information about the user account that is performing this launch. The names of these data items are taken from LIS. ###roles=Instructor [Optional] A comma-separated list of URN values for roles. If this list is non-empty, it should contain at least one role ###user_id=0ae836b9-7fc9-4060-006f-27b2066ac545 [Required] Uniquely identifies the user. This should not contain any identifying information for the user. Best practice is that this field should be a TC-generated long-term “primary key” to the user record – not the “logical key" ###lis_result_sourcedid=83873872987329873264783687634 [Optional] This field contains an identifier that indicates the LIS Result Identifier (if any) associated with this launch. This field should be present in order to receive the score back to the consumer via Outcomes. ###tool_consumer_instance_guid=lmsng.school.edu [Optional] This is a unique identifier for the TC. A common practice is to use the DNS of the organization or the DNS of the TC instance. If the organization has multiple TC instances, then the best practice is to prefix the domain name with a locally unique identifier for the TC instance. ###tool_consumer_instance_name=SchoolU [Optional] This is a user visible field – it should be about the length of a column. [block:api-header] { "type": "basic", "title": "Launch Responses" } [/block] This section captures the details on various responses that LTI launch request can send. [block:callout] { "type": "success", "title": "ON Success", "body": "On successful launch request processing, API will return `HTTP Response 303 - See Other` with proper redirect URL in `Location` header\nRedirect URL will be formed based on the `launch_presentation_return_url` present in the request by replacing proper parameters in the URL. Gooru LTI will also append `access_token` URL parameter to the return URL which denotes the logged in user." } [/block] [block:callout] { "type": "danger", "title": "ON Failure", "body": "In case of failure to process the launch request, API will return `HTTP Response Code 303 - See Other` with proper redirect URL in `Location` header.\nRedirect URL will be formed by adding a parameter called `lti_errormsg` that includes some detail as to the nature of the error. The `lti_errormsg` value should make sense if displayed to the user. If the tool has displayed a message to the end user and only wants to give the consumer a message to log, use the parameter `lti_errorlog` instead of `lti_errormsg`." } [/block]