Ally,

I don't want to jump into this discussion and certainly will wait for Steve or 
others to respond to your specific question. It does sound however as if you 
might be looking to implement a service for an extended community of users. 

If so, you may wish to look over the extensive set of documents available from 
OGF at http://ogf.org/documents to see if there are any that are applicable to 
your scenario. In particular there are documents that describe the grid 
security infrastructure, and an interoperable profile for the design of 
authorization methods using XACML has recently been published as GFD.205.  
Callouts for GridFTP as well as to other components of grid computing 
infrastructure are among the applications of the methods described in these 
documents. 

As I see you are based in the UK, you may wish to communicate with Mike Jones 
at Manchester, who co-chairs the OGF Federated Security working group, and/or 
Jens Jensen at STFC, the OGF Area Director for Security. 

If any of this information is helpful or you wish to know more about OGF, 
please contact the above folks or let me know. 

Alan


> On Feb 6, 2014, at 5:37 AM, "Ally Hume" <[email protected]> wrote:
> 
> Hi Steve,
> 
> Thank you for the information. In started to look around into the GridFTP 
> code to see if I could do the callouts I need to use an external 
> authorization service as this remains our architectural design and I 
> discovered source-trees/gridftp/server/acl/example which gives an example of 
> a extension API that supports authorization plug-ins. This seems to be 
> exactly what I need. It seems I can use this for all the access control and 
> therefore map all users to a single uid and hence decouple grid FTP from the 
> file system access control as desired.
> 
> Is there any reason why this would be a bad idea?
> 
> Regards,
> 
> Ally
> 
> 
> Ally Hume
> Software Architect
> EPCC, The University of Edinburgh
> 
> 
> 
> 
>> On 31 Jan 2014, at 03:36, Steve Tuecke <[email protected]> wrote:
>> 
>> Ally,
>> 
>> Unfortunately we do not yet have good public documentation on how sharing 
>> works from a security point of view.
>> 
>> In short, when you configure Globus Connect Server / GridFTP with sharing, 
>> you are configuring it to trust Globus to manage access control within the 
>> configured sharing bounds.  As a site administrator you can control what 
>> portions of your file system are sharable, using the sharing-restrict-paths 
>> option, which is like the restrict-paths option. You can also control which 
>> of your local users are allowed to share. Then as a user X, when you setup a 
>> shared endpoint within those bounds, you are specifying a particular folder 
>> that your GridFTP server will trust Globus to access.  When a user Y who has 
>> been granted permission via Globus to that shared endpoint accesses the 
>> folder, Globus logs into your GridFTP server as Globus, and specifies that 
>> it wants access user X’s shared endpoint. The GridFTP server will setuid 
>> into user X’s local account, chroot (enforced by GridFTP, not the system 
>> level) to the folder, and perform the I/O operations subject to the Globus 
>> managed access control rights as well as user X’s local file system 
>> permissions.
>> 
>> If you would like to discuss this in more detail, let me know and we can 
>> setup a call.
>> 
>> Regards,
>> -Steve
>> 
>>> On Jan 24, 2014, at 10:29 AM, Ally Hume <[email protected]> wrote:
>>> 
>>> Hi Steve,
>>> 
>>> Thank you for replying. I enjoyed the webinar and the functionality is very 
>>> interesting.
>>> 
>>> Is there any documentation that explains how the sharing works from a 
>>> security point of view? If I share my data at Edinburgh with you then does 
>>> the Edinburgh site simply have to trust Globus Online when Globus Online 
>>> tells Edinburgh that Steve Tuecke wants to access one of Ally Hume's 
>>> endpoints? You obviously cannot log onto the Edinburgh site though our 
>>> Authentication method because Edinburgh's authorisation service does not 
>>> know about you. I'm just speculating here so it would be great to read how 
>>> it is done.
>>> 
>>> Regards,
>>> 
>>> Ally
>>> 
>>> 
>>>> On 23 Jan 2014, at 21:45, Steve Tuecke <[email protected]> wrote:
>>>> 
>>>> Ally,
>>>> 
>>>> Globus (Online) has new “sharing” functionality that may be suitable for 
>>>> this use case. With Globus you can create “shared endpoints” on a storage 
>>>> system running a (new) GridFTP server. Each shared endpoint is basically 
>>>> giving Globus a virtual, change-rooted access path to a particular folder 
>>>> on your server. Once a folder is exported to Globus as a shared endpoint, 
>>>> the shared endpoint owner can then set access control policies that allow 
>>>> read or read-write access on any folder tree within the shared endpoint to 
>>>> any Globus user or group.
>>>> 
>>>> So in your case, you have a data archive that is accessible via GridFTP.  
>>>> Upgrade to the newest GridFTP server if you haven’t already — better yet, 
>>>> install Globus Connect Server, which makes the installation and 
>>>> configuration of GridFTP easier. Enable sharing on that server 
>>>> (https://support.globus.org/entries/23857088-Installing-Globus-Connect-Server).
>>>>   Create one or more shared endpoints for folders on your data archives.  
>>>> Then configure the access control on those shared endpoints to grant read 
>>>> or read-write access to the endpoints, or specific folders within the 
>>>> endpoints, to specific Globus users and groups.
>>>> 
>>>> Here’s a webinar we gave recently that includes a demonstration of the 
>>>> Globus sharing functionality:
>>>> 
>>>> http://fasterdata.es.net/fasterdata-home/more-references/esnet-helpful-talks-and-tutorials/delivering-a-campus-data-service-with-globus-and-esnet/
>>>> 
>>>> Regards,
>>>> -Steve
>>>> 
>>>>> On Jan 23, 2014, at 5:01 AM, Ally Hume <[email protected]> wrote:
>>>>> 
>>>>> Hi Michael,
>>>>> 
>>>>> This is exactly the type of thing I'd like to do but I would like to do 
>>>>> it on a per-user basis. We have a desire to decouple the access control 
>>>>> of our data archive system (which will be accessible via GridFTP) from 
>>>>> the unix file system access control.  I would therefore like to be able 
>>>>> to call out to a module or service than specifies a restrict path for 
>>>>> each authenticated user.
>>>>> 
>>>>> Ally Hume
>>>>> Software Architect
>>>>> EPCC, The University of Edinburgh
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>>> On 22 Jan 2014, at 22:39, Michael Link <[email protected]> wrote:
>>>>>> 
>>>>>> Hi Ally,
>>>>>> 
>>>>>> GT 5.2 has a path restriction feature that can do what I think you're 
>>>>>> asking.  See '-restrict-paths' here: 
>>>>>> http://toolkit.globus.org/toolkit/docs/5.2/5.2.5/gridftp/admin/#commandlineoptions-server
>>>>>> 
>>>>>> For instance, the configuration '-restrict-paths RW~/,R/data' would 
>>>>>> enable read/write access to the users home directory and read access to 
>>>>>> the /data directory, while denying all other paths.
>>>>>> 
>>>>>> If that doesn't fit your needs, can you give some examples of what you'd 
>>>>>> like to do?
>>>>>> 
>>>>>> Mike
>>>>>> 
>>>>>>> On 1/22/2014 6:23 AM, Ally Hume wrote:
>>>>>>> Does anybody know of a way to perform GridFTP's file permission 
>>>>>>> authorization using a call out to an external component rather than 
>>>>>>> simply mapping users to a unix user and replying on the unix file 
>>>>>>> permissions to handle the authorization? Ideally I'd like for the call 
>>>>>>> out service to be able to specify a restricted set of folders from all 
>>>>>>> the folders that the unix user has permissions to access.
>>>>>>> 
>>>>>>> Is this type of thing possible with GT5?  I've seen hints of people 
>>>>>>> trying to do something like this with GT4 but I'm not sure if this is 
>>>>>>> possible with the latest version.
>>>>>>> 
>>>>>>> Regards,
>>>>>>> 
>>>>>>> Ally Hume
>>>>>>> Software Architect
>>>>>>> EPCC, The University of Edinburgh
>>>>> 
>>>>> 
>>>>> -- 
>>>>> The University of Edinburgh is a charitable body, registered in
>>>>> Scotland, with registration number SC005336.
>>> 
>>> 
>>> -- 
>>> The University of Edinburgh is a charitable body, registered in
>>> Scotland, with registration number SC005336.
> 
> 
> -- 
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
> 

Reply via email to