Hey Suresh,

Thanks for starting this conversation!

What do you think the users’ “extra one time configuration” would look like?

One of the things I was thinking about was how the gateway can do things like 
pass a path to the compute node in order to find files. Is it possible for the 
gateway to produce a “file picker” sort of dialog based on what it can see in a 
path you give it? It runs jobs as its service account when Airavata interacts 
with it. You might not have to have it run *as* the user in order to produce a 
directory listing for acquiring and depositing files, if the user changes the 
permissions on a certain set of directories such that the service account can 
read/write to them.

Does this make sense? Would it be a large development effort to get this 
additional bit of UI functionality? Obviously part of the purpose of a science 
gateway is to avoid having to dig around on the command line sorting out what 
files are where.

Thanks!
Jarett

> On Aug 8, 2016, at 2:17 PM, Suresh Marru <[email protected]> wrote:
> 
> Hi Jarett,
> 
> To give some context, let me start refreshing the security(authentication and 
> authorization aspects) within Airavata. 
> 
> There are clearly two distinct layers, users securely interacting with 
> Airavata and Airavata able to security interact with storage and compute 
> resources. The former interactions are facilitated with WSO2 IS and later 
> managed by Airavata Credential Store. For your use case we need to brainstorm 
> on how we bridge the two. You can read more about Credential Store here [1]. 
> 
> If I am understanding your scenario, users authenticate on PGA with the 
> credentials in LDAP/FreeIPA (brokered through WSO2 IS). Airavata then allows 
> them to use compute resources managed by roles in the IS (in the future we 
> might replace this with more fine grained group management). All 
> authenticated and authorized users can interact with storage and compute 
> resources which the gateway administers have enabled them by retrieving the 
> credentials stored in the credential store. Currently only administrators 
> generate and configure these credentials. We have considered power users 
> (with appropriate role privileges also using credential store directly). 
> 
> If your use case is for every user, then we need to essentially have them 
> delegate access to their personal storage space. Access protocol is not not 
> too much of an issue to support, how seamlessly and security we can have 
> users delegate their storage credentials is a challenge. Its not a major 
> development effort, but its more of a usability issue. If we need to do it in 
> a good secure way, users should be prepared to do extra one time 
> configuration. If we need to have users do nothing, then that will lead to 
> less secure options. 
> 
> Can we outline from a usability standout what will be a acceptable credential 
> delegation (access to their storage space) and build from there? 
> 
> Cheers,
> Suresh
> 
> [1] - 
> https://scholarworks.iu.edu/dspace/bitstream/handle/2022/17379/ccgrid_2014_credential_store.pdf
>  
> <https://scholarworks.iu.edu/dspace/bitstream/handle/2022/17379/ccgrid_2014_credential_store.pdf>
> 
> 
>> On Aug 2, 2016, at 5:08 PM, Jarett DeAngelis <[email protected] 
>> <mailto:[email protected]>> wrote:
>> 
>> Hi all,
>> 
>> When the PGA gateway is dealing with something like getting files to and 
>> from user space (like an NFS share, for example), what is the canonical way 
>> of doing this? Since the gateway is running as the Apache service account, 
>> it does not have permissions on the user's directories. Is there something 
>> standard you can put into an application interface to let it get files back 
>> and forth? Like, some kind of spot for ssh/scp URIs, for example? I dunno, 
>> putting scp://user:password@host:~/path/to/directory 
>> <scp://user:password@host:~/path/to/directory> in for a path? Or some more 
>> nicely-designed file picker-type interface that uses the PGA user’s logged 
>> in credentials (in our case, from LDAP/FreeIPA)?
>> 
>> Thanks in advance,
>> Jarett
> 

Reply via email to