Managing Permissions

Understanding Permissions

NextGen Object Storage provides 2 levels of permissions: Account and Container.

Both permissions types are enforced on account members only, account admins always have all permissions.

Account-level permissions enforce Read (listing) and Write (creating/deleting) option for containers under an account.

Container-level permissions enforce Read (list/download) and Write (upload/delete) options for objects under a container.

Default Permissions:

An account is created with default account-level permissions that allow all account members to list/create/delete containers in the account.

After an account is created, account-level permissions can be set by a NextGen Object Storage Admin or an Account Admin.

After a container is created, container-level permissions can be set by a NextGen Object Storage Admin or an Account Admin.

Setting Account Permissions

Scope: Account Administrator

Account-level permissions are set in the Account view Details pane, and can be set globally for all users in an account or per-user.

image10

  • For global account permissions, check the desired permissions for All Members in the details pane at the bottom of the Accounts view and then click Save.

  • For per-user account permissions, click Add in the toolbar on top of the Details pane. In the Set Permissions dialogue which opens, individually select the desired permissions per user and then click Save.

Note

  • When setting permission per-user, existing global permission settings are removed.

  • When setting global permissions, existing per-user permissions are removed.

Setting Container Permissions

Scope: Account Administrator

Container-level permissions are set in the Console view Details pane, and can be set globally for all users in an account or per-user.

image11

  • For global container permissions, select the desired container in the Container pane at the top of the Console view. Then select the desired permissions in the Details pane in the All Users row or All Authenticated Members row and click Save.

  • For per-user container permissions, click Add in the toolbar on top of the Details pane. In the Set Permissions dialogue which opens, individually select the desired permissions per user and then click Save.

Note

  • When setting permission per-user, existing global permission settings are removed.

  • When setting global permissions, existing per-user permissions are removed.

Note

By making a container public (Make Public/Private button) any user can list this container’s objects (using “referral” API) even without permissions for this container.

Cross-Origin Resource Sharing (CORS)

Version: 23.09-SP1

Scope: Account Administrator

Cross-Origin Resource Sharing (CORS) is a security standard that enables servers to specify safe origins from which browsers are allowed to request resources.

CORS is an extension based on the Same-Origin Policy (SOP) that browsers use to prevent malicious applications from accessing sensitive data on domains beyond their control. SOP is a browser security feature that restricts how resources can be accessed by different web applications. It requires that a resource must be from the same origin as the web application that is attempting to access it.

SOP

For two origins to be considered the same, they must have the same domain and URI scheme. If a port is specified, then the ports of both origins must match. The URL path and query components are irrelevant for SOP purposes.

Example of SOP compliance:

  • Origin 1: https://example.com/example1/index.html

  • Origin 2: https://support.example.com/faqs.html

In this example, the scheme is https and the domain is example.com, and both are the same for both origins.

Example of SOP non-compliance:

  • Origin 1: https://example.com/example1/index.html

  • Origin 2: http://example.com/example1/index.html

    Although the domain is identical to Origin 1, the http scheme differs from https.

  • Origin 3: http://example.com:1030/example1/index.html

    Although the scheme and domain are identical to Origin 2, the specified port differs from no port specified in Origin 2.

  • Origin 4: http://examples.com:1030/example1/index.html

    Although the scheme and port are identical to Origin 3, the domain examples.com differs from example.com.

CORS

CORS enables client-side web applications that are loaded in one domain to interact with resources in a different domain. Using CORS support, you can build client-side web applications and specify the permitted cross-origin access to your resources.

To configure a bucket to allow cross-origin requests, add a CORS configuration to the bucket. See CORS configuration examples.

The CORS configuration is a set of rules on a bucket that:

  • Identifies the origins that are allowed access to the bucket

  • The HTTP methods (operations) supported for each origin, together with operation-specific information