not able to authenticate with user from non-default domain, v3

[Evgeniy Afonichev]

Here's steps to reproduce
1) Set up keystone endpoints to v3
2) openstack --os-identity-api-version 3 domain create mydomain
3) openstack --os-identity-api-version 3 project create myproject --domain mydomain
4) openstack --os-identity-api-version 3 user create myuser --password test --domain mydomain
5) openstack --os-identity-api-version 3 role add Member --user myuser --project myproject
6) openstack --os-identity-api-version 3 --os-username myuser --os-tenant-name myproject --os-password test user list
ERROR: cliff.app Could not find project: myproject (HTTP 401)

If I add user to tenant from default domain and try to authenticate again
openstack --os-identity-api-version 3 --os-username myuser --os-tenant-name demo --os-password test user list
ERROR: cliff.app Could not find user: myuser (HTTP 401)

Well, looking at the code I see that user is searched within default domain, not mydomain

[Dolph Mathews (dolph)]

You're also not specifying either the user's domain or the project's domain in step 6, so the client is (correctly) assuming that both exist in the default domain (which they don't, because you created them in a non-default domain). So, the server is correctly returning a 401 for the request in step 6, based on steps 1-5.

[Dolph Mathews (dolph)]

That said, I don't see a way to specify --os-user-domain-id, --os-user-domain-name, --os-project-domain-id or , --os-project-domain-name from a current checkout of openstackclient's CLI though!

[Evgeniy Afonichev (eafonichev)]

Please review this draft patch https://review.openstack.org/#/c/36500/
Could you please correct me if I'm on the wrong way

[Dean Troyer (dtroyer)]

Do we think we need the _ID versions of these options? I've never used --so-tenant-id for example.

Also, it would be nice to have a quick outline of what combinations of options are required, ie you only need --os-user-domain-name OR --os-project-domain-name, or whatever to do a non-default domain auth.

[Sergii Kashaba (skashaba)]

Hi All,
Is this issue going to be fixed? It makes not really convenient to use domain feature.

[Dolph Mathews (dolph)]

I'm happy to see just the -name options, as long as they're specified as -name, so that we can cleanly add -id later if desired.

If no --os-domain-name is specified, then the client should assume a domain ID of 'default' though.

[Bo Tang (botang)]

python-keystoneclient should also be changed in our solution of this bug.

problem: the auth/tokens request mistakenly use domain_id instead of domain_name.
solution: In keystoneclient.v3.client._do_auth() fix json construction process.
Changes:
1. python-openstackclient/openstackclient/shell.py: add default_domain parameter in method def authenticate_user(self), passing os_default_domain to client manager init.
2. python-openstackclient/openstackclient/common/clientmanager.py: pass default_domain to self._domain in __init__()
3. python-openstackclient/openstackclient/identity.py: add domain attributes when instantiating identity_client.
+ domain_name=instance._domain,
+ user_domain_name=instance._domain,
+ project_domain_name=instance._domain,
4. python-keystoneclient/keystoneclient/v3/client.py:
#if (domain_id or domain_name) and (project_id or project_name):
# raise ValueError('Authentication cannot be scoped to both domain'
# ' and project.')

The 4th change is critical but not sure if it affects others.

[Bo Tang (botang)]

patch for python-openstackclient is attached

[Steve Martinelli (stevemar)]

Also, looks like this patch is related:
https://review.openstack.org/#/c/60989/

[Bo Tang (botang)]

patch for python-keystoneclient is attached

[Dolph Mathews (dolph)]

botang: Thanks for the work you've done on this issue! Any chance you've already signed the CLA and are able to submit these patches to gerrit, or participate in the review for the change Steve linked to? https://wiki.openstack.org/wiki/HowToContribute

It'd be easier to see the context of these changes in gerrit, but I'm not sure the 4th change you referred to makes sense to me. For openstackclient, the patch that Steve linked to allows you to contextualize your username (as it's namespaced to a domain) by specifying:

  --os-user-domain-name=mydomain

On the CLI, which is passed to keystoneclient, and authentication should occur normally. The 4th change you referred to is not about authentication in a non-default domain, but about requesting a scope of authorization (and keystone only allows you to scope to either a project or domain, not both at the same time).

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/63599

[Bo Tang (botang)]

I submitted the code to gerrit as a draft: https://review.openstack.org/#/c/63599/

I think the change Steve linked to can also fix this bug. But it also requires the 4th change in my solution as I tested it.

For the 4th change in my solution, I added the OS_DEFAULT_DOMAIN value from the CLI to domain_name so that the "scope to both domain and project" error is triggered since the request is scoped with the target project already. This error trigger is correctly.

Another solution could be passing the domain value through some new CLI parameters such as OS_PROJECT_DOMAIN_NAME / OS_PROJECT_DOMAIN_ID so that the scope of project is passed from the CLI to the keystone server in the request. For this solution, keystone server should support the project domain scope accordingly. Please refer to this change: https://review.openstack.org/#/c/63602/. Thanks!

[Bo Tang (botang)]

Fix added in Paul Belanger's patch: https://review.openstack.org/#/c/60989/3

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/60989
Committed: https://git.openstack.org/cgit/openstack/python-openstackclient/commit/?id=420b10ee6dc8c40a7936001381080e4b6628e900
Submitter: Jenkins
Branch: master

commit 420b10ee6dc8c40a7936001381080e4b6628e900
Author: Paul Belanger <email address hidden>
Date: Mon Dec 9 20:01:04 2013 -0500

    Add support for specifying custom domains

    Add the ability to pass user_domain_id / user_domain_name, domain_id
    / domain_name, and project_domain_id / project_domain_name to keystone.
    These parameters are the first step needed to getting multi-domain
    support working via the CLI.

    Closes-Bug: #1198171
    Change-Id: I81a8534913978ff1cce01ec02741ae477e8c5fa4
    Signed-off-by: Paul Belanger <email address hidden>
    Signed-off-by: Bo Tang <email address hidden>