IdAS Change Password

Requirements

As described in bug 193223, we need a way to do the following:

1. Set a password for the first time
2. Reset an existing password
3. Specify an old password value when resetting
4. Cause the CP/backing store to generate and return a set/reset password

Proposal 1 (New API)

This was discussed on the Higgins Dev list at [1] [2] [3]

The resulting method looks like this:

/**
  * Adds or changes authentication materials.
  * @param oldMaterials May be null. Specifies the existing authentication materials
  *       which are being modified.
  *       The way in which this matches a known authentication identity and associated 
  *       materials is specified by the definition of the authentication materials object
  *       (that specification includes instructions as to which data in the materials are
  *       required to be present and which are not).
  *       When null, this operation is to be treated as a request to "add authentication materials".
  *       That is, the value of newMaterials will be used to create a new authentication
  *       identity and its associated materials.
  * @param newMaterials May be null. Specifies the value of the new authetication materials.  
  *       When null, oldMaterials must be specified, and this operation is treated as a request
  *       to "generate authentication materials"
  * @return May be null. When newMaterials is null, a generated authentication materials object
  *       is returned.  Otherwise the return value is null.
  * @throws IdASException
  */
public Object updateAuthNMaterials(Object oldMaterials, Object newMaterials) throws IdASException;

Consensus seemed to point to Proposal 2

Proposal 2 (Use existing APIs)

Treat authentication materials as attributes for purposes of management. This brings up the following issues:

1. Attribute types. How does an IdAS consumer know what attribute(s) to manage?
   1. One path is via standardization: Do we begin to propose some standardized attributes for this? For example, if someone wants to update their password, what attribute(s) do they update?
   2. Another path is discovery.
2. Specialized operations, behaviors, and extra data that will need to be supported. I'm talking about things we don't normally do when updating attributes, like:
   1. When updating the <userPassword> attribute, allow a way to specify the old password
   2. Allow a way for the caller to reset the password to an auto-generated value
   3. Allow the caller to update attributes which are (for whatever reason) not returned. For example, some contexts will not return a "userPassword" attribute, but may allow that attribute to be written to.
3. Design support for specialized behaviors: How do we do the things we list above? One suggestion is via controls (which are not yet designed). We also need to decide how to indicate different types of failures to the caller (the modification to userPassword didn't work because the CP requires the old password's value). Also, we need to decide whether to build in support (and if so, how) for feature discovery.