The Auth System 认证系统

The Auth System 认证系统

TempAuth

The auth system for Swiftis 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:

• The authentication/authorization part can be an external system or a subsystem run within Swift as WSGI middleware
• The user of Swift passes in an auth token with each request
• Swift validates each token with the external auth system or auth subsystem and caches the result
• The token does not change from request to request, but does expire

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

      1.认证/授权部分可以作为一个运行在Swift中作为WSGI中间件的外部系统或子系统

      2.Swift用户在每个请求中会附加认证令牌。

      3.Swift用外部的认证系统或者认证子系统来验证每个令牌并且缓存结果

      4.令牌不是每次请求都会变化，但是存在有效期

The token can be passedinto Swift using the X-Auth-Token or the X-Storage-Token header. Both have thesame format: just a simple string representing the token. Some auth systems useUUID 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-isback to the auth system for validation.

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

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

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

The included TempAuthalso has the concept of admin and non-admin users within an account. Adminusers can do anything within the account. Non-admin users can only performoperations per container based on the container’s X-Container-Read and X-Container-WriteACLs. Container ACLs use the “V1” ACL syntax, which looks like this: name1, name2, .r:referrer1.com, .r:-bad.referrer1.com,.rlistings 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 authsystem sets the request environ’s swift_owner key to True, the proxy willreturn additional header information in some requests, such as theX-Container-Sync-Key for a container GET or HEAD.

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

In addition to containerACLs, TempAuth allows account-level ACLs. Any auth system may use the specialheader X-Account-Access-Control to specify account-level ACLs in aformat specific to that auth system. (Following the TempAuth format is stronglyrecommended.) These headers are visible and settable only by account owners(those for whom swift_owner is true). Behavior of account ACLs is auth-system-dependent. In thecase of TempAuth, if an authenticated user has membership in a group which islisted in the ACL, then the user is allowed the access level of that ACL.

Account ACLs use the “V2”ACL syntax, which is a JSON dictionary with keys named “admin”, “read-write”,and “read-only”. (Note the case sensitivity.) An example value for the X-Account-Access-Control header looks like this: {"admin":["a","b"],"read-only":["c"]} Keys may be absent (as shown). Therecommended way to generate ACL strings is as follows:

fromswift.common.middleware.aclimport format_acl acl_data = { 'admin': ['alice'], 'read-write': ['bob', 'carol'] } acl_string= format_acl(version=2, acl_dict=acl_data)

Using the format_acl() method will ensure that JSON is encoded as ASCII(using e.g. ‘u1234’ for Unicode). While it’s permissible to manually send curl commands containing X-Account-Access-Control headers, you should exercise cautionwhen doing so, due to the potential for human error.

Within the JSONdictionary stored in X-Account-Access-Control, the keys have the following meanings:

Access Level	Description
read-only	These identities can read everything (except privileged headers) in the account. Specifically, a user with read-only account access can get a list of containers in the account, list the contents of any container, retrieve any object, and see the (non-privileged) headers of the account, any container, or any object.
read-write	These identities can read or write (or create) any container. A user with read-write account access can create new containers, set any unprivileged container headers, overwrite objects, delete containers, etc. A read-write user can NOT set account headers (or perform any PUT/POST/DELETE requests on the account).
admin	These identities have “swift_owner” privileges. A user with admin account access can do anything the account owner can, including setting account headers and any privileged headers – and thus granting read-only, read-write, or admin access to other users.

For more details, see swift.common.middleware.tempauth. Fordetails on the ACL format, seeswift.common.middleware.acl.

Users with the specialgroup .reseller_admin can operate on any account. For anexample usage please see swift.common.middleware.tempauth. If arequest is coming from a reseller the auth system sets the request environreseller_request to True. This can be used by other middlewares.

TempAuth will now allowOPTIONS requests to go through without a token.

The user starts a sessionby sending a ReST request to the auth system to receive the auth token and aURL to the Swift system.

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

KeystoneAuth

Swift is able toauthenticate against OpenStack Keystone viathe KeystoneAuth middleware.

In order to use the keystoneauth middleware the auth_token middleware from KeystoneMiddleware will need to beconfigured.

The authtoken middleware performs theauthentication token validation and retrieves actual user authenticationinformation. It can be found in the KeystoneMiddleware distribution.

The KeystoneAuth middlewareperforms authorization and mapping the Keystone roles to Swift’s ACLs.

ConfiguringSwift to use Keystone

Configuring Swift to use Keystone isrelatively straight forward. The first step is to ensure that you have the auth_token middleware installed. It can eitherbe dropped in your python path or installed via theKeystoneMiddleware package.

You need at first makesure you have a service endpoint of type object-store in Keystone pointing to your Swiftproxy. For example having this in your /etc/keystone/default_catalog.templates

catalog.RegionOne.object_store.name= Swift Service catalog.RegionOne.object_store.publicURL =http://swiftproxy:8080/v1/AUTH_$(tenant_id)scatalog.RegionOne.object_store.adminURL = http://swiftproxy:8080/catalog.RegionOne.object_store.internalURL =http://swiftproxy:8080/v1/AUTH_$(tenant_id)s

On your Swift Proxyserver you will want to adjust your main pipeline and add auth_token andkeystoneauth in your /etc/swift/proxy-server.conf like this

[pipeline:main]pipeline = [....] authtoken keystoneauth proxy-logging proxy-server

add the configuration forthe authtoken middleware:

