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

Bug #1264325 reported by Florent Flament on 2013-12-26
22
This bug affects 2 people
Affects Status Importance Assigned to Milestone
OpenStack Identity (keystone)
Wishlist
Unassigned

Bug Description

When getting an unscoped token, by authenticating against Keystone
without a scope, one should be able to perform scope independant
operations (when allowed to do so). For instance, an administrator
should be able to manage domains, roles and possibly users, without
needing to specify a scope.

Unscoped token are currently not much usefull, since they don't allow
any such operation.

$ curl -s -i http://localhost:5000/v3/auth/tokens \
-H "Content-Type: application/json" \
-d '{
    "auth": {
        "identity": {
            "methods": ["password"],
            "password": {
                "user": {
                    "domain": {"name": "Default"},
                    "name": "admin",
                    "password": "YourPasswordHere"
                }
            }
        }
    }
}' | grep ^X-Subject-Token
X-Subject-Token: b8c1cd2065ce4df39cbcb6e6111f9dba
$
$ curl -s -H "X-Auth-Token: b8c1cd2065ce4df39cbcb6e6111f9dba" \
http://localhost:5000/v3/domains | python -m json.tool
{
    "error": {
        "code": 403,
 "message": "You are not authorized to perform the requested action, identity:list_domains.",
        "title": "Forbidden"
    }
}
$
$ curl -s -H "X-Auth-Token: b8c1cd2065ce4df39cbcb6e6111f9dba" \
http://localhost:5000/v3/roles | python -m json.tool
{
    "error": {
        "code": 403,
        "message": "You are not authorized to perform the requested action, identity:list_roles.",
        "title": "Forbidden"
    }
}
$
$ curl -s -H "X-Auth-Token: b8c1cd2065ce4df39cbcb6e6111f9dba" \
http://localhost:5000/v3/users | python -m json.tool
{
    "error": {
        "code": 403,
        "message": "You are not authorized to perform the requested action, identity:list_users.",
        "title": "Forbidden"
    }
}
$

Dolph Mathews (dolph) wrote :

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

Changed in keystone:
importance: Undecided → High
status: New → Triaged
Sergii Kashaba (skashaba) wrote :

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.

Dolph Mathews (dolph) wrote :

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.

Sergii Kashaba (skashaba) wrote :

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.

Dolph Mathews (dolph) wrote :

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.

Changed in keystone:
assignee: nobody → Henrique Truta (henrique-4)
Changed in keystone:
assignee: Henrique Truta (henrique-4) → nobody
Haneef Ali (haneef) wrote :

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.

Ladislav Smola (lsmola) wrote :

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?

Adam Young (ayoung) wrote :

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.

Changed in keystone:
importance: High → Wishlist
Steve Martinelli (stevemar) wrote :

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.

Changed in keystone:
status: Triaged → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers