-
Notifications
You must be signed in to change notification settings - Fork 1
Service Plan
Indiana University’s Kumo is designed to provide easy, ubiquitous access to a user’s data wherever it is – in the cloud or on premise – from managed computing environments, including virtual systems and labs. A user configures their storage preferences through a hosted web portal. These preferences are securely stored and can be updated by the user at any time. When that user logs into a supported lab machine or virtual environment, a desktop client automatically imports the user’s profile and links their storage through a series of virtual or network drives. The user can then interact with their data through the OS file browser or an application’s Open/Save dialog.
The following cloud-based storage providers are supported by Kumo and connected as virtual drives:
- Box (personal, enterprise)
- Dropbox
- Google Drive
- Microsoft OneDrive (personal)
- Microsoft OneDrive for Business / Office365 (enterprise)
Additional integrations can be developed within weeks pending demand and certain technical requirements.
The following file servers are mounted directly as network drives via user-entered paths:
- SMB/CIFS-based file shares (via UNC paths)
- SharePoint/WebDAV servers (via HTTPS URLs)
Kumo currently supports Windows-based lab machines and virtual environments.
See Contact Us
Kumo is comprised of three primary components:
- A hosted Portal, at which a user can configure their storage preferences;
- A Client, which is installed on each workstation/VM and manages a user’s drive mappings and moves data to/from the cloud;
- An Access Broker service, which is a security module that facilitates cross-domain authentication between the Client and Portal.
The Kumo Portal is a centralized web application and set of web services hosted by Indiana University. When the user browses to the Portal, they are prompted to log in through the partner institution’s authentication service. This is accomplished via federated authentication and coordination between Indiana University and the partner institution. Once logged in, the user is presented with an array of storage options as described above.
The user can freely choose which storage option(s) to authorize. Cloud-based storage is configured by clicking a button that initiates the OAuth 2.0 workflow, which is an industry standard mechanism for providing and limiting 3rd-party access to cloud-based data. This workflow is described in greater detail below. On premise storage is configured by entering the UNC or URL address of the share. The user can disable any storage option at any time.
The Kumo Client is a small program that is installed once onto each domain-joined lab machine or virtual server. The Client has two responsibilities: to manage the virtual and network drive mappings corresponding to a user’s storage preferences, and to facilitate the transfer of data to and from a cloud-based storage provider. The Client is launched on a per-user basis as the user logs into a session and immediately authenticates with an Access Broker (described in the next section.) Once authenticated, the Client requests from the Portal the storage configuration for the user, which consists of the name and OAuth2 access tokens for any authorized cloud-based storage provider, and the path(s) to any on-premise storage. Cloud-based storage is mapped through a virtual file system framework. File metadata and content requests are made using the storage provider’s public API and authenticated with the OAuth2 access tokens provided by the Portal. On-premise storage paths are mounted as network drives, with file metadata and content requests being managed directly by the underlying operating system.
In order to provide an optimal user experience the Client will actively manage a user’s drive mappings over the course of a session. If the user changes their storage preferences during that session, the Portal will notify the Client that a preference update has occurred. The Client will then retrieve the latest storage configuration from the Portal and add or remove drives as necessary. This notification and update cycle occurs quickly, typically within 5 seconds.
The Client will periodically report cloud-based usage information back to the Portal. This information includes the identity of the user and provider, size of the file, start/end times of the transfer, whether data was uploaded or downloaded, and whether the transfer succeeded. Neither file names nor contents are reported. This information is used to provide aggregate, anonymized, per-provider utilization reports.
A key feature of Kumo is that a user’s storage configuration is automatically and silently fetched from the Portal and mounted by the Client when the user starts a session. Before this can occur the Portal must positively identify the Client as running on behalf of a particular user, which requires some method of authentication. However, the only pre-established identity exchange between the partner institution and Kumo – SAML-based federation – requires that the user manually log into the service through a web browser. The Kumo Access Broker is a secure, domain-level authentication proxy that allows the service to avoid federation’s manual log in requirement while ensuring that the Client/user is positively authenticated. The Access Broker is installed as a network service on a Windows Server 2008+ instance that is provisioned, secured, and maintained by the partner institution.
The Kumo Portal will authenticate users via federated authentication in coordination with the partner institution’s identity management group. Federation will support any SAML 2.0-capable identity provider, with Shibboleth and ADFS being two popular and widely deployed options. Indiana University will receive a universal principal name (UPN/EPPN) and email address for all authenticated users.
Kumo supports four service level roles as shown in the table below. The User and Reporter roles are issued as claims (security assertions) by the partner institution’s identity provider. The two administrative roles are granted through a database lookup. A user can be assigned the ServiceAdmin role only by an existing service-level administrator at Indiana University. A user can be assigned the MemberAdmin role by either a service-level administrator or an existing member-level administrator of the partner institution.
| Role | Asserted By | Privileges |
|---|---|---|
| User | IdP | Can configure personal storage options |
| Engineer | IdP | Can download Kumo Client installers |
| MemberAdmin | Kumo ADFS Server, via Database | Can administer presentation of partner institution’s site; manage cloud provider information; download and distribute Access Broker and Client installers. |
| ServiceAdmin | Kumo ADFS Server, via Database | Can add and modify partner institution metadata, including IdP location and support contacts. |
A cloud-based storage provider is authorized via the OAuth 2.0 workflow. When the user elects to authorize a particular provider, their browser is redirected to that provider’s website, where the user is prompted to log in. The user is then provided a description of the service that wishes to access their data – in this case Kumo – and the degree of data access that the service desires. The user chooses to allow or deny access to their data and is subsequently redirected back to the Kumo Portal. If the user has elected to allow access to their data, Kumo is issued a data token by the provider that provides on-going authorization to access the user’s data. This workflow is desirable in that it gives the user complete control over their data and prevents them from having to share their credentials with Kumo.
A user’s authorization to connect to a given file server cannot be verified when the path is entered. However, integrated (kerberos) authentication is used to authenticate the user when the file server is being mounted by the lab/virtual session.
The Access Broker utilizes two separate mechanisms to help the Portal positively identify the Client’s user. Client – Access Broker authentication is provided by the integrated (Kerberos) authentication features of the Active Directory Domain Services role in Windows Server 2008+. Access Broker – Portal authentication is provided by a mutual validation of SSL certificates. During the Access Broker installation process, the administrator is required to provide an SSL certificate (and hostname) by which the Access Broker will identify itself to the Portal. The Access Broker then registers itself with the Portal with this hostname, however it cannot serve requests until it is manually enabled by the administrator in a secure section of the Portal. All future Access Broker – Portal requests will use mutual certificate authentication to positively verify client/server identities.
The Portal requires that any request relating to a particular user’s storage profile be accompanied by a specific authorization token in the HTTP request header. When the Client is launched it requests this authorization token from the Access Broker, which in turn requests it from the Portal. Each request is authenticated using the mechanism described in the section above. Upon positively identifying the Client’s user, the Portal will release the authorization token back to the Access Broker, which in turn releases it to the Client. The Client stores this token in memory and attaches it to any subsequent request of the Portal. The token expires after one hour, at which time the Client must request a new token from the Access Broker.
Access to cloud-based data for a particular user is authorized by the OAuth 2.0 access tokens that are released to the Client by the Portal. The authorization tokens expire after a set period of time – typically one hour – after which the Client will send a request to the Portal to refresh the cloud provider access token for the given provider and user. This expiration/reauthorization process is a standard part of the OAuth 2.0 workflow.
Access to on-premises data is authorized by the domain-level permissions for the file server in question.