[Havana][Domains] User Credentials invalid

asked 2014-05-07 04:26:21 -0600

TypoPhil gravatar image

updated 2014-05-16 02:31:22 -0600


I followed this to create a domain_admin for more granular admin role with access to specific projects. I did the following using a client to interact with keystone api v3:

  1. Created 2 projects
    • one for a regular user in the domain
    • a default project for the domain_admin
  2. Created the domain to use
  3. Added the domain_id to the projects
  4. Created a regular user and a domain_admin user with the domain_id provided in the create call
  5. Granted roles to users in the domain:
    • default Member role to the regular user
    • domain_admin for the designated domain_admin user
  6. Granted roles to users in the projects:
    • Member role to the regular user on it's own project
    • domain_admin role to the domain_admin on the default project and the regular users project

Having done that, I assumed, that without having altered /etc/keystone/policy.json yet, I'd be able to log in through the Horizon Dashboard using the regular User. As it has a default role, the System should allow me to login in.

Trying to get a token through the api does also no longer work:

    Auth Failed: {u'message': u'The request you have made requires authentication.', u'code': 401, u'title': u'Unauthorized'}

I tried the same as the above, only in a different order of steps first.

  1. Create the projects
  2. Create the users
  3. Granting Member roles to both users in the respective projects
    • At this point both users could login, i.e. to the Horizon Dashboard
  4. Then created the domain
  5. Updated the projects with the domain_id
    • At this point, trying to login would yield You are not authorized for any projects.
  6. Updated the Users with the domain_id
    • At this point, listing (or getting) the user, showed a column extras, that somehow contained the description and email address of the user. (The body for the update call was ok, don't know how this happend)
    • At this point, I'd get Invalid user name or password.

At that point I stopped.

Is this solely related to the fact, that anything domain related in the file /etc/keystone/policy.json has the rule admin_required? How come I'm unable to login after setting domains up to use?

Any help is much appreciated. This is still on Ubuntu 13.10 with Havana/stable.

Regards, Phil


I just replaced the policy.json file with the policy.v3cloudsample.json file from the stable/havana branch. That results in:

2014-05-12 09:02:32.473 30777 ERROR keystone.openstack.common.policy [-] Failed to understand rule admin_on_project_filter
2014-05-12 09:02:32.473 30777 TRACE keystone.openstack.common.policy Traceback (most recent call last):
2014-05-12 09:02:32.473 30777 TRACE keystone.openstack.common.policy   File "/usr/lib/python2.7/dist-packages/keystone/openstack/common/policy.py", line 475, in _parse_check
2014-05-12 09:02:32.473 30777 TRACE keystone.openstack.common.policy     kind, match = rule.split(':', 1)
2014-05-12 09:02:32.473 30777 TRACE keystone.openstack.common.policy ValueError: need more than 1 value to unpack

I'll have ...

edit retag flag offensive close merge delete


Ok, there seems to be nothing else to configure. policy.py is expecting the rule to be notated as i.e. rule:admin_or_cloud_admin. As string it can split using a colon as separator. I'll try policy.v3cloudsample.json file from the master branch. Notation of rules seems to fit there.

TypoPhil gravatar imageTypoPhil ( 2014-05-12 04:28:26 -0600 )edit

What type of token are you getting? You need to get domain scoped token to get it working.
What do you mean by I don't set domain_id for the user?

Can you also let me know how are you getting token? You have to use v3 api.

Haneef Ali gravatar imageHaneef Ali ( 2014-05-14 21:42:58 -0600 )edit

See updated question for answer. BTW, is this really the correct approach? Posting the relevant information to answer questions as an Update to the original one?

TypoPhil gravatar imageTypoPhil ( 2014-05-16 02:15:33 -0600 )edit
You are using domain scoped token


Just to make sure, are you saying that the same request works if you use default policy file and it doesn't work if u use v3cloudpolicy.  Do you get the token with default policy file?
Haneef Ali gravatar imageHaneef Ali ( 2014-05-16 07:20:43 -0600 )edit

Sorry, I don't see where my post implied that. No, with the default policy.json in place, the scoped request does not return a token.

TypoPhil gravatar imageTypoPhil ( 2014-05-19 08:11:02 -0600 )edit

1 answer

Sort by ยป oldest newest most voted

answered 2014-05-09 11:15:32 -0600

updated 2014-05-09 11:29:36 -0600

Don't use /etc/keystone/policy.json. That relies only on admin role. If you want to use domain admin concept use /etc/jkeystone/policy.v3cloudsample.json as policy.json.

You need to edit this file to suit your need. As per this file, any user who has admin role is considered "domain_admin". If that user also part of some specified domain then he is considered as "cloud_admin".

To make this work do the following

   1) Create cooule of domains and couple of users in each domain
   2) Create few projects and assign whatever role you want
   3) Assing a user "admin" role in each domain.
   4) Identity one of the domain as "cloud_admin_domain" and update that domain's domain_id as admin_domain_id in policy.json
       "cloud_admin": "rule:admin_required and domain_id:admin_domain_id",

edit flag offensive delete link more


Hello Haneef,

thanks for looking into this. Do I get this right? There's no need for a custom role to handle this? I just use the v3 specific policy file and use default roles?


TypoPhil gravatar imageTypoPhil ( 2014-05-12 01:08:44 -0600 )edit

So with the master branch file it works. Do I really have to set the domain_id hardcoded in the specified rule, like "cloud_admin": "rule:admin_required and domain_id:$MY_LONG_DOMAIN_ID"?

TypoPhil gravatar imageTypoPhil ( 2014-05-12 04:46:41 -0600 )edit

Yes. you don't need to create a custom role with v3cloudpolicy.sample and you need to hard code the domain_id of cloud_admin

Just like any sw, there are multiple ways of doing it. What I have explained above is one way of doing it with the default v3cloud policy file with minimum change.

You can avoid hardcoding domain_id by creating a custom role cloud_admin and use that in the role instead of hard coded domain_id

Ideally you want to do this with custom roles for cloud_admin and domain_admin since the role name 'admin" is overloaded in openstack. Every service use the role:"admin" to define their admin.

Haneef Ali gravatar imageHaneef Ali ( 2014-05-12 09:11:53 -0600 )edit

Hey, thanks so far, please the the update in the question for details about the problems I still have.

TypoPhil gravatar imageTypoPhil ( 2014-05-14 06:54:06 -0600 )edit

Get to know Ask OpenStack

Resources for moderators

Question Tools

1 follower


Asked: 2014-05-07 04:26:21 -0600

Seen: 1,164 times

Last updated: May 16 '14