Last Updated: May 1, 2020

1. Introduction

This document describes the common tasks a Globus administrator would need to do to create and manage storage gateway and collection resources associated with the endpoints that they run. This document assumes that you have already created and deployed an endpoint by following the Globus Connect Server version 5 Installation Guide. The commands in this guide assume you have access to the globus-connect-server command-line tool.

Storage Gateways provide the policies for a storage system connected to the endpoint, and Collections provide the data access interfaces for users.

A storage gateway contains policies for

A collection contains GridFTP and HTTPS interfaces for data access, and policies that govern sharing data with other users.

Important

In this document, we will show some example invocations of the Globus Connect Server version 5 management commands. If you plan to follow along on your own system, you’ll need to change the commands to reflect your organization and login policies. Anywhere you see something highlighted like this you’ll need to replace the text with something that matches the desired policies for your own endpoint.

2. Storage Gateways Overview

A storage gateway provides the access policies for the endpoint’s connected storage systems. It is a named interface by which authorized users can create and manage collections on the connected storage system. A single storage system may be associated with multiple storage gateways, each with its own policies.

Storage gateway policies describe what type connector the storage gateway uses, the paths it allows access to, the login requirements are for the storage gateway, and the algorithm to map Globus identities to the user namespace of the storage gateway (e.g. local accounts).

2.1. Commands

Storage gateways are managed via the globus-connect-server storage-gateway command:

globus-connect-server storage-gateway create

Create a storage gateway

globus-connect-server storage-gateway delete

Delete a storage gateway

globus-connect-server storage-gateway list

List storage gateways

globus-connect-server storage-gateway show

Show a storage gateway definition

globus-connect-server storage-gateway update

Update an existing Storage Gateway

3. Creating a Storage Gateway

We’re going to walk through creating a storage gateway, discussing the policies associated with the different aspects of the storage gateway.

3.1. Select a Connector and a Display Name

Example 1. Storage Gateway Connector and Name

We’ll use the POSIX connector for our example. We’ll call the storage gateway Example Gateway. Those will be used as positional parameters to create the storage gateway, so we’ll be using this command-line:

globus-connect-server storage-gateway create posix "Example Gateway" [OPTION]...

Note, that this is not yet a complete enough command-line to use, we’ll be adding more policy parameters to replace [OPTION]…​ in the command-line.

3.2. Configure Authentication Requirements

Globus users will authenticate with their identity providers before being able to access Globus Connect Server version 5 collections. Each storage gateway has policies that require identities from one or more providers to access storage on collections associated with the gateway. Administrators can also set policies to control how recently the authentications must have occurred, and whether the storage gateway serves protected data that requires High Assurance authentications.

3.2.1. Authentication Policies

There are three command-line options that control which user identities are allowed access to the data on a storage gateway: --domain, --authentication-timeout-mins, and --high-assurance.

The value of the --domain command-line option restricts access to users who have an identity in the given domain. This may be configured to be multiple values to allow authentication by multiple identity providers. If more than one domain is allowed, the storage gateway needs to have an identity mapping method configured to decide how to process names from the different identity namespaces. See Identity Mapping Policies for more information.

The value of the --authentication-timeout-mins command-line option defines the timeout (in minutes) after which a user will need to re-authenticate in order to access mapped collections on non high assurance storage gateways or for any data access on high assurance storage gateways. If this is not supplied, the default value of this timeout is 11 days.

The value of the --high-assurance command-line option defines whether the storage gateway manages high assurance data. If it is set, then the authentication timeout is enforced on per application sessions.

Example 2. Require a Specific Domain and Monthly Reauthentication

For our example, we’ll require users to have an identity with the example.org domain, and will use an authentication timeout of 30 days. This means that the user must authenticate at least once every month with that identity to access data.

The following command line option can be used for that:

--domain example.org \
--authentication-timeout-mins $((60 * 24 * 30))

3.3. Configure Identity Mapping

Identity mapping in Globus Connect Server version 5 controls how user’s identity is granted access to accounts on storage gateways serving collections. Each Globus user has one or more identities linked to their Globus accounts. The identity mapping feature of Globus Connect Server version 5 allows administrators to configure which identity providers they allow access, and how the user information from identity provider (user name, id, email) is used to select a local account name that is relevant to the storage gateway.

See the Identity Mapping Admin Guide, which includes some helpful recipes as well as a full specification of the documents used to configure custom identity mappings.

3.3.1. Identity Mapping Policies

Globus Connect Server v5.4 supports a flexible system for mapping user identity information in Globus to the local account needed to access data on a variety of storage systems. This includes a default mapping for cases where there is only one allowed domain, as well as pattern-based mappings and callouts to external programs for custom mapping algorithms.

Default Identity to Username Mapping

By default, if the storage gateway is configured to allow identities from a single domain, one of the following mappings are done from the user’s identity in the allowed domain to the storage gateway user namespace:

  • For connectors such as Black Pearl, Ceph, POSIX, when Globus Connect Server maps an identity to an account, it strips off the data after the @ character. So the username user@example.org is mapped to the account user.

  • Some connectors (Box, Google Cloud Storage, Google Drive) require that the account name must be qualified by a domain name. When Globus Connect Server maps an identity to an account, it retains the entire username by default, so the username user@example.org is mapped to the account user@example.org.

Note

The S3 connector uses account names qualified by a domain name, but the account name is used solely for logging purposes. The user must interact with the globus.org web interface to register an S3 key_id and secret_key with the Globus Connect Server Manager API.
Custom Identity to Username Mapping

The --identity-mapping command-line option configures a storage gateway to use either an expression based identity mapping or an external identity mapping program. See the Identity Mapping Guide for more information.

The --identity-mapping command-line option can be passed on the command-line with a few different types of data as its arguments:

--identity-mapping external:CMD

When mapping a identity to a username, Globus Connect Server invokes the command-line program CMD to map the identity. The value of the CMD string will be parsed as a shell command-line, so arguments may be included if quoted. A full description of the input, output, and arguments to the program are included in Identity Mapping Guide.

--identity-mapping file:JSON_FILE
--identity-mapping JSON

The JSON_FILE argument is a path to a file which contains a JSON document containing the mapping configuration, as described in the Identity Mapping Guide. The JSON argument is the json document itself.

Example 3. Default Identity Mapping

Since we’re only allowing a single identity provider, and our account namespace matches that of example.org, we’ll not set any identity mapping options.

Read the Identity Mapping Guide for recipes to configure custom user identity to storage account mappings, so you can manage access to your storage via Globus for users with identities from different organizations.

3.4. Configure Data Access Restrictions

Even with an account from a provider you trust, and a username that you’ve allowed access to the storage gateway, there may some areas of the filesystem that you need to restrict, either to disallow writing to data in a directory, or to completely disallow access to some directories of the file system via Globus.

3.4.1. Data Access Policies

The --restrict-paths command-line option controls access to subtrees of the data provided by the storage gateway. This is configured using the PathRestrictions document type.

Path restrictions provide a framework for administrators to constrain data access on the storage gateway. Restrictions can be set at the folder level. They may allow read, write, or deny access to data. These are absolute paths from the root of the storage gateway virtual file system.

Example 4. Restrict Access to $HOME

For this example, we’ll restrict access to the home directories of our users. Each user will only see their home directory when they list collections on this storage gateway. To enable this, we’ll create a file containing the path restrictions, and then pass that file’s path as a parameter to the --restrict-paths command-line option.

First, create the path restriction document. Create a file called path-restrictions.json with the following content:

{
    "DATA_TYPE": "path_restrictions#1.0.0",
    "read_write": ["$HOME"],
    "none": ["/"]
}

Then we’ll add it to the command-line:

--restrict-paths file:path-restrictions.json

3.5. Configure User Access Restrictions

As an administrator, you can further restrict access to the storage gateway to subset of users - either allow or deny of subset of accounts. Once a Globus account is mapped to a storage gateway account, it is further subject to this user policy, where you can explicitly allow or deny some subset of those accounts.

3.5.1. User Policies

The --user-allow and --user—​deny command-line options control which users may access data on a storage gateway. These operate on the result of the identity mapping, a user name that is in the namespace of storage gateway. This may be a user name, id, or email address based on the storage gateway requirements.

A username is allowed or denied access depending on whether the --user-allow and --user—​deny command-line option are set on a storage gateway, and whether the username is present in one or both of those policies. In general, if a username is in the value of --user—​deny it is always denied, and if a --user-allow policy is provided the username must be in the policy value in order to be allowed access.

The full set of effects of these policies are contained in the following table:

--user-allow --user—​deny result

member

-

Allowed

member

not a member

Allowed

-

-

Allowed

-

not a member

Allowed

-

member

DENIED

not a member

-

DENIED

not a member

not a member

DENIED

not a member

member

DENIED

member

member

DENIED

Note

The POSIX connector includes additional policies related to POSIX groups, which change the allow/deny handling slightly. See POSIX user policies section of the command line tool for more information.

Example 6. Disable System Users

We’ll filter out the access to the root user. This makes it so even if someone has the root@example.org identity, they won’t be granted access to the storage gateway.

--user-deny root

3.6. Create the Storage Gateway

Now that we have decided on all our policies, we’ll use the command to create the storage gateway.

Example 7. Create a Storage Gateway
% globus-connect-server storage-gateway create posix "Example Gateway" \
    --domain example.org \
    --authentication-timeout-mins $((60 * 24 * 30)) \
    --restrict-paths file:path-restrictions.json \
    --user-deny root
Storage Gateway ID: 7187a9a0-68e4-48ea-b3b9-7fd06630f8ab

This was successful and the output the ID of the new storage gateway ( 7187a9a0-68e4-48ea-b3b9-7fd06630f8ab in this case) for our reference. Note that this will always be a unique value if you run the command. If you forget the id of a storage gateway, you can always use the command globus-connect-server storage-gateway list to get a list of the storage gateways on the endpoint.

Note that this creates the storage gateway, but does not yet make it accessible via Globus and HTTPS. You’ll need to follow the steps in Create a Collection to do that.

There are many storage-gateway specific policy options to this command, they are documented in full in the reference manual.

Important

If you are using Globus Connect Server version 5 with high assurance features, you will need to set all storage gateways that have access to protected or restricted data as high assurance by passing the --high-assurance and --authentication-timeout-mins command-line options when you create a Storage Gateway. Once a storage gateway is created, the high-assurance feature can not be changed from enabled to disabled or vice versa.

4. Collections

Collections are discoverable access points that allow data to be transferred through GridFTP or HTTPS.

A collection consists of metadata about the collection, a DNS domain for access data on the collection, and configuration on the Data Transfer Nodes to access the collection data. Globus Connect Server version 5 supports two types of collections: mapped and guest.

4.1. Mapped Collection

A mapped collection allows access to data for users who have accounts in the storage gateway’s user space (or local account). The collection uses the identity mapping method configured on the storage gateway to map the Globus account of the user accessing the collection to an account in the Storage Gateway’s user space. All accesses to the data on the collection are performed using the local account and (if needed for the storage gateway) the account’s credentials.

Mapped collections can only be created by those with an administrator or owner role on the Endpoint, and can be created against any storage gateway that exists on the endpoint.

In addition, a mapped collection has optional properties to allow users to share data. The command-line options --allow-guest-collections and --sharing-restrict-paths configure the sharing option. These options are only allowed on endpoints covered under a subscription.

4.2. Guest Collection

If your endpoint is managed, you can configure policies to allow data sharing for a collection via Globus. When you enable data sharing, you allow your users to create new guest collections related to a mapped collection.

A guest collection is a collection that uses an existing mapped collection and adds the ability of a user to share access to their data on that collection. All access to the data is performed using the account of the user who created the guest collection. That user can also add entries to an access control list to allow others to access some parts of the guest collection owner’s data.

A guest collection document has additional properties mapped_collection_id and user_credential_id to describe the relationship between the collection and a mapped collection where it was created and the credential used for data access.

4.3. Commands

Collections are managed via the globus-connect-server collection command:

globus-connect-server collection create

Create a new collection.

globus-connect-server collection delete

Delete a collection.

globus-connect-server collection list

List collections.

globus-connect-server collection show

Show information about a collection.

In addition, once a collection is created, it may be viewed and edited using the Globus web application.

5. Create a Collection

With the storage gateway created, the next step is to create a mapped collection to allow access to the storage gateway’s data.

This is also where you will add metadata about the collection so prospective users can more easily find ways to access the data that they are interested in.

The command we’ll be using is globus-connect-server collection create. It requires a few positional parameters and has many options. We’ll show the format of the command, and then explain more about what those positional parameters and options mean.

Example 8. Collection Create Command Syntax

The basic syntax for this command

globus-connect-server collection create \
    STORAGE_GATEWAY_ID \
    COLLECTION_BASE_PATH DISPLAY_NAME \
    [OPTION]...

5.1. Select a Storage Gateway

We can create a mapped collection for any storage gateway configured on this endpoint. You can list the available storage gateways using the globus-connect-server storage-gateway list command. The ID column of the output is the one that contains the id to use here.

Example 9. Storage Gateway

For this example, we’ll use the output of the storage gateway command from the previous section.

7187a9a0-68e4-48ea-b3b9-7fd06630f8ab

