Keystone v3 token validation locked to default domain

asked 2014-10-26 06:28:23 -0600

muran gravatar image

In keystone/token/providers/, method assert_default_domain, there is a condition raised: if calling script AND the used token are both using version V3 AND the token is not authed against the default domain. I can't see the logic in this as since V3 we can create projects and users inside a domain to further isolate them. Why would we want to then restrict services using V3 tokens to only use default domain?

This became as issue for me after upgrading to Juno since Nova now tries to auth using V3 tokens and fails since I use different domains for certain users.

edit retag flag offensive close merge delete


I can add that the Juno issue was solved by entering the following parameter in config file /etc/nova/api-paste.ini :

"auth_version = v3.0"

The original question regarding why anyone would like to lock down any domains outside the default domain still stands.

muran gravatar imagemuran ( 2014-10-26 14:20:55 -0600 )edit

1 answer

Sort by ยป oldest newest most voted

answered 2014-10-26 15:19:29 -0600

I don't think anything is locked in keystone. V3 tokens can't be validated using V2, but V2 can be validated against V3. Tokens are backward compatible and not forward compatible. So if you are validating against V2, it has to pass the assertion that the token should be to part of "default" domain since in V2 we only have "default" domain.

I don't think you need to add auth_version. paste.ini uses keystonemiddleware in Juno which by default uses v3. If your paste.ini is configured to use keystoneclient, then it will default to v2.0

edit flag offensive delete link more


Thanks a lot for the answer. Things are a bit more clear now.

muran gravatar imagemuran ( 2014-10-27 02:18:47 -0600 )edit

Get to know Ask OpenStack

Resources for moderators

Question Tools


Asked: 2014-10-26 06:28:23 -0600

Seen: 298 times

Last updated: Oct 26 '14