Ask Your Question
0

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

1 answer

Sort by ยป oldest newest most voted
0

answered 2016-07-01 00:04:42 -0500

Is not possible. While most Keystone objects have a n"extra' field, they do not get added to the Token. You would need to write a custom token provider to do that.

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

[hide preview]

Get to know Ask OpenStack

Resources for moderators

Question Tools

1 follower

Stats

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

Seen: 444 times

Last updated: Jul 01