Keystone/TempUserProvisioning/Blueprint

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.

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

1. Addition of expiry time as an optional parameter to the call that creates a new user entry
2. Addition of user ID as an optional parameter to the call that creates a new user entry.
3. Addition of a new API call to delete all expired user entries

These will be made to the API documentation