Work on the tool and platform side separately first, make sure they are minimally functional independently of each other.
Tool Side
[x] Accept a launch from the LTI Reference Implementation platform.
[x] First stage of the launch is the login stage, verify that required parameters are present and return a 400 error if not. More complicated error checking can be implemented later.
[x] Second stage of the launch is the authentication request, get the parameters that needs to be sent back to the platform listed in a form on a page. User has to manually click the submit button to proceed to the next step.
[x] Third stage of the launch is the authentication response. Simply validate that required parameters are present for now. A more thorough id_token validation can be implemented later.
Note: Completed but has hardcoded values that would only work with my RI platform instance.
[x] First stage: login, a basic form that submits the required parameters to the tool, user has to click the submit button to proceed.
[x] Second stage: authentication request, an endpoint that receives the authentication request from the tool, validates it for required parameters, and then proceed to the third stage.
[x] Third stage: authentication response, generate a signed id_token using hardcoded RSA keys and again, use a form to submit the response back to the tool.
Note: Something is broken with the RI tool and it has really unhelpful error messages, so I've replaced it with the example tool for development.
Combined Version
Unify the tool and platform side together so that when the tool side receives a launch, it also tells the platform side to send out a launch. This combines the two sides together to act like a transparent proxy.
[x] Replace hardcoded values used previously with configurable values.
[x] Use the shim to bridge between a Reference Implementation platform and the Reference Implementation tool example tool.
Filtered Version
Adds data filtering so that the launch's data is transformed when it passes from the tool side to the platform side. This completes prototype1.
[x] Create a filtering system that specifies what kinds of transformations needs to be done on the params sent on each request.
[x] Implement actual nonce security checking. This involves CSRF protection that uses cookies which would involve #2 but if we somehow can use html5 storage instead, might be able to circumvent that. OWASP notes that signed/encrypted JWT is sufficient for CSRF protection, so we don't have to worry about this.
Initial Skeleton
Work on the tool and platform side separately first, make sure they are minimally functional independently of each other.
Tool Side
id_tokenvalidation can be implemented later.Note: Completed but has hardcoded values that would only work with my RI platform instance.
Platform Side
LTI Reference Implementation toolLTI php example tool.id_tokenusing hardcoded RSA keys and again, use a form to submit the response back to the tool.Note: Something is broken with the RI tool and it has really unhelpful error messages, so I've replaced it with the example tool for development.
Combined Version
Unify the tool and platform side together so that when the tool side receives a launch, it also tells the platform side to send out a launch. This combines the two sides together to act like a transparent proxy.
Reference Implementation toolexample tool.Filtered Version
Adds data filtering so that the launch's data is transformed when it passes from the tool side to the platform side. This completes prototype1.
This involves CSRF protection that uses cookies which would involve #2 but if we somehow can use html5 storage instead, might be able to circumvent that.OWASP notes that signed/encrypted JWT is sufficient for CSRF protection, so we don't have to worry about this.