refs INTEROP-7575
flag=none
--------------------------------------------------
Test plan
--------------------------------------------------
* go to the Developer Keys page
* click on "+ LTI Key"
* find the "LTI Advantage Services" section
* the Canvas Data Services permissions should not appear
Change-Id: Ie6cf84a214e0fec019daaabb2cc8c1565f9305b6
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/299644
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Xander Moffatt <xmoffatt@instructure.com>
QA-Review: Xander Moffatt <xmoffatt@instructure.com>
Product-Review: Alexis Nast <alexis.nast@instructure.com>
If a developer key is given a scope (meaning that it only works
on some API endpoints), and then the route for one of those endpoints
is changed, this causes a problem for the developer key. So, we want
to prevent that. This will force that change to be more intentional.
flag=none
refs INTEROP-7476
Change-Id: I4bbf2509112f375354cdde56a6e3ab46b77f239e
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/283706
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Evan Battaglia <ebattaglia@instructure.com>
QA-Review: Evan Battaglia <ebattaglia@instructure.com>
Product-Review: Tucker Mcknight <tmcknight@instructure.com>
closes INTEROP-6474
flag=none
test plan:
* in the lti-1.3-test-tool repo, check out these commits:
* https://gerrit.instructure.com/c/lti-1.3-test-tool/+/259061
* https://gerrit.instructure.com/c/lti-1.3-test-tool/+/259062
* using the AGS UI of the test tool,
* with an assignment that has a line item already
* post a Score object using that API, and check the box to include
a file content item
* the returned json should include the file content item, and a progress url
* using the id from the progress url, fetch a Progress object using
the AGS UI, providing the same credential and context ids
* (optional) enable InstFS locally and repeat the same process
Change-Id: Ieacc71cd612acf2fdf5c7e72293135796928877e
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/259064
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Wagner Goncalves <wagner.goncalves@instructure.com>
QA-Review: Wagner Goncalves <wagner.goncalves@instructure.com>
Product-Review: Xander Moffatt <xmoffatt@instructure.com>
refs SAS-1540
* adds an audience setting to developer keys, so a key can be set to
target external audiences with its credentials grants
* when a key with an external audience grants credentials, the token is
signed with an asymmetric key instead of the internal symmetric key
* external audiences can retrieve the corresponding public keys from
/login/oauth2/jwks
* credentials issued by developer keys with an account id include the
account's guid in a custom claim
includes a refactor of key storage and rotation in consul, which had
already been done for LTI. but it wasn't really a feature of lti, just
something used by LTI, and we needed the same for key management for
this. moved it to be part of Canvas::Security
Change-Id: Ie5c0fcee6fc21687f31c109389a3bcc1ed349c5d
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/243606
QA-Review: Jonathan Featherstone <jfeatherstone@instructure.com>
Reviewed-by: Jonathan Featherstone <jfeatherstone@instructure.com>
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Product-Review: Jacob Fugal <jacob@instructure.com>
Fixes: CAL-30
flag = none
Test Plan:
- Check developer keys LTI page and make sure HIDDEN items do not show up
(http://canvas.docker/accounts/1/developer_keys#lti_key_modal_opened)
under "LTI Advantage Services"
- Specs pass
Change-Id: I8408be58124ef7e57804b5a66fef791608701f7b
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/235629
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
QA-Review: Aaron Ogata <aogata@instructure.com>
Product-Review: Alex Slaughter <aslaughter@instructure.com>
Reviewed-by: Weston Dransfield <wdransfield@instructure.com>
Endpoint needed by CDC Event Tranformer to look up UUIDs for root
accounts it hasn't seen.
closes PLAT-5515
flag=none
Test plan:
- get an LTI Advantage token for a site admin dev key with the new scope.
This can be done by adding logging to the live-events-lti tool (I
think in app/services/access_token_service.rb#16) or using my
cdc-event-transformer test in CanvasClientTest.java and printing out
cc.getToken().
- hit the new endpoint with header "Authorization: Bearer MYACCESSTOKEN"
web.canvas-lms.docker/api/lti/accounts/123 with varying
values of account ID, including global IDs, accounts that do not
exist, global IDs where the shard does not exist...
- ideally we'd like to test that a dev key only available for one shard
cannot access account info for another shard. This could be done by
creating two dev keys that have the same ID but are on different
shards, and use a token for one dev key to try to access an account on
the other shard. This is probably hard to do locally though. I did
test on prod that DeveloperKey#account_binding_for will return nil
for an account in another shard even if there is a dev key with the
same local ID in the account's shard that has access to it.
Change-Id: I1299ebce9b94ce00d7cb62db01891b81908915ff
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/229580
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Weston Dransfield <wdransfield@instructure.com>
QA-Review: Xander Moffatt <xmoffatt@instructure.com>
Product-Review: Evan Battaglia <ebattaglia@instructure.com>
Closes PLAT-4952
Test Plan:
- Install an LTI 1.3 tool that uses the new
scope and service endpoint
- Make a request to the new endpoint specifying
a feature flag that exists. Verify the
feature flag is returned in the response
with accurate data.
- Make a request to the new endpoint specifying
a feature flag that does not exist. Verify
the service responds with a 404
- Verify the new endpoint adheres to LTI
Advange authentication/authorization (
requres JWT access token, requres active
developer key, etc.)
Change-Id: Ifb876b541c237a3c9ca45270bafea5693d6a03eb
Reviewed-on: https://gerrit.instructure.com/211196
Tested-by: Jenkins
Reviewed-by: Clint Furse <cfurse@instructure.com>
QA-Review: Clint Furse <cfurse@instructure.com>
Product-Review: Weston Dransfield <wdransfield@instructure.com>
Closes PLAT-4766
Test Plan:
- Configure Canvas to use the live events
subscription service
- Verify making a request to the new endpoint
returns a categorized list of events
- Verify the new endpoint uses LTI advantage
authorization/authentication
Change-Id: Id6f4ec2978e3a4542042bd821e408acfa566005c
Reviewed-on: https://gerrit.instructure.com/207713
Tested-by: Jenkins
Reviewed-by: Clint Furse <cfurse@instructure.com>
QA-Review: Clint Furse <cfurse@instructure.com>
Product-Review: Weston Dransfield <wdransfield@instructure.com>
closes PLAT-4744
Test Plan:
- see that the index action returns a list
Change-Id: I92cc07c5476c7dd48202f38b62e09df6aa591b62
Reviewed-on: https://gerrit.instructure.com/206435
Reviewed-by: Weston Dransfield <wdransfield@instructure.com>
Tested-by: Jenkins
QA-Review: Marc Phillips <mphillips@instructure.com>
Product-Review: Marc Phillips <mphillips@instructure.com>
closes PLAT-4761
Test Plan:
- see that a call to this endpoint will show a sub
Change-Id: Ifc299aebe5cfbadaf82a1970f75ad182ffa31b29
Reviewed-on: https://gerrit.instructure.com/206489
Reviewed-by: Xander Moffatt <xmoffatt@instructure.com>
Tested-by: Jenkins
QA-Review: Marc Phillips <mphillips@instructure.com>
Product-Review: Marc Phillips <mphillips@instructure.com>
fixes PLAT-4492
Test Plan
-Create test tool
-Use tool to create developer key in canvas
-Change tool credential oauth_client_id to match
client id from developer key
-Go to http://lti13testtool.docker/developer_key/update_public_jwk/21
-Verify that public JWK was changed:
Change-Id: Ic09a665d4ab14d3423b7e4b2a3a51296c0617981
Reviewed-on: https://gerrit.instructure.com/194447
Tested-by: Jenkins
Reviewed-by: Weston Dransfield <wdransfield@instructure.com>
QA-Review: Weston Dransfield <wdransfield@instructure.com>
Product-Review: Jesse Poulos <jpoulos@instructure.com>
Add some changes to the Manual Configuration form
for 1.3 tools.
refs PLAT-4248
Test Plan:
n/a
Change-Id: I02d0321eb338ddda5dccd232ab024729abfdf88e
Reviewed-on: https://gerrit.instructure.com/187168
Tested-by: Jenkins
Reviewed-by: Weston Dransfield <wdransfield@instructure.com>
QA-Review: Marc Phillips <mphillips@instructure.com>
Product-Review: Marc Phillips <mphillips@instructure.com>
Wording is now more useful for admins to determine
what permissions are being granted.
closes PLAT-4257
Test Plan:
- Create a tool with all permisisons
- Note that the help text is changed and useful
Change-Id: I23f50db5fad5d81565d64e8609d6a3da17f56321
Reviewed-on: https://gerrit.instructure.com/185851
Tested-by: Jenkins
Reviewed-by: Weston Dransfield <wdransfield@instructure.com>
QA-Review: Marc Phillips <mphillips@instructure.com>
Product-Review: Jesse Poulos <jpoulos@instructure.com>
- LTI 1.3 launches now include an AGS claim
(`https://purl.imsglobal.org/spec/lti-ags/claim/endpoint`)
if the current tool's `DeveloperKey` has been granted
any AGS scope.
- If the launched link is an `Assignment`, the AGS claim will
include a `lineitem` sub-claim set to the `Assignment`'s
LTI Advantage `LineItem` API URL
(`/api/lti/courses/:course_id/line_items/:line_item_id`).
- In any AGS-enabled launch from from a `Course` or `Group`,
the AGS claim will include `lineitems` sub-claim set the
`Course`'s LTI Advantage `LineItem` collection API URL
(`/api/lti/courses/:course_id/line_items`.)
Closes LTIA-49
Test Plan:
1. Create an LTI 1.3 tool with at least one AGS scope granted to
its `DeveloperKey`. Those scopes are:
- `https://purl.imsglobal.org/spec/lti-ags/scope/lineitem`
- `https://purl.imsglobal.org/spec/lti-ags/scope/lineitem.readonly`
- `https://purl.imsglobal.org/spec/lti-ags/scope/result.readonly`
- `https://purl.imsglobal.org/spec/lti-ags/scope/score`
2. Launch the tool from a course navigation link.
3. Verify that the
`https://purl.imsglobal.org/spec/lti-ags/claim/endpoint` claim is
present and:
3.1. Sets all the granted scopes into the `scope` sub-claim
3.2. Sets the `lineitems` sub-claim to
`/api/lti/courses/:course_id/line_items`
3.3. The `lineitem` sub-claim is not present.
4. Bind the tool to an `Assignment` and launch from that
`Assignment`.
5. Verify that the
`https://purl.imsglobal.org/spec/lti-ags/claim/endpoint` claim is
present and:
5.1. Sets all the granted scopes from step 1 into the `scope`
sub-claim
5.2. Sets the `lineitems` sub-claim to
`/api/lti/courses/:course_id/line_items`
5.3. Sets the `lineitem` sub-claim to
`/api/lti/courses/:course_id/line_items/:line_item_id`
To find :line_item_id for step 5.3 either use the console or database
query. E.g. in the console:
`Assignment.find(Assignment.maximum(:id)).line_items.find(&:assignment_line_item?).id`
6. Create another LTI 1.3 tool but do not grant any AGS scopes to its
`DeveloperKey`.
7. Launch the tool from a course navigation link.
8. Verify that the
`https://purl.imsglobal.org/spec/lti-ags/claim/endpoint` claim is
not present.
9. Bind the tool to an `Assignment` and launch from that
`Assignment`.
10. Verify that the
`https://purl.imsglobal.org/spec/lti-ags/claim/endpoint` claim is
not present.
Change-Id: I787d3e99c60993ed3d28ede08455617e601f3d30
Reviewed-on: https://gerrit.instructure.com/171345
Tested-by: Jenkins
Reviewed-by: Weston Dransfield <wdransfield@instructure.com>
QA-Review: Weston Dransfield <wdransfield@instructure.com>
Product-Review: Marc Phillips <mphillips@instructure.com>
- NRPS v2 invocations referencing a `Course` Context now attempt to
resolve a `ContextExternalTool` (CET) given the JWT `AccessToken`
attached to the request. In order to return memberships, that CET
must be active and must either be bound directly to the `Course` or
to an `Account` in the `Course`'s' `Account` chain.
- `AccessToken` must be associated with an active `DeveloperKey`
(DK), and the search for the "operative" CET for the current request
is executed against that DK's list of active CETs.
- `Course`-level CETs are preferred, followed by `Account`-level
CETs.
- LTI 1.3/Advantage features must be turned on at the CET and root
`Account` levels.
- The `AccessToken`'s'JWT signature and security claims are not
themselves validated... that comes later.
- `Group` Context support also comes later.
Closes LTIA-26
Test Plan:
- Via Rails console create a `DeveloperKey` associated with the
public key of a Tool configured in the IMS LTI 1.3/Advantage
Reference Implementation (RI) and the root `Account` in your env
- Via Rails console, create a LTI 1.3-enabled
`ContextExternalTool` with a `course_navigation` placement and
linked to the just-created `DeveloperKey` and its `Account`
- For a `Course` owned by this `Account`, verify that direct
invocations of the NRPS v2 API.
(`GET /api/lti/courses/:course_id/names_and_roles`) fail with
a 401 and a message complaining about a missing access token.
- Navigate to the `Course` and click the newly created nav link,
which should successfully launch the RI.
- Click the 'Request Names and Roles' link in the RI. Verify
course is reported in the NRPS v2 format.
- Deactivate the `DeveloperKey`. Click 'Request Names and Roles'
link in the RI. Verify a (non-descript) on-screen error message.
- Re-enable the `DeveloperKey` and re-verify the same behavior
for a `Course` associated with a sub-`Account`.
- Delete the CET, verify that NRPS v2 invocations from the RI
fail.
- Via Rails console, create a new CET linked to the same
`DeveloperKey`, but now attached to the sub-`Account` `Course`.
- Re-verify NRPS v2 invocation from the RI.
- *Consult JIRA for full acceptance criteria.
Change-Id: Ie9625ea8d6ce5e6f59e3c7ce1d10d0a47291afa4
Reviewed-on: https://gerrit.instructure.com/167183
Tested-by: Jenkins
QA-Review: Samuel Barney <sbarney@instructure.com>
Reviewed-by: Marc Phillips <mphillips@instructure.com>
Product-Review: Karl Lloyd <karl@instructure.com>
Closes PLAT-3748
Test Plan:
- Create an LTI key with customizations
- Verify the disabled placements are persisted
to the database
- Verify the scopes are persited to the database
- Verify the LTI key flow works as expected
Change-Id: I97217b09cfb10b3732d6ded478b95a8999c6b4e5
Reviewed-on: https://gerrit.instructure.com/166691
Tested-by: Jenkins
Product-Review: Weston Dransfield <wdransfield@instructure.com>
Reviewed-by: Marc Phillips <mphillips@instructure.com>
QA-Review: Marc Phillips <mphillips@instructure.com>
Closes PLAT-3746
Test Plan:
Verify the customization form only displays
placements that are requested in the tool
config and valid canvas placements.
Change-Id: I00383b992b3e8881f6f0b3929120886862b60a3a
Reviewed-on: https://gerrit.instructure.com/166362
Reviewed-by: Marc Alan Phillips <mphillips@instructure.com>
QA-Review: Xander Moffatt <xmoffatt@instructure.com>
Tested-by: Jenkins
Product-Review: Weston Dransfield <wdransfield@instructure.com>
Closes PLAT-3767, PLAT-3796
Test Plan:
- Make a request to the create endpoint. In addition
to including the 'tool_configuration' param, provide
a 'developer_key' param that looks like the following:
{
name: 'some name',
email: 'test@test.com',
notes: 'notes'
scopes: [some valid scopes]
require_scopes: true,
test_cluster_only_true,
}
- Verify the developer key that gets created as part of
the request had those fields set correctly
- Verify the scopes must be valid scopes
- Validate this works when both when providing the
tool settings as a URL and as a JSON blob
- Verify the same things for the update endpoint
Change-Id: I3313e90c36ece876f3b3be76de916a25b4ae06af
Reviewed-on: https://gerrit.instructure.com/166245
Reviewed-by: Marc Alan Phillips <mphillips@instructure.com>
QA-Review: Marc Alan Phillips <mphillips@instructure.com>
Tested-by: Jenkins
Product-Review: Weston Dransfield <wdransfield@instructure.com>
* NOTE: does not contain any server-side validation
of these scopes, just their definitions
refs PLAT-3766
test plan:
* load the developer keys page
* open console, confirm `window.ENV.validLtiScopes`
exists and contains the correct scopes from the ticket
Change-Id: I376ce41bcfdfcc074ae3356956cae7b8dbffb1a5
Reviewed-on: https://gerrit.instructure.com/165945
Reviewed-by: Weston Dransfield <wdransfield@instructure.com>
Tested-by: Jenkins
Reviewed-by: Marc Alan Phillips <mphillips@instructure.com>
QA-Review: Weston Dransfield <wdransfield@instructure.com>
Product-Review: Xander Moffatt <xmoffatt@instructure.com>
fixes PLAT-3454
test plan:
* you can either test in production RAILS_ENV
or turn on eager_loading and disable class_cache in development
* The scopes list in the developer keys page should show all
expected scopes
Change-Id: I4018cdd8d4f08d32f549cfab5f4a135c2144c403
Reviewed-on: https://gerrit.instructure.com/152398
Tested-by: Jenkins
Reviewed-by: Weston Dransfield <wdransfield@instructure.com>
QA-Review: Weston Dransfield <wdransfield@instructure.com>
Product-Review: Karl Lloyd <karl@instructure.com>
Closes PLAT-3394
Test Plan:
- Run the `doc:api` rake task
- Navigate to /doc/api/index.html and verify there
are two new links in the OAuth2 section ("Developer
Keys" and "API Token Scopes")
- Verify both links work
- Verify the token scopes documentation has a table
for each scope group and includes all Canvas
scopes
- Verify "Resources" documentation pages now display
the scope along with each API endpoint
Change-Id: I2fea0ff531744dbaf63d24619b3c0e9655a25a7a
Reviewed-on: https://gerrit.instructure.com/151010
QA-Review: August Thornton <august@instructure.com>
Reviewed-by: Nathan Mills <nathanm@instructure.com>
Tested-by: Jenkins
Product-Review: Jesse Poulos <jpoulos@instructure.com>
fixes PLAT-3311
test plan:
* run the rake task "doc:api"
* request the scopes from api/v1/accounts/:account_id/scopes
- you should get back a json object that includes the localized name
* request the scopes from api/v1/accounts/:account_id/scopes passing
the query param "group_by=resources_name"
- you should get back a json object with the scopes grouped by
localized resource_name
Change-Id: I2cab1822baef7cdda6471096153d60d4f7fe1e2b
Reviewed-on: https://gerrit.instructure.com/150233
Tested-by: Jenkins
Reviewed-by: Marc Alan Phillips <mphillips@instructure.com>
QA-Review: August Thornton <august@instructure.com>
Product-Review: Jesse Poulos <jpoulos@instructure.com>
refs PLAT-3024
test plan:
* request the scopes from api/v1/accounts/:account_id/scopes
- you should get back a json object that matches the documentation
* request the scopes from api/v1/accounts/:account_id/scopes passing
the query param "group_by=resources"
- you should get back a json object with the scopes grouped by
resource
Change-Id: I4562121a44e3baccc7de8e56e19629377f1931df
Reviewed-on: https://gerrit.instructure.com/148623
Reviewed-by: Marc Alan Phillips <mphillips@instructure.com>
Tested-by: Jenkins
Reviewed-by: Andrew Butterfield <abutterfield@instructure.com>
QA-Review: August Thornton <august@instructure.com>
Product-Review: Nathan Mills <nathanm@instructure.com>
fixes PLAT-3176
fixes PLAT-3179
fixes PLAT-3181
fixes PLAT-3177
Test plan:
* Create a DeveloperKey
* Create an AccessToken
* Ensure that everything can be accessed as normal
* Set require_scopes to true on the DeveloperKey
* Ensure that nothing can be accessed
* Add some scopes to the AccessToken from the list of available scopes
TokenScopes::SCOPES
* Ensure that the endpoints associated with those requests work but that
others don't
* Ensure that HEAD requests work for GET endpoints
* Ensure all api endpoints behave normally when scopes are not turned on
for developer key
Change-Id: I0e7c1758ae2d51743490f243cfa21714255c8109
Reviewed-on: https://gerrit.instructure.com/143026
Tested-by: Jenkins
Reviewed-by: Simon Williams <simon@instructure.com>
Reviewed-by: Nathan Mills <nathanm@instructure.com>
QA-Review: August Thornton <august@instructure.com>
Reviewed-by: Rob Orton <rob@instructure.com>
Product-Review: Karl Lloyd <karl@instructure.com>
Alexandre Trindade