Open Stack

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: 'openstack at 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