RE: [higgins-dev] Updating Password with IdAS

["Jim Sermersheim" <jimse@xxxxxxxxxx>]

>>> David Kuehr-McLaren <dkuehrmc@xxxxxxxxxx> 7/13/07 9:23 AM >>>
<snip>
>As for management of the authn materials.  Each CP needs to allow the management of authn materials associated to the digital subjects contained in the CP (assuming the CP supports authn materials as attributes on its subjects). 
 
ok
 
>I agree that it would be best to use the existing APIs to manage the authentication materials.  
 
This might cause various problems in regards to management.  For example: An application which uses AuthNNamePasswordMaterials is allowed to refer to the name and password in abstract terms. All it has to do is use the constructor (authN = new AuthNNamePasswordMaterials(myCtx, "Alice", "Secret");).  The application doesn't need to know what the attribute name is which holds the password.  For management however, the application would need more knowledge.  
 
In this simple example, it may not be a huge issue -- the application has to figure out what the URI is(http://www.eclipse.org/higgins/ontologies/2006/higgins#userPassword).  If the CP has special handling which maps that attribute for the open method, yet fails to map the same attribute URI for modify methods, then the application will not be able to modify the attribute.
 
>Authentication materials could be identified by attribute type, where differences in behavior can be defined by type. For example, an attribute type of authnMaterialsPassword is write only (returns a null value on read, or the results are unpredictable).  
 
Is this different from traditional access control rules on the accessability of attributes?
 
>A value compare of a authnMaterialsPassword type will compare the hash value of the input string with the attribute value. etc. 
 
This kind of rule may be bad -- if the semantics of such an operation were to assign a "true" return as meaning "caller presented correct credentials" (in other words, if this were used as a "verifyPassword" method.  Why?  Because it may be easy to acquire the hash of a user's password (it may even be widely distributed), and thus only a presentation of the actual password could be said to verify that the presenter knows the value.  
 
Let's look at the case of AuthNSelfIssuedMaterials.  That thing is constructed using a ppid, key modulus, and key exponent.  What we store is very different.  What is stored is a single value which is a hash of the three components strung together (or something like that).  In order for one to present materials for authentication, they have to present all three values (not the single hashed value).  
 
Furthermore (for the case above), the CP only contains the single hashed value, and in a different attribute "cardKeyHash" in the case of the JNDI ldap CP.  In order to hijack the existing update operations, the CP would need to special case updates which contained all three component values (ppid, mod, exp).  I suppose it could look for these three attributes, and have a special case where it now knows that in reality, the caller is attempting to modify the authn materials.  What would it do if some but not all of the information was presented?  Fail I suppose.  If other information was also passed (like streetAddress)?  I don't know -- I guess it would try to handle that as an "update credentials, as well as this other attribute".
 
For reasons like these, some believe that introducing a specific API for updating credentials is better than re-using existing APIs.  I note that even LDAP chose this route, as it was seen as welcoming a high degree of interop problems to re-use the existing modify operation to update passwords.
 
>If there are other requirements, like old password, then this would be passed in as "control" meta data.   
>
>If the Authn materials are treated as attributes on the subject, then they can have the meta data required for the lifecycle management (last changed, expiration date, policy, etc.) 

Without thinking too hard, I imagine this could also be done even if we had a specific "updateAuthNMaterials" in cases where the passed materials were made up of IAttributes.  It would be more clunky though, since one would basically rely on the diff between the old and new materials to convey the changes to be made.

Thinking out loud here: One other option which serves both the notion of keeping authn materials somewhat abstract (or at least minimizing the caller's need to have CP knowledge) and the notion of ease of updates, is to allow authNMaterials to be gotten (getAuthNMaterials) and then the returned materials could be read, updated, and applied as long as the CP allowed those actions (same behavior as attributes, without requiring them to be attributes).  Likely, the CP would only return authNMaterials under trusted scenarios (caller is authenticated and authorized to view and update them).

<snip>
 
Jim