The root Policy configuration is stored in the policy.json file on the Gateway server's disk so it is always available and so an administrator can always modify it. Combined with an administrative login the cluster administrator cannot be locked out of the storage cluster.

Important

The root Policy document must be synchronized across all servers when more than one Gateway server is deployed.

See Defined ETC Documents for modifying a Policy for a tenant, storage domain, or bucket through the management API.

See SCSP Context Sub-Resources for modifying the policy sub-resource for a domain or bucket through storage API.

Administrative Override

The Gateway's access control mechanism has a provision to allow cluster administrators to log in to a tenant or storage domain and bypass all restrictions contained within that tenant's or domain's policy sub-resource. This can be used to access content where the owner mistakenly cut-off all access and locked out users. Another example is if the IDSYS for the storage domain has incorrect information within preventing all user logins.

The cluster administrator performs an administrative bypass request by putting an exclamation point "!" before and an at sign "@" after the username. The form of the user name portion of the login is: "!" + name + "@"

This instructs Gateway to use only the root IDSYS and root Policy documents when looking up the user and when evaluating whether an action is allowed. Any idsys or policy sub-resource associated with the tenant, storage domain, or buckets are ignored.

This example logs in as the user named admin and blanks the Policy document on the marketing.example.com domain so only the owner identified by the X-OwnerMeta header of the domain object is allowed to operate in the domain.

curl -u '!admin@:adminpw' -X PUT 
	-H 'Content-type: application/json' 
	-d '' 'http://DOMAIN/?policy'

Presumably, after unlocking the storage domain, the owner re-submits a corrected Policy document allowing the proper user access for the domain's content.

Domain IDSYS and Bucket Policy Overrides

Along the lines of the administrative override, Gateway provides a mechanism for accessing a storage domain by bypassing either the domain's IDSYS or a bucket's Policy.

The user name for the request uses the form: user + "@". For example "psmith@" to bypass the storage domain's IDSYS in favor of the root IDSYS. Requests performed using user names in the form "user@" are still subject to the domain and bucket Policy. Logins in this form only affect the authentication source for users.

The user name for the request uses the form: "!" + user, such as "!psmith" or "!psmith@other.com" to bypass a bucket's Policy. Requests of this form are authenticated using a domain IDSYS and are still subject to the domain Policy. This form of login can be used by the domain administrator to modify a the bucket Policy for another user's bucket. Notice this override also works when the domain owner is from another tenant domain.

User Name Login Formats

These are the meanings for the different user name formats used to authenticate with Gateway.

User Name	Effect	Restrictions

User Name	Effect	Restrictions
user	Use this domain's IDSYS and domain + bucket Policy sub-resource.	User must be able to log in to this domain's IDSYS.
user@otherdomain	Use other domain's IDSYS and this domain + bucket Policy sub-resource.	Other domain must exist in same storage cluster as this domain. User must be able to log in to other domain's IDSYS.
user+othertenant	Use other tenant's IDSYS and this domain + bucket Policy sub-resource	Other tenant must exist in same storage cluster as this domain. User must be able to log in to other tenant's IDSYS.
!user	Use this domain's IDSYS and domain Policy; ignore any bucket Policy.	Only domain owner can use this.
!user@otherdomain	Use other domain's IDSYS and this domain's Policy; ignore any bucket Policy.	Only domain owner can use this; owner is from another domain.
!user+othertenant	Use other tenant's IDSYS and this domain's Policy; ignore any bucket Policy.	Only domain owner can use this; owner is from another tenant.
user@	Use root IDSYS (ignore domain IDSYS) and use domain + bucket Policy sub-resource.	User must be able to log in to root IDSYS.
!user@	Use root IDSYS (ignore domain IDSYS) and root Policy (ignore domain + bucket Policy sub-resource).	User must be able to log in to root IDSYS.

Cross-Tenant Access Control

The access control policy evaluation in Gateway allows for the specification of users and groups that exist in other tenants and other storage domains within the Swarm cluster. This is performed by appending @domain or +tenant qualifications onto a user or group name.

See "Qualification of User/Group Names" in IDSYS Document Format for a full explanation for user and group qualification.

While there is no limit on the number of other domains specified in a Policy document, all tenants and storage domains must exist within the same storage cluster.

Applications should not use @domain and +tenant qualifications unless the users and groups to which the principals refer are actually outside of the storage domain or tenant in which the policy resides. An IDSYS must exist within the referenced tenant or storage domain when users and groups are fully qualified.

Swarm Node Status Page Visibility

The Swarm node status page of the legacy Admin Console is presented in response to a "GET /" request. If access to the resource "/*" is granted to anonymous or any user, the result is they are authorized to request "/" and are able to view the node status page for the back-end storage cluster. Note: due to connection pooling done by the Gateway, there is no way to specify which storage node's status page is returned on a request.

The following addition to the policy for the domain explicitly denies anonymous users access to "/" so they cannot view the node status page.

...
{
  "Effect": "Deny",
  "Sid": "AdminPage",
  "Principal": {
    "anonymous": [
      "*"
    ]
  },
  "Action": [
    "GetObject"
  ],
  "Resource": "/"
}, ...

By changing the principal, the previous policy example can be adapted to deny access to the node status page for any user or group.

Swarm Documentation

Modifying Policies