These notes are the result of a tour provided by jd maloney on February 15, 2018
The objective of the tour was to learn about the parameters of authentication and permissioning in the globus connect model.
Following the Non-Shared Endpoint Model
In the non-shared endpoint, Globus connect authenticates the user with the authentication method found in the /etc/globus-connect-server.conf file. In this file there is a property called "IdentityMethod" which can be set to:
- MyProxy
- CILogon
- A generic OAuth configuration
At NCSA we use our OAuth server.
The next problem is mapping the authenticated user back to their UID for picking up local file permissions. This is accomplished with a file called "/etc/grid-security/grid-mapfile". There is a cron job that regularly queries LDAP for members of an appropriate group and writes their data to this file.
If we can figure out how to work with UID/GID from docker containers in Kubernetes, then we could consult these two files to make sure we remain in synch with the local globus install.
Following the Shared Endpoint Model
Access to shared endpoints are controlled by the user's Globus ID. Access to the local file system is simply determined by permissions for the user who owns the endpoint. A naive approach would be to authenticate users to workbench via globusAuth and then test to see if they have access to the share. Containers running in workbench would then require similar permissions to the shared endpoint owner's UID. The Globus shared endpoint allows fine-grained write permissions which would be harder to replicate in the container-based permissioning.