D6.2:Virtual Folder and West-Life Portal integration

Virtual Folder and West-life portal integration

Integration between Virtual folder (VF) and West-life portal (VRE) can be done using cookie based authentication. VF trust VRE when deployed on the same host. An user authenticates to West-life portal (VRE) and is redirected to Virtual Folder (HTTP cookie sessionid is set). Selected components of Virtual Folder then asks VRE for the user details of the user with cookie "sessionid" and serves user specific content.

Prototype implementation is maintained in "dev-multiuser branch" https://github.com/h2020-westlife-eu/west-life-wp6/tree/dev-multiuser. Prototype implementation of the integration modify VRE in Python/Django framework to expose REST interface returning userinfo based on sessionid. New class UserInfo, UserSerializer and appropriate url into api/urls.py.

Prototype implementation modify MetadataService (C# ServiceStack .NET). New RequestFilterAttribute obtains the user info from VRE - this request filter is triggered on every service call.

URL mapping

• http://localhost/ - redirects to VRE
• http://localhost/virtualfolder - VF userspecific content
• http://localhost/metadataservice - REST api for VF functionality (needs sessionid from VRE)
• http://localhost/webdav/{username}/{path} - redirects to user's specific virtual folder webdav, no authentication is required!, need to figure out howto deal with that, e.g. security by obscurity ( hash of username with expiration time) (doesn't need sessionid)

public URL mapping:

• https://portal.west-life.eu/ - redirects to VRE
• https://portal.west-life.eu/virtualfolder - VF userspecific content
• https://portal.west-life.eu/metadataservice - REST api for VF web component functionality (needs sessionid from VRE)
• https://portal.west-life.eu/webdav/{username}/{path} - redirects to user's specific virtual folder webdav mounted at ${VF_CONTAINER_DIR}/{username}/{path}
  • requires sessionid - with logged-in user
• https://portal.west-life.eu/webdav/{hash}/{path} - redirects to user's specific virtual folder webdav mounted at ${VF_CONTAINER_DIR}/{username}/{path}
  • do not require sessionid - with logged-in user

Security

DB contains sensitive information, if compromised, the VF service will gain bad reputation. Current best practices:

1. not to store user passwords, store hash instead:
   1. not an option for VF use case - it needs to access the files in scatered data storages on behalf of user
2. encrypt the passwords and tokens:
   1. use strong encryption method
   2. store encryption key in some secure space - e.g. dedicated hardware etc.
   3. use salt to enhance encryption

Security Design

The accesstoken (password for b2drop) are stored within VF database. From version 17.02 ('dev' branch) the selected items in DB are encrypted while the others are left in plain, it is stored using AES encryption with symetric key and salt based on username.

• key is generated during bootstrap of the process and exported as system variable 'VF_STORAGE_PKEY' and stored in a file within VM
• encryption is enhanced by a salt generated from username, every user has unique
• exploatation of the db may not harm too much as the sensitive information are encrypted.
• every instance of VM uses different random encryption key
• in case of the key is changed, lost - the public information is valid, however securetoken are lost - user needs to reconnect/ update the password into VF.

Other options to consider

1. move encryption key to dedicated HW within portal, leave it in secured file within VM.
2. encrypt whole DB, one key and salt
3. find out different secure mechanism to store sensitive information
4. connect to b2drop using token not password - depends on availability on b2drop service

Virtual folder and partner portal integration

D6.2:Virtual_Folder_and_Partner_Portal_integration

UX Design

Progress

Meeting notes:

• January_30th_conference_call
• D6.2Call17.02.02
• D6.2Call17.02.07
• D6.2Call17.02.10
• D6.2Call17.02.14
• D6.2Call17.02.16
• D6.2Call17.02.23
• D6.2Update17.03.02
• D6.2Call17.03.09

Work in progress:

• [[1]]

Restricted Webdav URL

new design proposal

Getauthproxy API at /api/getauthproxy/ generates URL https://portal.west-life.eu/webdav/{hash}/{path} - which redirects to user's specific virtual folder webdav mounted at ${VF_CONTAINER_DIR}/{username}/{path}. This is currently used by filepicker and uploaddirpicker component to generate URL, that do not require sessionid. But this allows path traversal along all user's mounted folders.

Proposal is to introduce new VRE API to generate URL e.g.https://portal.west-life.eu/webdav/{hash} - which redirects to user's ${VF_CONTAINER_DIR}/{username}/{path} - Note that the {path} is not encoded in URL - thus allowing to browse only this specific folder but not parent.

• authenticated GET /api/getauthpathproxy - returns list of proxies [{id,hash,path,expiration}] in user context belonging to user
• GET /api/authpathproxy/{id} - returns concrete detail of proxy [{id,hash,path,expiration}]
• PUT /api/authpathproxy/{id} - puts new or replaces existing proxy for user
• POST /api/authpathproxy - puts new proxy for user - generates {id}
• DELETE /api/authpathproxy/{id} - deletes existing proxy and mapping of {url} -> {server_path}
• all proxies may have expiration time - in days - a crontab job on system (or DJANGO service) removes expired entries from web server regularly.