Difference between revisions of "Keystone/TempUserProvisioning/Blueprint"
(→API changes) |
|||
| Line 36: | Line 36: | ||
The following API changes are needed | The following API changes are needed | ||
#Addition of expiry time as an optional parameter to the call that creates a new user entry | #Addition of expiry time as an optional parameter to the call that creates a new user entry | ||
| − | |||
#Addition of a new API call to delete all expired user entries | #Addition of a new API call to delete all expired user entries | ||
These will be made to the API documentation | These will be made to the API documentation | ||
Latest revision as of 12:57, 17 May 2013
Temporary User Provisioning in Keystone
There are many instances in which it might be beneficial to be able to create temporary user entries in Keystone. For example, guest accounts and fixed term contract employees, support for short term alliances such as Virtual Organisation, or autoprovisioning of federated users. We propose adding an expiry time to user entities, and to support this, a function to delete all expired entries. In order to support backwards compatibility, the system should still allow for users to be created without an expiry time, which then denotes a permanent user that can only be deleted by an administrator. The current structure of the user entity is:
{
"user": {
"default_project_id": "263fd9",
"domain_id": "1789d1",
"email": "joe@example.com",
"enabled": true,
"id": "0ca8f6",
"links": {
"self": "http://identity:35357/v3/users/0ca8f6"
},
"name": "Joe"
}
}
The proposed new structure of the user entry is:
{
"user": {
"default_project_id": "263fd9",
"domain_id": "1789d1",
"email": "joe@example.com",
"enabled": true,
"id": "0ca8f6",
"links": {
"self": "http://identity:35357/v3/users/0ca8f6"
},
"name": "Joe"
“expiry_time”: “2013-05-27T18:30:59.999999Z”
}
}
Handling token expiry
When a system can create both temporary and permanent users, because tokens are time limited, then it is important that a token cannot be issued which exceeds the expiry time of the user it is linked to. Therefore in order to support the addition of temporary users, the code that sets token validity should be changed so as to limit it to no later than the user expiry time.
API changes
The following API changes are needed
- Addition of expiry time as an optional parameter to the call that creates a new user entry
- Addition of a new API call to delete all expired user entries
These will be made to the API documentation
