To be a bit more succinct, if I PATCH existing Keystone JSON documents
(projects, roles, users, etc) with my own custom JSON attributes, can I expect
this to be a safe practice?
Meaning, I'd like to add my own custom attributes and be able to query them
back at a later time when I look up the user or verify the authentication token.
Is this a behavior that we can count on working in the future?
If it is an appropriate way to add the metadata we want, are there naming
conventions we must preserve in our custom attributes to avoid name collisions
in the future?
Thank you very much for your time, help, and consideration,
-PG
-----Original Message-----
From: Phillip Guerin
Sent: Thursday, May 15, 2014 4:16 PM
To: 'openst...@lists.openstack.org'
Subject: [Openstack] [Keystone] Extending Keystone JSON documents with custom
attributes, safe?
Hello,
We're working on a project that uses a REST interface that exposes a set of
APIs to our internal systems. We'd like to leverage the Keystone data models
for our own fine grained authorization by adding our own custom attributes to
Keystone 'projects', 'users', etc.
For example:
"user": {
"domain": {
"id": "1789d1",
"links": {
"self": "http://identity:35357/v3/domains/1789d1";
},
"name": "example.com"
},
"id": "0ca8f6",
"links": {
"self": "http://identity:35357/v3/users/0ca8f6";
},
"name": "Joe"
--------------------------------------------------------------------------------
"sandvine": {
"authorization": {
"requests": ["url", "url?fields=a,b,c"]
"attributes": {
"obfuscation": ["attr1"]
}
}
"accounting": {
}
}
--------------------------------------------------------------------------------
}
While I've done some simple tests and it essentially works, is this procedure
of PATCHing Keystone user/role/etc... documents acceptable practice from your
point of view?
Is this a behaviour that we can count on working in the future?
If it is an appropriate way to add the metadata we want, are there naming
conventions we must preserve in our custom attributes to avoid name collisions
in the future?
While this works on the direct objects I update, I don't see my custom fields
when I verify the associated user token. Meaning, I can add my own attributes
to 'user', but when I verify the token, I only see a subset of the 'user'
attributes in the response payload. I don't see my own custom attributes and I
don't see the 'links' attribute either. Whereas when I do a GET on the 'user' I
just PATCHed, I see 'links' and my own custom attributes as well.
Is this by design, or am I potentially missing something in my token
verification request or configuration that would return the full data model
associated with the token?
- My work flow is to create a user, PATCH the user, GET the user to
confirm, then GET the token to ensure the PATCHed data has been
associated to it. I see changes to pre-existing Keystone attributes
when I GET the token, I just don't see my custom additions.
If this isn't appropriate, is there an alternative method to add custom
metadata to elements in the data model (users/roles/etc..)?
For example, we've also considered building a single nested JSON document and
serializing that into the 'blob' section of the 'policy'
attribute.
Our service is not an Openstack service, so we cannot take advantage of writing
policy to handle fine grained authorization of the APIs we're exploring through
our own REST interface. The above is how we're trying to bridge that gap.
Thanks a lot for your time and feedback!
Phillip Guerin
Software Engineer
+1-519-572-4668
skype: phillip.guerin
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
