Requests fail when no admin_token_auth middleware
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Identity (keystone) |
Fix Released
|
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:
#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:
#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.
Changed in keystone: | |
assignee: | nobody → Brant Knudson (blk-u) |
description: | updated |
description: | updated |
Changed in keystone: | |
importance: | Undecided → High |
status: | New → Triaged |
Changed in keystone: | |
status: | Triaged → In Progress |
Changed in keystone: | |
milestone: | none → havana-2 |
status: | Fix Committed → Fix Released |
Changed in keystone: | |
milestone: | havana-2 → 2013.2 |
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.