API v3 - Unable to perform scope independant operations with unscoped token

This is closely related to bug 968696, and would be addressed by explicitly scoping tokens to keystone per https://blueprints.launchpad.net/keystone/+spec/service-scoped-tokens

isn't listing domain and other essential operations should be available using token scoped to admin domain? Admin domain is a domain pointed in policy.json in the rule (old syntax)
"cloud_admin": [["rule:admin_required", "domain_id:admin_domain_id"]],

The cons of this approach is that horizon doesn't support users who are assigned to domain. CLI for OpenStack doesn't support arguments to define scope for tenant in Havana, for IceHouse fix https://bugs.launchpad.net/python-openstackclient/+bug/1198171 was recently committed, not sure about what exactly is allowed now.

I'm not really sure I understand the question, the but "admin domain" is a proprietary deployment concept that keystone itself can't rely upon.

I mean that according to the https://github.com/openstack/keystone/blob/master/etc/policy.v3cloudsample.json there is a set of rules:
    "admin_required": "role:admin",
    "cloud_admin": "rule:admin_required and domain_id:admin_domain_id",
    "identity:get_domain": "rule:cloud_admin",
    "identity:list_domains": "rule:cloud_admin",
So to be able to have 'openstack cluster admin functionality '(manage domains, roles and possibly users and be able to list domains ) it's enough to:
1. Create domain which will be used as an admin domain
2. Put id of this domain to policy.json to rule "cloud_admin": "rule:admin_required and domain_id:admin_domain_id"
3. Assign user to created domain with an admin role
4. get token using created domain as a scope.
5. Now you should be able to do mentioned operations.

I didn't get what does "proprietary deployment concept" mean? All the rules that allow mentioned functionality are already in the the policy.v3cloudsample.json.

Service admin concept mentioned as a solution is much better. But if people want to get this functionality now, and considering how fast support for new keystone features is added to clients and UI, the hint with 'cloud_admin' rule can be useful enough.

In short, policy.v3cloudsample.json is not the default because of the "admin domain" concept -- it's a minor evolution of the "admin tenant" concept, which itself is a hack (see the bug & mailing list conversation on "admin-ness"). I agree that your solution sort of works, but it doesn't represent the semantics around authorization that we'd like to support and advocate.

Is this really a bug? unscoped token doesn't have any roles. So you can only invoke the operaitons which are defined as "allow all" in policy.json. List domain/user/groups requires role.

I too wonder if this is an actual bug. Is it documented somewhere that the concept of the 'unscoped_token' from v2 has been cancelled?

All operations on Keystone should be scoped, either explicitly or implicitly. However, for the unscoped/implicit case, it should not be done with an unscoped token. Unscoped tokens really are for very specific use cases, such as avoiding the need to specify a project from the WewbUI during initial project listing. They are, eseentially,a way to avoid sending the password back and forth to the Keystone server.

There is a case to be made for tokenless operations using X509 or comparable authentication that can be carried along with the request, but those will not use unscoped tokens.

This is really a feature request, and not one that I am likely to recommend we implement.

I have to agree with Adam here, unscoped tokens have a specific purpose, to get a scoped token or to auth with a web UI.

APIs in keystone should very much be protected by a scoped request. Unless a use-case is presented where using an unscoped token is much easier for operators (and equally as safe), then I'm inclined to mark this as won't fix as it does not align with the project's goal.