There are few things more useful than a set of examples when starting to work with a new API. Here are some I’ve started collecting up for my work:
The first of three articles: More. Policy
Get a token. This user has the role ‘admin’ in a project, which means they can execute admin operations.
Save the following in a file named token-request.json
{ "auth": { "identity": { "methods": [ "password" ], "password": { "user": { "domain": { "name": "Default" }, "name": "admin", "password": "freeipa4all" } } }, "scope": { "project": { "domain": { "name": "Default" }, "name": "demo" } } } }
And execute it with
export TOKEN=`curl -si -d @token-request.json -H "Content-type: application/json" http://localhost:35357/v3/auth/tokens | awk '/X-Subject-Token/ {print $2}'`
To list domains
curl -si -H"X-Auth-Token:$TOKEN" -H "Content-type: application/json" http://localhost:35357/v3/domains
Create a domain
curl -H"X-Auth-Token:$TOKEN" -H "Content-type: application/json" -d '{"domain": {"description": "--optional--", "enabled": true, "name": "dom1"}}' http://localhost:35357/v3/domains
To list users
curl -si -H"X-Auth-Token:$TOKEN" -H "Content-type: application/json" http://localhost:35357/v3/users
To create a users, create file named create_user.json file like this:
{ "user": { "default_project_id": "d0f445c3379b48f38a2ab0f17314bbf9", "description": "Description", "domain_id": "default", "email": "ayoung@redhat.com", "enabled": true, "name": "ayoung", "password": "changeme" } }
Execute it like this
curl -si -H"X-Auth-Token:$TOKEN" -H "Content-type: application/json" http://localhost:35357/v3/users -d @create_user.json
The response should look like this, with different auto-generated IDs.
{"user": {"description": "Description", "links": {"self": "http://192.168.0.2:5000/v3/users/8221b007376a40ce8459c05f90077f16"}, "enabled": true, "email": "ayoung@redhat.com", "default_project_id": "d0f445c3379b48f38a2ab0f17314bbf9", "id": "8221b007376a40ce8459c05f90077f16", "domain_id": "default", "name": "ayoung"}}
Note that in the above case the new user_id is 8221b007376a40ce8459c05f90077f16. Use that to get the user directly:
$ curl -H"X-Auth-Token:$TOKEN" -H "Content-type: application/json" http://localhost:35357/v3/users/8221b007376a40ce8459c05f90077f16 {"user": {"name": "ayoung", "links": {"self": "http://192.168.0.2:5000/v3/users/8221b007376a40ce8459c05f90077f16"}, "enabled": true, "email": "ayoung@redhat.com...", "default_project_id": "d0f445c3379b48f38a2ab0f17314bbf9", "id": "8221b007376a40ce8459c05f90077f16", "domain_id": "default", "description": "Description"}}
To figure out how to do additional operations, see the V3 Identity API.
I got the token as described, but when I try to list domains then throws up error 403 Forbidden. Any thing I need to make change in policy.json?
{“error”: {“message”: “You are not authorized to perform the requested action, identity:list_domains.”, “code”: 403, “title”: “Forbidden”}}
great! thanks a lot for putting this together!
Nice examples! On my Fedora 20 devstack system, I’ve found that $TOKEN will end up having a DOS style newline (‘cr nl’ as shown by ‘od -a’). This causes Keystone to consider the token as invalid for further requests, resulting in ‘401 Unauthorized’ responses.
To resolve this issue, you can just pass the returned token through ‘dos2unix’ like this:
export TOKEN=`curl -si -d @token-request.json -H “Content-type: application/json” http://localhost:35357/v3/auth/tokens | awk ‘/X-Subject-Token/ {print $2}’ | dos2unix`
Nice example. Thanks for the blog.
Adam,
The last link your post now returns a 404.
-Harry
Harry’s right, but here’s a link that works as of today to the v3 API (and the other versions, as well).
http://specs.openstack.org/openstack/keystone-specs/