User Lifecycle

Connectors should implement the user lifecycle SPI if the cloud service supports users within accounts and resources owned by users. This SPI will be called by CPBM to keep users in services in sync with the user lifecycle in CPBM.


The UserHandle is an opaque handle that represents a given user in a service instance.
public class UserHandle {    /* A unique opaque handle to identify the service specific entity corresponding to       this user */    public String getHandle();      /* Can store any json/string data and CPBM will preserve this as it is. This field        may be used to store any additional data the connector would like to associate with        this user handle    */    public String getData();      /* Connector can store apiKey/secret or username/passwords etc in this key and values        in this map would be displayed in the CPBM credentials section.     */    public Map<String, String> getApiCredentials();      /* Back reference to the user */    public User getUser();      }  public class User {  ...    /* Return the user handle for the corresponding service instance if exists. Returns        null otherwise */    public UserHandle getHandle(String serviceInstanceId);    /* Add an user handle to the user */    public void addHandle(String serviceInstanceId, UserHandle handle);    /* Remove a user handle from the user */    public void removeHandle(String serviceInstanceId);  }

The handle string should be the same one that is used to identify the user in the usage record.


The UserLifecycleHandler is defined as follows:
/**    * Handles user lifecycle.     */  public interface UserLifecycleHandler {      /* Registers a user in the cloud service and stores the mapping of the user as        handles in user object passed as parameter. User handle must be added as          User.addHandle. */    public String register(User user);      /* Lock the user */    public void lock(User user);      /* Disable the user */    public void disable(User user);      /* Unlock the user */    public void unlock(User user);      /* Enable the user */    public void enable(User user);      /* Terminate the user. In this case user handle should be cleaned. This can be done          as user.removeHandle */    public void terminate(User user);    /**     * Sets service level controls at user level. User level     * controls are set under the following scenarios     *     * <ul>     *   <li> When a user is newly created, the controls are applied from the tenant's account type     *   <li> when a tenant moves account types     * </ul>     * In all cases, the service is expected to do its best to apply the     *   updated values by triangulating between the  tenant's current     *   settings, the new settings and any current limitations. For     *   example, a tenant's current quota, new quota and currently used     *   amount (against that quota).     *     * @param user The user to update     * @param controls - Map of control names and their values; Not null when SP edits the service controls     *                   and when a tenant moves account types     */        public void setControls(User user, Map<String, String> controls);      /**     * Retrieves service level controls defined at tenant level     * @param user The user     * @return     */      public Map<String, String> getControls(User user);    }
The UserLifecycleHandler SPI methods are as follows:
  • register: Register a scope corresponding to this user in the cloud service
  • lock: Prevent the user from accessing their resources from the service UI/API. The resources can remain operational.
  • disable: Prevent user from accessing resources. Reduce all resource consumption while allowing reactivation.
  • unlock: allow users access to their resources again
  • enable: allow users to access their resources again. Ideally, enable will remember the lock state of the user. This allows blanket disable/enable without changing lock state.
  • terminate: Remove the user from the service

A note on the difference between locking and disabling. Lock simply prevents access to resources. It does not reduce resource consumption. It may be used for minor infractions such as login failures etc. However, disable reduces resource consumption (say by shutting down VMs etc) and is expected to put the user in a state of minimal resource consumption, while still allowing the system to recover that user back to operational state. Disable is also expected to remember (ideally) the lock state so that when a user is locked and then disabled and re-enabled, they continue to be in the locked state. However, in practice, it is not expected that all cloud services support this nuance. So, it is acceptable for disable to behave exactly like lock.

Figure 1. User Lifecycle Handler

Vous avez d’autres questions ? Envoyer une demande