The Auth System 认证系统


TempAuth  

The auth system for Swift is loosely based on the auth system from the existing Rackspace architecture – actually from a few existing auth systems – and is therefore a bit disjointed. The distilled points about it are:

Swift的认证系统松散地基于已存在的Rackspace架构的认证系统—实际上来自于一些已存在的认证系统—所以有些不连贯。关于此认证系统的要点有以下4点:

  • The authentication/authorization part can be an external system or a subsystem run within Swift as WSGI middleware
  • 认证/授权部分可以作为一个运行在Swift中作为WSGI中间件的外部系统或子系统
  • The user of Swift passes in an auth token with each request
  • Swift用户在每个请求中会附加认证令牌。
  • Swift validates each token with the external auth system or auth subsystem and caches the result
  • Swif用外部的认证系统或者认证子系统来验证每个令牌并且缓存结果
  • The token does not change from request to request, but does expire
  • 令牌不是每次请求都会变化,但是存在有效期

The token can be passed into Swift using the X-Auth-Token or the X-Storage-Token header. Both have the same format: just a simple string representing the token. Some auth systems use UUID tokens, some an MD5 hash of something unique, some use “something else” but the salient point is that the token is a string which can be sent as-is back to the auth system for validation.

令牌可以通过使用X-Auth-Token或者X-Storage-Token头部被传入Swift。两者都有相同的格式:仅使用简单的字符串来表示令牌。一些认证系统使用UUID令牌,一些使用唯一的MD5哈希值,一些则使用其它的方法,不过共同点是令牌是可以发送回认证系统进行证实有效性的字符串。

Swift will make calls to the auth system, giving the auth token to be validated. For a valid token, the auth system responds with an overall expiration in seconds from now. Swift will cache the token up to the expiration time.

Swift将会调用认证系统,给出要验证的认证令牌。对于一个正确的令牌,认证系统回应一个从当前开始的总有效期秒数。Swift将会缓存令牌直到有效期结束。

The included TempAuth also has the concept of admin and non-admin users within an account. Admin users can do anything within the account. Non-admin users can only perform operations per container based on the container’s X-Container-Read and X-Container-Write ACLs. For more information on ACLs, see swift.common.middleware.acl.

其包含的TempAuth,对于account而言,也有admin和non-admin用户的概念。admin用户拥有账号的所有操作权限。non-admin用户仅可以基于每个容器执行基于容器的X-Container-Read and X-Container-Write的访问控制列表进行操作。对于更多关于ACLs的信息,参见swift.common.middleware.acl

Additionally, if the auth system sets the request environ’s swift_owner key to True, the proxy will return additional header information in some requests, such as the X-Container-Sync-Key for a container GET or HEAD.

此外,如果认证系统设置request environ的swift_owner键为True,该代理服务器将在某些请求中返回额外的头部信息,诸如用于容器的GET或HEAD的X-Container-Sync-Key。

The user starts a session by sending a ReST request to the auth system to receive the auth token and a URL to the Swift system.

用户通过发送一个ReST请求到认证系统来接受认证令牌和一个URL到Swift系统来开始会话。

Extending Auth  扩展的认证

TempAuth is written as wsgi middleware, so implementing your own auth is as easy as writing new wsgi middleware, and plugging it in to the proxy server. The KeyStone project and the Swauth project are examples of additional auth services.

Also, see Auth Server and Middleware.

TempAuth被作为wsgi中间,因此实现你自己的认证系统就如同写一个新的wsgi中间件一样容易,然后把它安装到代理服务器上。KeyStone和Swauth项目是另外认证服务器的例子。也可以参见 Auth Server and Middleware.


转自:http://www.cnblogs.com/yuxc/archive/2011/10/26/2203908.html

你可能感兴趣的:(中间件,REST,服务器,System,token,rackspace)