Requests fail when no admin_token_auth middleware

Bug #1190708 reported by Brant Knudson on 2013-06-13
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Identity (keystone)
High
Brant Knudson

Bug Description

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.

Brant Knudson (blk-u) on 2013-06-13
Changed in keystone:
assignee: nobody → Brant Knudson (blk-u)
Brant Knudson (blk-u) on 2013-06-13
description: updated
description: updated
Dolph Mathews (dolph) on 2013-06-13
Changed in keystone:
importance: Undecided → High
status: New → Triaged
Bryan Murray (bryan-murray) wrote :

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) wrote :

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).

Changed in keystone:
status: Triaged → In Progress

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

Changed in keystone:
status: In Progress → Fix Committed
Thierry Carrez (ttx) on 2013-07-17
Changed in keystone:
milestone: none → havana-2
status: Fix Committed → Fix Released
Thierry Carrez (ttx) on 2013-10-17
Changed in keystone:
milestone: havana-2 → 2013.2
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers