The user grants access to the application and the storage service redirects the user back to your Kumo portal.This prompt typically includes information about the application that is requesting access, including the name of the application the scope of access requested. The user will be redirected to the storage service's website where they will login and be prompted to explicitly delegate access to Kumo.
A user visits the Kumo portal and elects to authorize Kumo to access their files on the storage service.This application will have a unique identifier and a shared secret that you'll set in a corresponding storage option in your Kumo portal.However, if you do have such an agreement in place you may wish to consult with the service owners at your institution prior to creating this application.) Note: For the purposes of OAuth2 your institution does not need to have to have any sort of pre-existing or enterprise agreement with the storage service in order to create this application. A Kumo administrator will create a Kumo application on the storage service's website.
Specific instructions for each supported storage service are provider later in this document, but the general process is illustrated below. In order to make a storage service available to your users a bit of configuration must be performed at both the storage service's site and in your Kumo admin portal. The OAuth2 specification and a helpful primer are available if you'd like to learn more. OAuth2 is an authorization framework that enables resource owners (students, faculty, staff) to delegate access to their resources (cloud-based files) to 3rd party services (Kumo) without having to share their credentials. This document describes how to configure your Kumo tenant to work with supported cloud storage services.
0 kommentar(er)