[filter:authtoken]paste.filter_factory = keystonemiddleware.auth_token:filter_factoryidentity_uri = http://keystonehost:35357/ admin_tenant_name = serviceadmin_user = swift admin_password = password auth_uri = http://keystonehost:5000/cache = swift.cache include_service_catalog = False delay_auth_decision = True

The actual values forthese variables will need to be set depending on your situation, but in short:

• identity_uri points to the Keystone Admin service. This information is used by the middleware to actually query Keystone about the validity of the authentication tokens. It is not necessary to append any Keystone API version number to this URI.
• The admin auth credentials (admin_user, admin_tenant_name, admin_password) will be used to retrieve an admin token. That token will be used to authorize user tokens behind the scenes.
• auth_uri should point to a Keystone service from which users may retrieve tokens. This value is used in the WWW-Authenticate header that auth_token sends with any denial response.
• cache is set to swift.cache. This means that the middleware will get the Swift memcache from the request environment.
• include_service_catalog defaults to True if not set. This means that when validating a token, the service catalog is retrieved and stored in the X-Service-Catalog header. Since Swift does not use the X-Service-Catalog header, there is no point in getting the service catalog. We recommend you set include_service_catalog to False.

Note

 

The authtoken configvariable delay_auth_decision must be set to True. The default isFalse, but that breaks public access, StaticWeb, FormPost, TempURL,and authenticated capabilities requests (using Discoverability).

and you can finally addthe keystoneauth configuration. Here is a simple configuration:

[filter:keystoneauth]use = egg:swift#keystoneauth operator_roles = admin, swiftoperator

Use an appropriate listof roles in operator_roles. For example, in some systems, the role _member_ orMember is used to indicate that the user isallowed to operate on project resources.

OpenStack Service UsingComposite Tokens

Some Openstack servicessuch as Cinder and Glance may use a “service account”. In this mode, youconfigure a separate account where the service stores project data that itmanages. This account is not used directly by the end-user. Instead, all accessis done through the service.

To access the “service”account, the service must present two tokens: one from the end-user and anotherfrom its own service user. Only when both tokens are present can the account beaccessed. This section describes how to set the configuration options tocorrectly control access to both the “normal” and “service” accounts.

In this example, endusers use the AUTH_ prefixin account names, whereas services use the SERVICE_prefix:

[filter:keystoneauth]use = egg:swift#keystoneauth reseller_prefix = AUTH, SERVICE operator_roles =admin, swiftoperator SERVICE_service_roles = service

The actual values forthese variable will need to be set depending on your situation as follows:

• The first item in the reseller_prefix list must match Keystone’s endpoint (see/etc/keystone/default_catalog.templates above). Normally this is AUTH.
• The second item in the reseller_prefix list is the prefix used by the Openstack services(s). You must configure this value (SERVICE in the example) with whatever the other Openstack service(s) use.
• Set the operator_roles option to contain a role or roles that end-user’s have on project’s they use.
• Set the SERVICE_service_roles value to a role or roles that only the Openstack service user has. Do not use a role that is assigned to “normal” end users. In this example, the role service is used. The service user is granted this role to a single project only. You do not need to make the service user a member of every project.

This configuration worksas follows:

• The end-user presents a user token to an Openstack service. The service then makes a Swift request to the account with the SERVICE prefix.
• The service forwards the original user token with the request. It also adds it’s own service token.
• Swift validates both tokens. When validated, the user token gives the admin or swiftoperatorrole(s). When validated, the service token gives the service role.
• Swift interprets the above configuration as follows: * Did the user token provide one of the roles listed in operator_roles? * Did the service token have the service role as described by the

SERVICE_service_roles options.

• If both conditions are met, the request is granted. Otherwise, Swift rejects the request.

In the above example, allservices share the same account. You can separate each service into its ownaccount. For example, the following provides a dedicated account for each ofthe Glance and Cinder services. In addition, you must assign the glance_service and cinder_service to the appropriate service users:

[filter:keystoneauth]use = egg:swift#keystoneauth reseller_prefix = AUTH, IMAGE, VOLUMEoperator_roles = admin, swiftoperator IMAGE_service_roles = glance_serviceVOLUME_service_roles = cinder_service

Accesscontrol using keystoneauth

By default the only usersable to perform operations (e.g. create a container) on an account are thosehaving a Keystone role for the corresponding Keystone project that matches oneof the roles specified in the operator_roles option.

Users who have one of the operator_roles will be able to set container ACLs togrant other users permission to read and/or write objects in specificcontainers, using X-Container-Read and X-Container-Write headers respectively. In addition tothe ACL formats described here, keystoneauth supports ACLs using theformat:

other_project_id:other_user_id.

where other_project_id is the UUID of a Keystone project and other_user_id is the UUID of a Keystone user. Thiswill allow the other user to access a container provided their token is scopedon the other project. Both other_project_id and other_user_id may be replaced with the wildcard character* which will match any project or userrespectively.

Be sure to use KeystoneUUIDs rather than names in container ACLs.

Note

 

For backwardscompatibility, keystoneauth will by default grant container ACLs expressed asother_project_name:other_user_name (i.e. using Keystone names ratherthan UUIDs) in the special case when both the other project and the other userare in Keystone’s default domain and the project being accessed is also in thedefault domain.

For further informationsee KeystoneAuth

Users with the Keystonerole defined in reseller_admin_role (ResellerAdmin by default) can operate on any account. The auth system sets therequest environ reseller_request to True if a request is coming from a userwith this role. This can be used by other middlewares.

ExtendingAuth 扩展认证

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

Also, see Auth Server andMiddleware.

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