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

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

See See SCSP Context Sub-resources for modifying 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 into in to a tenant or storage domain and bypass all restrictions that may be 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 their users. Another example is if the IDSYS for the storage domain has incorrect information within it that prevents preventing all user logins.

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

...

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

...

Presumably, after unlocking the storage domain, the owner would then re-submit submits a corrected Policy document that would allow 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.

In order to bypass the storage domain's IDSYS in favor of the root IDSYS, the 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.

In order to bypass a bucket's Policy, the 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 that 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.

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 done performed by appending @domain or +tenant qualifications onto a user or group name.

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

While there is no limit on the number of other domains that may be specified in a Policy document, all of the 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. When users and groups are fully qualified, an 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 will be that they will be is they are authorized to request "/" and will be are able to view the node status page for the back-end storage cluster. Note that : 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 will explicitly deny denies anonymous users access to "/" so that they cannot view the node status page.

...

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