| RE: [higgins-dev] Updating Password with IdAS |
|
<sorry, forgot to type words before hitting send on that last one>
I wasn't suggesting a new ISubjectAuthNMaterials, thought it's an interesting idea.
I'm primarily interested in building a model where the management applications don't end up having to have lots of specific knowledge based on the context/context provider being used in order to update authN materials. It would also be nice if the CP's didn't have to be burdened with writing special-case handling code for "virtual attributes" which cause it to execute some different "changePassword" type of code -- but I concede that CP's are often in the role of doing such things anyway.
Let's go ahead and explore the notion of using existing update operations, and thus specifying to CP's that they need to allow appropriate access to authN materials as attributes in order to support updates to them.
* Attribute type 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?
* Enumerate specialized behaviors: We need to list the different types of 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:
** When updating the <userPassword> attribute, allow a way to specify the old password
** Allow a way for the caller to reset the password to an auto-generated value
* 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.
Jim
>>> David Kuehr-McLaren <dkuehrmc@xxxxxxxxxx> 7/18/07 1:32 PM >>> <snip> >>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. I agree. However, I contend the same object used to pass authnMaterials on open and validate (see use case #2, below) can not be the same object as the one used to manage the materials for the subject. The contents of the materials object is different for validate vs. manage use cases. In the case of the open, the context may be presented with a generated credential (Kerberos ticket) that is already validated and contains a expiration. You can not manage this type of credential, but it can be used to validate an identity to open a context. >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. I am not sure I understand your example. I agree that the application should not need to know the details of the authentication method, only that it needs to supply the abstract authnMaterials to open or validate. However, to manage the authnMaterials specific knowledge of the type of credential and the format of the materials is require. There are three use cases: 1.) Open: An Identity wants to open the context in order to use the context to look p or manage profile information. In this case, the credentials are only checked for the entity doing the open. The open handler of the CP needs to process the authnMaterials on the open. The identity performing the open may or may not be in the context. I suggest that the authentication portion of the open handler of all CPs be plugable. 2.) Validating authnMaterials of other Digital Subject : once the context is open the connecting identity needs to use the context as a security registry, to validate the identities of subjects in the context. The identity on the open wants to "compare" or otherwise validate one of the sets of authnMaterials associated to one or more subjects. The validation handler used for this operation is specific to the type of authnMaterials associated to the subject and independent of the type of handler and materials used to open the context. For example, the application could open the context using a password, but be validating the identities of subjects in the context using certificates. I think that this could still use abstract authnMaterials from the app point of view (I think I just agreed that there needs to be at least one new API on IDigitalSubject to validate an authnMaterials object. 3.) Same as 2, but the connecting identity wants to modify the authnMaterials of subjects and or query and modify the metadata. This is different from cases 1 and 2, because the management application needs to address a specific set of materials and deal with the specific input format. In addition, there needs to be a way to query and set the metadata on a specific set of materials. In this case, I was thinking the authnMaterials are much more like attributes, than in cases 1 and 2. >>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? This is functional/behavioral and not access control. A repository may not have the ability to return a value for a set of stored authnMaterials, or if it does, it will not be in the same form as the input authnMaterials (hashed password value, or the keycard example). >>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. I was not clear here. I meant to say that the CP would know how validate the authnMaterials for a specific type. The CP would know that a password type was stored as hash, but require a string for input. For a compare value operation on an attribute of type authnMaterialsPassword, the CP would perform the hash of the input password attribute and compare it to the stored hash value. However, you convinced me that a API to validate authnMaterials is the better way to go. <snip> >>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). That is sort of where I started with my thinking on this. To be used as an authentication object on open and as a managed object in the context, the AuthNMaterials associated to digital subjects need to have all the functions and behaviors of a complex attribute. I think of this as a new interface (lets say ISubjectAuthNMaterials). As you pointed out, this is over kill for an app that only wants to open a context or validate an identity. So, having IAuthNMaterials for open and validate, and something like ISubjectAuthNMaterials that has the characteristics of IAttribute makes sense to me. Are you suggesting new interfaces like ISubjectAuthNMaterials and IHasSubjectAuthNMaterials with add, modify, remove, get, and validate operations? I was concerned that this would add a new concept to the Higgins DigitalSubject model, where the DS only has attributes and metadata. If this is OK with others, then I can see where this would meet the management requirements. <snip> David |