SwiftStack Auth

A fast flat-file is deployed on each node with hashed passwords. Users may be added, changed, or deleted via Controller web interface or REST API, without restarting the proxy server. Great for application development, where there are a relatively fixed number of accounts on the clusters.

SwiftStack Authentication and SwiftStack Authorization are installed on all clusters managed by SwiftStack by default and cannot be removed. It is the auth-of-last-resort for any cluster.

../../_images/swiftstack-authentication.png ../../_images/swiftstack-authorization.png

Configuration

Storage Users can be added / edited / deleted on the Controller by navigating to the cluster, followed by clicking on 'Manage Cluster' and 'Manage Storage Accounts'.

For more information on the relevant parts of the REST API see User and User Database Deployment Job.

Changes made via either the web interface or the REST API are reloaded approximately 15 seconds after they are pushed to the cluster. The reload time can be modified in the SwiftStack Authentication middleware page.

Token Expiration

Once a token has been issued, it will continue to function even after changing the password or deleting the user. The token will expire when it reaches the key cache lifetime (default 1 day). The token lifetime can be modified on the SwiftStack Authorization middleware page.

If it becomes necessary to expedite this process, the command service memcached restart may be issued as root on all of the nodes running proxy-servers. This may be all nodes in the cluster for small clusters.

For more targeted token expiration, SwiftStack Auth provides an endpoint for removing a single user's token. Making a DELETE request to the endpoint /auth/v1.0/users/<username>/token with a valid auth token for a superuser will immediately expire that user's token. This endpoint will return a 204 if successful.

Account Disablement

An Account can be disabled in order to prevent all traffic to and from that Account until it is re-enabled. This allows you to temporarily "shut off" an Account without having to delete its data or change any ACLs set on individual containers within.

To disable an Account, make a POST request to the endpoint /auth/v1.0/accounts/<account name>/disable with a valid auth token for a superuser. To re-enable an Account, use the sister endpoint /auth/v1.0/accounts/<account name>/enable. Both endpoints return 204 if successful. Note that hitting the enable endpoint on an Account that has not previously been disabled is harmless.

Using Proxies to Make Clients Region-Aware

While clusters generally only have one API hostname used in the auth URL and storage URLs, being able to use another DNS name might sometimes be desirable. One common example would be distributed, multi-region clusters, where being able to address a certain region's proxy servers by a specific API hostname might be beneficial. In the event that multiple DNS-names are used to target Swift proxy servers in separate Regions, set the override_storage_hosts setting on the SwiftStack Authorization page to True, in order to cause SwiftStack Auth to return storage URLs with hostnames that match the auth URL used.

For example, if you have a cluster spanning two regions, east and west, you might want to have two DNS names for the API hostnames mapped to the proxy servers in those regions. Your API hostname may be swift.example.com with DNS entries for east.swift.example.com and west.swift.example.com.

User Accounts vs Swift Storage Accounts

The SwiftStack Controller allows you to define up to 4,096 User Accounts per cluster. Generally, User Accounts on the SwiftStack Controller translate 1:1 with Swift Storage Accounts on the Swift Cluster, but there are some mechanisms for decoupling this relationship in order to increase the number of Swift Storage Accounts available on the cluster.