Requests fail when no admin_token_auth middleware

[Brant Knudson]

When the admin_token_auth middleware is removed from the paste pipeline, the server responds to requests with a 500 Internal Server Error rather than the correct data.

Operations should work even without the admin_token_auth middleware

To recreate:

1) Start with devstack.

2) Reconfigure Keystone to remove admin_token_auth from the paste pipeline.

[pipeline:public_api]
#pipeline = access_log sizelimit url_normalize token_auth admin_token_auth xml_body json_body ec2_extension user_crud_extension public_service
pipeline = access_log sizelimit url_normalize token_auth xml_body json_body ec2_extension user_crud_extension public_service

[pipeline:admin_api]
#pipeline = access_log sizelimit url_normalize token_auth admin_token_auth xml_body json_body ec2_extension s3_extension crud_extension admin_service
pipeline = access_log sizelimit url_normalize token_auth xml_body json_body ec2_extension s3_extension crud_extension admin_service

[pipeline:api_v3]
#pipeline = access_log sizelimit url_normalize token_auth admin_token_auth xml_body json_body ec2_extension s3_extension service_v3
pipeline = access_log sizelimit url_normalize token_auth xml_body json_body ec2_extension s3_extension service_v3

3) Do a request using v2 admin api.

$ keystone user-list
An unexpected error prevented the server from fulfilling your request. 'is_admin' (HTTP 500)

I think the problem is that the server is assuming that is_admin will be in the context, but it's only there if the request has gone through the admin_token_auth middleware. If this is the case then the server could be changed so that is_admin in the context is optional.

Another option is to provide an alternative bit of middleware that sets the is_admin flag to False.

[Bryan Murray (bryan-murray)]

Is there any difference between a token matching the admin token from the config file versus a user having a role of cloud admin?

If yes, I would like to know why. I am new to keystone and would like to understand.

If no, it seems that there could be 2 approaches to handling is_admin:
1) have a required middleware check both the token against the config admin token and check the user against an admin role. With this approach, services can continue to check is_admin to get the same functionality.
2) stop trying to set is_admin in middleware and add a function is_admin() in the services which performs the calculation of token against config admin token and user against role.

It might be better to take approach 1 since the services handle checking for administrator permission differently right now, and the use of is_admin is spread across several files.

[Dolph Mathews (dolph)]

Bryan: Yes, the admin_token effectively bypasses identification + authentication. There is no traceability or accountability in it's use, and is exclusively intended for bootstrapping keystone before any user accounts actually exist (so it's useful for a SQL-based identity deployment, but not necessarily against a read-only LDAP deployment).

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/32976
Committed: http://github.com/openstack/keystone/commit/19fb6fc37760c3983ac9bfdd0bdeda48654533ab
Submitter: Jenkins
Branch: master

commit 19fb6fc37760c3983ac9bfdd0bdeda48654533ab
Author: Brant Knudson <email address hidden>
Date: Thu Jun 13 17:45:20 2013 -0500

    Work without admin_token_auth middleware

    Requests would fail with a 500 Internal Server Error if the
    admin_token_auth middleware was removed from the paste pipeline.
    The requests would fail because the code assumed that the context
    contained an 'is_admin' element, but that element was only in
    the context if the admin_token_auth middleware was in the
    pipeline.

    This change makes it so that if the admin_token_auth middleware
    isn't in the paste pipeline requests will not fail with a
    500 Internal Server Error.

    Change-Id: Ic064785226ee70ee475d8f72fea3c2ae6971a07f
    Fixes: bug 1190708