Is it acceptable to PATCH Keystone JSON documents with custom attributes?

asked 2014-05-28 12:13:03 -0500

pguerin gravatar image

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@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": {         
        }
    }
}

Specifically:

"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 ... (more)

edit retag flag offensive close merge delete