api-ref
bin
doc
manpages
saio
source
api
authentication.rst
container_quotas.rst
discoverability.rst
form_post_middleware.rst
large_objects.rst
object_api_v1_overview.rst
object_versioning.rst
temporary_url_middleware.rst
use_content-encoding_metadata.rst
use_the_content-disposition_metadata.rst
images
ops_runbook
account.rst
admin_guide.rst
apache_deployment_guide.rst
associated_projects.rst
conf.py
container.rst
cors.rst
crossdomain.rst
db.rst
deployment_guide.rst
development_auth.rst
development_guidelines.rst
development_middleware.rst
development_ondisk_backends.rst
development_saio.rst
first_contribution_swift.rst
getting_started.rst
howto_installmultinode.rst
index.rst
logs.rst
middleware.rst
misc.rst
object.rst
overview_architecture.rst
overview_auth.rst
overview_backing_store.rst
overview_container_sync.rst
overview_encryption.rst
overview_erasure_code.rst
overview_expiring_objects.rst
overview_global_cluster.rst
overview_large_objects.rst
overview_object_versioning.rst
overview_policies.rst
overview_reaper.rst
overview_replication.rst
overview_ring.rst
policies_saio.rst
proxy.rst
ratelimit.rst
replication_network.rst
ring.rst
ring_background.rst
test-cors.html
etc
examples
install-guide
swift
test
.alltests
.coveragerc
.functests
.gitignore
.gitreview
.mailmap
.manpages
.probetests
.testr.conf
.unittests
AUTHORS
CHANGELOG
CONTRIBUTING.rst
LICENSE
MANIFEST.in
README.rst
REVIEW_GUIDELINES.rst
babel.cfg
bandit.yaml
bindep.txt
requirements.txt
setup.cfg
setup.py
test-requirements.txt
tox.ini

This change is in support of Composite Tokens and Service Accounts (see http://specs.openstack.org/openstack/swift-specs/specs/in_progress/ service_token.html) During coding, minor changes were made compared to the original specification. See https://review.openstack.org/138771 for these changes. DocImpact Change-Id: I6072b4efb3a479a8e0cc2d9c11ffda5764b55e30
59 lines
2.1 KiB
ReStructuredText
59 lines
2.1 KiB
ReStructuredText
==============
|
|
Authentication
|
|
==============
|
|
|
|
The owner of an Object Storage account controls access to that account
|
|
and its containers and objects. An owner is the user who has the
|
|
''admin'' role for that tenant. The tenant is also known as the project
|
|
or account. As the account owner, you can modify account metadata and
|
|
create, modify, and delete containers and objects.
|
|
|
|
To identify yourself as the account owner, include an authentication
|
|
token in the ''X-Auth-Token'' header in the API request.
|
|
|
|
Depending on the token value in the ''X-Auth-Token'' header, one of the
|
|
following actions occur:
|
|
|
|
- ''X-Auth-Token'' contains the token for the account owner.
|
|
|
|
The request is permitted and has full access to make changes to the
|
|
account.
|
|
|
|
- The ''X-Auth-Token'' header is omitted or it contains a token for a
|
|
non-owner or a token that is not valid.
|
|
|
|
The request fails with a 401 Unauthorized or 403 Forbidden response.
|
|
|
|
You have no access to accounts or containers, unless an access
|
|
control list (ACL) explicitly grants access.
|
|
|
|
The account owner can grant account and container access to users
|
|
through access control lists (ACLs).
|
|
|
|
In addition, it is possible to provide an additional token in the
|
|
''X-Service-Token'' header. More information about how this is used is in
|
|
:doc:`../overview_backing_store`.
|
|
|
|
The following list describes the authentication services that you can
|
|
use with Object Storage:
|
|
|
|
- OpenStack Identity (keystone): For Object Storage, account is synonymous with
|
|
project or tenant ID.
|
|
|
|
- Tempauth middleware: Object Storage includes this middleware. User and account
|
|
management is performed in Object Storage itself.
|
|
|
|
- Swauth middleware: Stored in github, this custom middleware is modeled on
|
|
Tempauth. Usage is similar to Tempauth.
|
|
|
|
- Other custom middleware: Write it yourself to fit your environment.
|
|
|
|
Specifically, you use the ''X-Auth-Token'' header to pass an
|
|
authentication token to an API request.
|
|
|
|
Authentication tokens expire after a time period that the authentication
|
|
service defines. When a token expires, use of the token causes requests
|
|
to fail with a 401 Unauthorized response. To continue, you must obtain a
|
|
new token.
|
|
|