Difference between revisions of "Keystone/TempUserProvisioning/Blueprint"

Revision as of 12:56, 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

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