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 <http://oauth.net/>`_. 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.