Keystone/TempUserProvisioning/Blueprint - Revision history

Kwss: /* API changes */

2013-05-17T12:57:32Z

‎API changes

Kwss at 12:56, 17 May 2013

2013-05-17T12:56:59Z

Kwss: Created page with "=== 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, ..."

2013-05-16T15:26:55Z

Created page with "=== 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, ..."

New page

=== 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:
<pre><nowiki>{
"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"
}
}</nowiki></pre>
The proposed new structure of the user entry is:
<pre><nowiki>{
"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”
}
}</nowiki></pre>

==== 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.
==== Specifying User IDs ====
In order to maintain functionality for temporary users on systems which user User IDs in access control lists we have modified the user creation process to allow a user ID to passed in with the user entity, if this parameter is present, it will be used instead of the standard randomly generated ID.
==== 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 user ID 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

@@ Line 36: / Line 36: @@
 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

@@ Line 33: / Line 33: @@
 ==== 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