ONEDrive implementation ======================= ONEDrive mockups: https://repository.dataone.org/software/cicore/trunk/itk/d1_client_onedrive/doc/build/html/mockups/index.html Notes from U&A WG discussions: http://epad.dataone.org/Sp13-SCUAwg-usability .. _`ONEDrive mockups`: https://repository.dataone.org/software/cicore/trunk/itk/d1_client_onedrive/doc/build/html/mockups/index.html Overview ~~~~~~~~ The three `ONEDrive mockups`_ were evaluated and it was determined that support for search/discovery would be based on integration with ONEMercury and that folder contents would be rendered as a folder structure as shown in the first image in the OS specific integration mockup. .. graphviz:: digraph G { "D1 Workspace" -> "ONEMercury" [dir=both]; "D1 Workspace" -> "ONEDrive" [dir=both]; } The system consists of a new product that provides a web interface and APIs for a workspace and extensions in ONEMercury and ONEDrive to interact with the workspace. There is no direct connection between ONEMercury and ONEDrive. Interaction is indirect, through the D1 Workspace. The D1 workspace has public APIs, enabling programmatic access for MNs, ITK and other DataONE components. For instance, MNs that have existing search facilities can add objects to a user's workspace. User experience overview ~~~~~~~~~~~~~~~~~~~~~~~~ - The user can go directly to ONEMercury and perform searches without logging in. - When the user finds an object or query that he would like to add to his workspace, he clicks one of the "add to workspace" buttons. At that point, if he is not already logged in, he is forwarded to CILogon. After logging in, he is returned to ONEMercury, where he can complete the operation. - ONEMercury also contains a link to the workspace. If the user clicks the link without already having logged in, he is forwarded to CILogon before the workspace opens. - The user's view of the workspace is a web interface in which he can manipulate his saved objects and searches. In the initial implementation, this can be simply a list of items with a delete button for each. - When the user wants to access objects directly through ONEDrive, he starts ONEDrive in the same way that other apps are started in his OS. Ideally, he would then automatically be brought through CILogon, but only if not already logged into the workspace. At the completion of the procedure, ONEDrive would be mounted and opening the ONEDrive root would display his workspace, from which objects can be accessed directly. Workspace ~~~~~~~~~ The initial view of the workspace can be a simple list of objects with a delete option for each. But the workspace concept is powerful and there are many possibilities for useful functionality that can be implemented there. The workspace can, essentially, become a dashboard for the user's interaction with content in DataONE. * Objects and queries can be: * named * annotated * arranged into folder structures * shared with other users * rated * previewed * downloaded * System metadata properties can be edited: * ACLs * Owner * Object Format * Various statistics can be provided: * Usage data for objects owned by user * Amount of storage used in DataONE * Replication status of objects Some possible product names for the D1 workspace: * ONESpace * ONEDesktop * ONEDashboard Implementation ~~~~~~~~~~~~~~ Goals: * The user should only need to authenticate a single time when using three different products (ONEMercury, the workspace and ONEDrive). * The user should not need to authenticate when using ONEMercury without interacting with the workspace. * When the user authenticates, that should open access both to his workspace and to his access controlled objects in DataONE. * The user should only be required to re-authenticate when the certificate expires. * When the certificate expires, the user should automatically be forwarded to CILogon again (avoiding cryptic error messages about expired certificates). * Communication between the components must be secure and authenticated. Workspace --------- When the user logs in via the workspace, the workspace forwards the user to CILogon. But, instead of the certificate being downloaded to the user's computer, it is stored by the workspace and the user is provided with a session cookie that has the same expiration date-time as the certificate. The session allows the user to access the workspace through the browser, and so, allows indirect access to the certificate. It also allows ONEMercury to issue REST API calls to the workspace in the context of a specific user (when running from the same browser). The workspace uses the certificate when issuing DataONE queries on behalf of the user. ONEMercury ---------- ONEMercury authentication goals: * Avoid having to log into the workspace if the user does not use the workspace functionality. Main options for workspace integration: * Server side (the server issues calls to the workspace). * Client side (the client issues calls to the workspace). ONEDrive -------- ONEDrive must have access to a valid CILogon certificate. The certificate links ONEDrive to a specific user's workspace. The certificate also allows ONEDrive to access non-public objects for which the user has access. ONEDrive authentication goals: * Avoid having to go through CILogon authentication if the user already has logged into the workspace. * If the user is not already logged in through the workspace, have the ONEDrive-initiated login also apply to the workspace. Options to investigate: 1) ONEDrive can be started through a simple OS specific program that opens an embedded browser. If it's possible for this embedded browser to reach the workspace session cookie, it would be possible to enable an automated download of the certificate without the user having to authenticate again. This would also enable the workspace to determine if the user is already authenticated and direct to CILogon if necessary. 2) Supporting `OAuth `_. With OAuth, there would be a page in the workspace in which the user could obtain an authentication token. This authentication token would be copied into the user's local ONEDrive configuration. ONEDrive would then be able to download the currently valid certificate and use it for retriving object bytes directly from MNs. I also considered the following option but realized that it would not scale because it would cause all object access to go through the workspace server: If it's possible for ONEDrive to reach the workspace session cookie directly, then ONEDrive could interact with DataONE via the workspace by submitting the cookie in REST API calls. The workspace would add the certificate to connections made on behalf of the user.