9
9
The auth system for Swift is loosely based on the auth system from the existing
10
10
Rackspace architecture -- actually from a few existing auth systems -- and is
11
11
therefore a bit disjointed. The distilled points about it are:
13
* The authentication/authorization part is outside Swift itself
13
* The authentication/authorization part can be an external system or a
14
subsystem run within Swift as WSGI middleware
14
15
* The user of Swift passes in an auth token with each request
15
* Swift validates each token with the external auth system and caches the
16
* Swift validates each token with the external auth system or auth subsystem
17
18
* The token does not change from request to request, but does expire
19
20
The token can be passed into Swift using the X-Auth-Token or the
20
21
X-Storage-Token header. Both have the same format: just a simple string
21
representing the token. Some external systems use UUID tokens, some an MD5 hash
22
of something unique, some use "something else" but the salient point is that
23
the token is a string which can be sent as-is back to the auth system for
22
representing the token. Some auth systems use UUID tokens, some an MD5 hash of
23
something unique, some use "something else" but the salient point is that the
24
token is a string which can be sent as-is back to the auth system for
26
Swift will make calls to the external auth system, giving the auth token to be
27
Swift will make calls to the auth system, giving the auth token to be
27
28
validated. For a valid token, the auth system responds with an overall
28
29
expiration in seconds from now. Swift will cache the token up to the expiration
29
time. The included devauth also has the concept of admin and non-admin users
30
time. The included Swauth also has the concept of admin and non-admin users
30
31
within an account. Admin users can do anything within the account. Non-admin
31
32
users can only perform operations per container based on the container's
32
33
X-Container-Read and X-Container-Write ACLs. For more information on ACLs, see
33
34
:mod:`swift.common.middleware.acl`
35
The user starts a session by sending a ReST request to the external auth system
36
to receive the auth token and a URL to the Swift system.
36
The user starts a session by sending a ReST request to the auth system to
37
receive the auth token and a URL to the Swift system.
42
Auth is written as wsgi middleware, so implementing your own auth is as easy
43
Swauth is written as wsgi middleware, so implementing your own auth is as easy
43
44
as writing new wsgi middleware, and plugging it in to the proxy server.
45
The current middleware is implemented in the DevAuthMiddleware class in
46
swift/common/middleware/auth.py, and should be a good starting place for
47
implementing your own auth.
49
46
Also, see :doc:`development_auth`.
56
The Swauth system is an optional DevAuth replacement included at
57
swift/common/middleware/swauth.py; a scalable authentication and
58
authorization system that uses Swift itself as its backing store. This section
59
will describe how it stores its data.
53
The Swauth system is included at swift/common/middleware/swauth.py; a scalable
54
authentication and authorization system that uses Swift itself as its backing
55
store. This section will describe how it stores its data.
61
57
At the topmost level, the auth system has its own Swift account it stores its
62
58
own account information within. This Swift account is known as
added
removed
doc/source/overview_auth.rst
