issues of updating user via keystone rest api

Bug #1201251 reported by Lijun Jiang on 2013-07-15
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
OpenStack Identity (keystone)
Medium
Ya Hong Du

Bug Description

We found two problems related to updating user via keystone.

(1) Via, the instruction of updating user on, http://docs.openstack.org/api/openstack-identity-service/2.0/content/POST_updateUser_v2.0_users__userId__.html

It is required POST action to update the existing user email, name, or description.

Via my verification, POST to update existing user caused
{
    "error": {
        "message": "The resource could not be found.",
        "code": 404,
        "title": "Not Found"
    }
}

The detailed for this test is,
[root@lijunj ~]# curl -i http://localhost:35357/v3/users/fee07a4ebc014744b31564835b715aa1 -X POST -H "Content-Type: application/json" -H "Accept: application/json" -H "X-Auth-Token: ADMIN" --data '
> {
> "user": {
> "id": "fee07a4ebc014744b31564835b715aa1",
> "description": "v3 keystone user test",
> "email": "none@",
> "enabled": true
> }
> }'
HTTP/1.1 404 Not Found
Vary: X-Auth-Token
Content-Type: application/json
Content-Length: 93
Date: Mon, 15 Jul 2013 02:23:44 GMT

{"error": {"message": "The resource could not be found.", "code": 404, "title": "Not Found"}}

I ensure the id fee07a4ebc014744b31564835b715aa1 user which is exisitng already in environment. Below is the output of listing v3/users/fee07a4ebc014744b31564835b715aa1
--List user
[root@lijunj ~]# curl -i http://localhost:35357/v3/users/fee07a4ebc014744b31564835b715aa1 -X GET -H "Content-Type: application/json" -H "Accept: application/json" -H "X-Auth-Token: ADMIN"
HTTP/1.1 200 OK
Vary: X-Auth-Token
Content-Type: application/json
Content-Length: 349
Date: Mon, 15 Jul 2013 02:24:51 GMT

{"user": {"aa": "144442", "name": "test", "bb": "23", "debug-wrongattribute": "12345", "cc": "45", "enabled": true, "links": {"self": "http://localhost:5000/v3/users/fee07a4ebc014744b31564835b715aa1"}, "id": "fee07a4ebc014744b31564835b715aa1", "email": "<email address hidden>", "debug_wrongattribute": "12345", "domain_id": "default", "tenantId": ""}}

The user fee07a4ebc014744b31564835b715aa1 was created for testing.

We may discuss this document correction-ability. And, POST can not be used for updating user, but PUT action can.

(2) Document in http://docs.openstack.org/ does mention, updating user can not support to refresh a user tenant id/ project id. And "keystone user-update" command is designed not to allow to have any parameter to refresh tenant-id / project-id of a user. But REST API keeps silent for any clients attempt to change a existing user tenant id or project id. From my test verification, in spite of changing successfully tenant/project id for a existing user, the user still belongs to the original tenant / project. That means, updating tenant / project id for a user is invalid.

--Create user
curl -i http://localhost:35357/v2.0/users/ -X POST -H "Content-Type: application/json" -H "X-Auth-Token: ADMIN" --data '
{
    "user": {
        "name": "li-03",
        "description": "v2.0 keystone user test",
        "email": "none@",
        "tenantId": "ccaf7621482a41ce91d3ee824ff7c959",
        "password": "passw0rd",
        "enabled": true
    }
}'
Response:
{"user": {"description": "v2.0 keystone user test", "name": "li-03", "enabled": true, "email": "none@", "id": "00027b03821f4b7590a1a94f865a61ff", "tenantId": "ccaf7621482a41ce91d3ee824ff7c959"}}

-- List the tenant users.
curl -i http://localhost:35357/v2.0/tenants/ccaf7621482a41ce91d3ee824ff7c959/users -X GET -H "Content-Type: application/json" -H "X-Auth-Token: ADMIN"