5.2. Configure Collection Base Path

Each mapped collection has a base_path property, which is the starting directory relative to the root of the storage gateway’s virtual file system that will act as the root of the collection. A user who accesses the collection will never be able to see any files that do not exist in that directory or one of its subdirectories.

Note

When a user creates a guest collection, there is also a base_path property to that collection. That is path is interpreted relative to the base_path of the mapped collection the user used to create the collection.

The path restriction setting above already restricts the parts of the storage gateway’s virtual filesystem to the user’s $HOME directory. This means that if we select a base path outside of a user’s home directory, they will not be able to see any files or directories (except for an empty root directory) when accessing the collection.

Example 10. Base Path

Since we’ve already restricted access to $HOME, we can do a few different things with the base path.

If we expect users to use this collection to access only their home directories, it might make sense to use $HOME as the base path. Then, the root directory listing will show their home directory contents.

If we anticipated adding other path restrictions later on to allow access to other directories, (e.g. /projects), we could use / as the base path. In that case, the users can see files in their home directories, but the / directory would be otherwise empty. We’ll do that for this example.

/

Note, that this is not yet a complete enough command-line to use, we’ll be adding more policy parameters in the following sections.

5.3. Display Name

Like the storage gateway above, we need to choose a display name for this collection. The collection display name a bit more important, because your users will see this as part of the interface to accessing data on this collection.

Example 11. Display Name

Since this collection will only allow access to the home directories of users in the example.org domain, and it’s a posix collection, we’ll call it POSIX example.org home directories, so our users can easily find it.

"POSIX example.org home directories"

5.4. Metadata

A collection is only useful if your users can find it. Globus Connect Server version 5 supports a large number of metadata properties on the collection objects to make it easy to describe who is operating the collection, where it is, and any other keywords that might make sense for your organization or project.

The options which allow you to set metadata are:

--keywords string,string,…​

Comma separated list of keywords to help searches for the collection

--department DEPARTMENT

Department which operates the collection

--organization ORGANIZATION

Organization for the Collection

--contact-email EMAIL

Contact email for the Collection

--contact-info INFO

Contact info for the Collection

--info-link URL

Link to a web page containing info about the collection.

--description STRING

Description of the collection.

--public
--private

Set the Collection to be public or private (defaults to public)

Example 12. Add some metadata

We’d like to make it easy for our users to get information about our collection, so we’ll add some information about our organization, and a link to our documentation about the storage systems at our site, a description, and some keywords.

--organization 'Example organization' \
--contact-email support@example.org \
--info-link https://example.org/storage/info \
--description "Collection of home directories for the example.org's users" \
--keywords example.org,home

5.5. Sharing

We’re going to assume this is a managed endpoint, and that we want to allow our users to share data with their collaborators. We’ll need to enable the guest collections option at a minimum, and we can also put some data access restrictions to what access types users can share with others.

Example 13. Allow read-only sharing

For this example, we’ll allow users to share any path that they can access on the mapped collection, but only in a read-only mode. Recall that the guest collection can only see files visible on the mapped collection, so users will only be able to share their home directories in this example.

First, create the sharing path restriction document. Create a file called sharing_restrictions.json with the following content.

{
    "DATA_TYPE": "path_restrictions#1.0.0",
    "read": ["/"]
}

Then we’ll add it to the command-line:

--allow-guest-collections \
--sharing-restrict-paths file:sharing_restrictions.json

5.6. Create a Collection

Now that we have decided on all our policies, we’ll use the command to create the collection.

Example 14. Create a Collection
% globus-connect-server collection create \
    7187a9a0-68e4-48ea-b3b9-7fd06630f8ab \
    / collection_name \
    --organization 'Example organization' \
    --contact-email support@example.org \
    --info-link https://example.org/storage/info \
    --description "Collection of home directories for the example.org's users" \
    --keywords example.org,home \
    --allow-guest-collections \
    --sharing-restrict-paths file:sharing_restrictions.json

Collection ID: 56c3dff0-d827-4f11-91f3-b0704c53aa4c

This was successful and the output the ID of the new collection ( 56c3dff0-d827-4f11-91f3-b0704c53aa4c in this case) for our reference. Note that this will always be a unique value if you run the command. If you forget the id of a collection, you can always use the command globus-connect-server collection list to get a list of the collections on the endpoint.

You can use this value with the Globus transfer service and web application, or when editing or deleting this collection.

There are many policy-related options to this command, they are documented in full in the reference manual, but many are discussed in later sections of this document.

6. Path Restrictions

This object represents the path restrictions for a storage gateway or a sharing path restrictions for a mapped collection.

The values of each of the path lists in this object are interpreted using the POSIX pattern matching notation as described in fnmatch(3) with flags set to 0 with additional support for some special user-specific value interpolation:

~
$HOME

The user’s home directory if the storage gateway supports such a concept, / otherwise

$USER

The effective Storage Gateway-specific username that is being used for data access. For a Guest Collection, this is the username of the identity that created the Guest Collection.

These restrictions are evaluated at every data access. When evaluating restrictions, the user-specific interpolation is applied before the file name matching is evaluated.

Globus Connect Server evaluates its path restrictions from longest leading expression match to shortest. When pattern matching characters are present, they are considered as a lower priority match than a literal character, with more specific pattern characters given precedence. The precedence is thus "literal character", "bracket expression", ? (single-character wildcard), * (wildcard). Note that if multiple path restrictions apply, they are applied from longest match to shortest match. If during evaluaton, a longer match restricts to read, but a shorter match allows read-write, the result is that read-write is allowed.

These restrictions are evaluated at every data access. When evaluating restrictions, the user-specific interpolation is applied before the file name matching is evaluated.

Globus Connect Server evaluates its path restrictions from longest leading expression match to shortest. When pattern matching characters are present, they are considered as a lower priority match than a literal character, with more specific pattern characters given precedence. The precedence is thus literal character, bracket expression, ? (single-character wildcard), * (wildcard).

If multiple path restrictions apply, all matches are applied from longest to shortest, with the following rules for overriding values:

longer restriction shorter restriction result

read_write

read

read_write

read_write

none

read_write

read

read_write

read_write

read

none

read

none

read_write

none

none

read

none

7. Globus Help Resources

7.1. Documentation Website

This website (docs.globus.org) contains a wealth of information about configuring and using the Globus service. Many common issues can be resolved quickly by browsing our frequently asked questions and reading the relevant guides and how-to’s. We recommend consulting these resources first when looking for fast resolution to any issue you are having with the Globus service.

7.2. Mailing Lists

If you use Globus, then participating in one or more of the public email lists is an excellent way to keep in touch with your peers in the Globus Community. For questions about managing your Globus deployment, e.g. installing software for a Globus endpoint, configuring your firewall, and integrating your institution’s identity system, subscribe to the admin list. For other inquiries and discussions, try the user or developer lists. For more information on mailing lists and how to subscribe, click here.

7.3. Globus Support

Questions or issues that pertain to Globus Connect Server version 5 installation or to any client or service that is used in the Globus software-as-a-service (SaaS) or platform-as-a-service (PaaS) offering can be directed to the Globus support team by submitting a ticket. Subscriptions include a guaranteed support service level.

When submitting a ticket for an issue with Globus Connect Server, please include the endpoint name, a description of your issue, and screenshot/text dumps of any errors you are seeing. Please also include the output of Globus Connect Server’s self-diagnostic command, run as root, from the server hosting the endpoint:

globus-connect-server self-diagnostic

Appendix A: StorageGateway Document

A storage gateway provides the access policies for the endpoint’s connected storage systems. It is a named interface by which authorized users can create and manage collections on the connected storage system. A single storage system may be associated with multiple storage gateways, each with its own policies.

Storage gateway policies describe what type connector the storage gateway uses, the paths it allows access to, the login requirements are for the storage gateway, and the algorithm to map Globus identities to the user namespace of the storage gateway (e.g. local accounts).

Name

Type

Description

DATA_TYPE

string storage_gateway#1.0.0

Type of this document

id

string <uuid>

Unique id string for this Storage Gateway.

display_name

string

Name of the Storage Gateway.

connector_id

string <uuid>

Id of the connector type that this Storage Gateway interacts with.

high_assurance

boolean

Flag indicating if the storage_gateway requires high assurance features.

require_high_assurance (deprecated)

boolean

Alias for high_assurance.

authentication_timeout_mins

integer

Timeout (in minutes) during which a user is required to have authenticated to access files or create user credentials on this Storage Gateway.

For a high assurance Storage Gateway, this must be done within the current Globus Auth session, otherwise, the caller can perform the authentication with any application which uses Globus Auth.

authentication_assurance_timeout (deprecated)

integer

Alias for authentication_timeout_mins.

allowed_domains

array (string)

List of allowed domains. Users creating credentials or collections on this storage_gateway must have an identity in one of these domains.

identity_mappings

array ( IdentityMapping )

List of identity mappings to attempt to apply to user identities to determine what accounts are available for access.[Private]

users_allow

array (string)

List of connector-specific usernames allowed to access this Storage Gateway.[Private]

users_deny

array (string)

List of connector-specific usernames denied access to this Storage Gateway.[Private]

restrict_paths

One of { object PathRestrictions ​ }

Path restrictions within this Storage Gateway. paths are interpreted as absolute paths in the file namespace of the connector.[Private]

process_user

string

Local POSIX user the GridFTP server should run as when accessing this Storage Gateway.[Private]

load_dsi_module

string

NAme of the DSI module to load by the GridFTP server when accessing this Storage Gateway.[Private]

policies

One of { PosixStoragePolicies , , object , object , , , object , object ​ }

Connector-specific storage policies.

{
  "DATA_TYPE": "storage_gateway#1.0.0",
  "id": "fc1f3ba0-1fa4-42b2-8bb3-53983774fa5f",
  "display_name": "string",
  "connector_id": "145812c8-decc-41f1-83cf-bb2a85a2a70b",
  "high_assurance": true,
  "require_high_assurance": true,
  "authentication_timeout_mins": 30,
  "authentication_assurance_timeout": 30,
  "allowed_domains": [
    "example.com"
  ],
  "identity_mappings": [
    {
      "DATA_TYPE": "external_identity_mapping#1.0.0",
      "command": [
        "/opt/globus/bin/python",
        "/opt/globus/map-globus-identity-data"
      ]
    }
  ],
  "users_allow": [
    "user1"
  ],
  "users_deny": [
    "user2"
  ],
  "restrict_paths": {
    "DATA_TYPE": "path_restrictions#1.0.0",
    "read": [
      "/public"
    ],
    "read_write": [
      "/home",
      "/projects"
    ],
    "none": [
      "/private"
    ]
  },
  "process_user": "gcsweb",
  "load_dsi_module": "google_drive",
  "policies": {
    "DATA_TYPE": "posix_storage_policies#1.0.0",
    "groups_allow": [
      "globus"
    ],
    "groups_deny": [
      "nonglobus"
    ]
  }
}

Appendix B: Collection Document

Collections are discoverable access points that allow data to be transferred through GridFTP or HTTPS.

A collection consists of metadata about the collection, a DNS domain for access data on the collection, and configuration on the Data Transfer Nodes to access the collection data. Globus Connect Server version 5 supports two types of collections: mapped and guest.

Name

Type

Description

anyOf {

Guest Collection , Mapped Collection }

Collections are discoverable access points that allow data to be transferred through GridFTP or HTTPS.

A collection consists of metadata about the collection, a DNS domain for access data on the collection, and configuration on the Data Transfer Nodes to access the collection data. Globus Connect Server version 5 supports two types of collections: mapped and guest.

{
  "DATA_TYPE": "collection#1.0.0",
  "id": "18d367d5-45cf-4724-a53e-5a685e45c942",
  "manager_url": "https://gcs.data.globus.org/",
  "domain_name": "i-f3c83.123.globus.org",
  "high_assurance": true,
  "https_url": "https://i-f3c83.123.globus.org",
  "tlsftp_url": "tlsftp://i-f3c83.123.globus.org",
  "collection_type": "guest",
  "display_name": "Project Foo Research Data",
  "connector_id": "c8b7ab5c-595c-43c9-8e43-9e8a3debfe4c",
  "identity_id": "c8b7ab5c-595c-43c9-8e43-9e8a3debfe4c",
  "storage_gateway_id": "fc1f3ba0-1fa4-42b2-8bb3-53983774fa5f",
  "root_path": "/",
  "collection_base_path": "/",
  "default_directory": "/projects",
  "public": true,
  "force_encryption": false,
  "disable_verify": false,
  "organization": "University of Example",
  "department": "Data Science",
  "keywords": [
    "Project Foo",
    "Data Intensive Science"
  ],
  "description": "Information related to the \"Foo\" project.",
  "contact_email": "project-foo@example.edu",
  "contact_info": "+1 (555) 555-1234",
  "info_link": "https://project-foo.example.edu/info",
  "authentication_timeout_mins": 30,
  "policies": {
    "DATA_TYPE": "posix_collection_policies#1.0.0"
  },
  "user_credential_id": "1ce95432-73c7-4060-8fb2-5d61d627f164",
  "mapped_collection_id": "14326300-5a33-4387-9bb0-7f85c3dc3185"
}