{"users": [{"name": "sceagent", "id": "07d544b772ce4ab18592d165cea9b8da", "tenantId":
....//The content is not important. li-03 is in tenant ccaf7621482a41ce91d3ee824ff7c959 already.
 {"name": "li-03", "description": "v2.0 keystone user test", "enabled": true, "email": "none@", "id": "00027b03821f4b7590a1a94f865a61ff", "tenantId": "ccaf7621482a41ce91d3ee824ff7c959"}]}

--Update user. Used anther tenant id inside, and rest api does not throw exception.
curl -i http://localhost:35357/v2.0/users/00027b03821f4b7590a1a94f865a61ff -X PUT -H "Content-Type: application/json" -H "X-Auth-Token: ADMIN" --data '
{
    "user": {
        "name": "li-03",
        "description": "v2.0 keystone user test 01",
        "email": "none@",
        "tenantId": "e0cdb35aa15d45f998c308eb78407513",
        "password": "passw0rd",
        "enabled": true
    }
}'

Response:
{"user": {"description": "v2.0 keystone user test 01", "name": "li-03", "extra": {"tenantId": "e0cdb35aa15d45f998c308eb78407513", "description": "v2.0 keystone user test 01", "email": "none@"}, "enabled": true, "email": "none@", "id": "00027b03821f4b7590a1a94f865a61ff", "tenantId": "e0cdb35aa15d45f998c308eb78407513"}}

--List tenant e0cdb35aa15d45f998c308eb78407513 user
curl -i http://localhost:35357/v2.0/tenants/e0cdb35aa15d45f998c308eb78407513/users -X GET -H "Content-Type: application/json" -H "X-Auth-Token: ADMIN"

Response:
{"users": []}

The user was not updated to add into e0cdb35aa15d45f998c308eb78407513.

From above, we can not upate user to change a existing user tenant/project. Is it good way we add the tight 'assert'/judgement for any attemption of updating user tenantId property?

Brad Figg (brad-figg) on 2013-07-15
Changed in linux (Ubuntu):
status: New → Incomplete
Lijun Jiang (lijunjbj) on 2013-07-15
affects: linux (Ubuntu) → keystone
Dolph Mathews (dolph) wrote :

I'm wondering if this is a recent doc bug? Need to research git history before attempting a "fix" in the implementation. Filing as low in keystone because this API is deprecated in favor of v3 anyway.

Changed in keystone:
importance: Undecided → Low
status: Incomplete → Triaged
Lijun Jiang (lijunjbj) wrote :

I route the bug to keystone. And change the bug status to new.

description: updated
Changed in keystone:
status: Triaged → New
Lijun Jiang (lijunjbj) wrote :

@Dolph Mathews (dolph)
Hi, Dolph,

Just, I moved the bug status from incomplete to new at the nearly time you were adding comments / changing the status for the bug. My action accidentally covered some of you setting. If the bug status should be triage, you pls set it again. Thank you.

Dolph Mathews (dolph) on 2013-07-17
Changed in keystone:
status: New → Triaged
kaitian521 (kaitian521) on 2013-08-08
tags: added: update
Changed in keystone:
status: Triaged → Confirmed
kaitian521 (kaitian521) wrote :

I think it is necessary to fix this problem, we can not change tags other than "name", "password", "email" and "enabled"

Dazhao Yu (dzyu) on 2013-08-12
Changed in keystone:
assignee: nobody → Dazhao Yu (dzyu)

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

Changed in keystone:
status: Confirmed → In Progress
Henry Nash (henry-nash) wrote :

Surely isn't the actual bug that our code does not support changing the default_project_id? So rather than add code to check we are not trying to change it.....we should add the code that supports it. This would involve calling the assignment backend to remove the member role from the old default project and adding it into the new one.

Dazhao Yu (dzyu) wrote :

Henry, thanks for your comments.

Firstly, I want to say sorry, since I miss the bug point.

The bug have two part need to fix:

1, The documentation need to modify -- http://docs.openstack.org/api/openstack-identity-service/2.0/content/POST_updateUser_v2.0_users__userId__.html, since update should use "PUT" method, if use "POST" method, we will got error. I do not know how to update the documentation, can you give me some info about it.

2, Use OpenStack CLI command----'keystone help update-user', we can see we can only update 'name', 'email' and 'enabled', for the other property, we can not to update, but from rest api, we can change any property expect 'id', such as change the tenantId, even one no-existed tenantId or property. We should to make the code change to make sure REST API has same restrict with CLI command.

Morgan Fainberg (mdrnstm) wrote :

As I posted on the review, I'll echo the sentiment here. I think that Henry is correct in that the correct fix would be to back-fill the code to support changing the default project id instead of restricting down what properties can be changed.

kaitian521 (kaitian521) wrote :

I think so, a new patch is submited, please review it

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

Changed in keystone:
assignee: Dazhao Yu (dzyu) → Ya Hong Du (yahongdu)
Dolph Mathews (dolph) on 2013-09-04
Changed in keystone:
importance: Low → Medium
Dolph Mathews (dolph) wrote :

The second issue described here was also reported in bug 1226475

Changed in keystone:
assignee: Ya Hong Du (yahongdu) → Morgan Fainberg (mdrnstm)
Changed in keystone:
assignee: Morgan Fainberg (mdrnstm) → Ya Hong Du (yahongdu)
Changed in keystone:
assignee: Ya Hong Du (yahongdu) → Morgan Fainberg (mdrnstm)
Changed in keystone:
assignee: Morgan Fainberg (mdrnstm) → Ya Hong Du (yahongdu)
Changed in keystone:
assignee: Ya Hong Du (yahongdu) → Morgan Fainberg (mdrnstm)

Reviewed: https://review.openstack.org/46207
Committed: http://github.com/openstack/keystone/commit/dda19c3977cd12bd6694a3bc932539ca2b08aee9
Submitter: Jenkins
Branch: master

commit dda19c3977cd12bd6694a3bc932539ca2b08aee9
Author: Morgan Fainberg <email address hidden>
Date: Thu Sep 12 00:11:45 2013 -0700

    Cleanup of tenantId, tenant_id, and default_project_id

    This patchset normalizes the use of tenantId, tenant_id, and
    default_project_id across the Identity backend. This includes
    making default_project_id no longer part of the "extra" json blob
    on the user object and migrating all "tenantId" "tenant_id" and
    "default_project_id" into the new column (SQL).

    In the LDAP driver, None is set as the mapping for
    default_project_id. This means that use of default_project_id with
    LDAP Identity will require an explicit mapping to be defined by the
    cloud operator.

    "default_project_id" remains (by default) configured to be in the
    "ignore" attributes for the LDAP driver, so 'tenantId' and
    'default_project_id' will not be saved on the user_object during
    update or create unless Keystone is explicitly configured to do so.

    closes-bug: 1219739
    closes-bug: 1226475
    related-bug: 1201251
    Change-Id: I07f9dfe111646884ac5efd42fc8c2974188b3b94

Changed in keystone:
assignee: Morgan Fainberg (mdrnstm) → Ya Hong Du (yahongdu)
kaitian521 (kaitian521) wrote :

I will abondoned the previois patch, please review this one :

https://review.openstack.org/#/c/47982/1

Changed in keystone:
assignee: Ya Hong Du (yahongdu) → Dolph Mathews (dolph)
Dolph Mathews (dolph) on 2013-09-24
Changed in keystone:
assignee: Dolph Mathews (dolph) → Ya Hong Du (yahongdu)

Reviewed: https://review.openstack.org/42826
Committed: http://github.com/openstack/keystone/commit/7f42af363be92c6e4a46cfb3ff1a279933fc9299
Submitter: Jenkins
Branch: master

commit 7f42af363be92c6e4a46cfb3ff1a279933fc9299
Author: YaHong Du <email address hidden>
Date: Tue Sep 24 14:40:39 2013 +0800

    Add user to project if project ID is changed

    When an user updates project ID, it is necessary to make sure
    the new tenant is available.

    Remove the member role from the old tenant.

    Add the member role to the new tenant.

    Fixes bug 1201251

    Change-Id: I0c2c8971039f567180fd910e959e4a1f0574034d

Changed in keystone:
status: In Progress → Fix Committed
Thierry Carrez (ttx) on 2013-10-02
Changed in keystone:
milestone: none → havana-rc1
status: Fix Committed → Fix Released

I am out of the office until 10/08/2013.

I am taking national day holiday. come back at 10.8. if urgent thing, pls
contact me. 86-10-18910391807

Note: This is an automated response to your message "[Bug 1201251] Re:
issues of updating user via keystone rest api" sent on 10/02/2013 19:29:59.

This is the only notification you will receive while this person is away.

Thierry Carrez (ttx) on 2013-10-17
Changed in keystone:
milestone: havana-rc1 → 2013.2
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers