| RE: [higgins-dev] Updating Password with IdAS |
|
>>> David Kuehr-McLaren <dkuehrmc@xxxxxxxxxx> 7/11/07 5:05 PM >>>
> >Jim, > >I was out of the office when the bulk of this thread was posted. I think I have caught up. Hopefully I am not bringing up resolved questions. I very much appreciate your effort on this. > >-- Are the CPs required to provide generated IAuthNAttributesMaterials when newMaterials is null and oldMaterials is specified? Not all registries have that capability to generate credentials. What exception should the CP throw if it can not generate materials? NotImplementedException does not seem to fit quite right. I agree, an exception should be expected when the Context Provider or the Context's policy prevents this. Should we add a generic OperationNotPermittedException or something more specific like UnableToGenerateAuthNMaterialsException?
>-- How can I set the metadata of the attribute that will ultimately hold the IAuthNAttributesMaterials for the specific IDigitalSubject? When I reset a password, I may want to pre-expire a password, so that it must be changed on first use. There's no requirement that the authentication identity be a digital subject in the context. Further, there's no requirement that any/all of the other authentication materials (including a password) be represented by an attribute (even when the authentication identity is a digital subject in the context). I think that if there are capabilities like you mention above (pre-expire a password), then the authentication materials object needs to be specified in such a way as to allow that data to be conveyed.
>-- How does the application get the password strength policy before attempting to call updateAuthNMaterials or after a call to updateAuthNMaterials fails? Have you considered a defined exception for a failure to update due to a policy violation? We don't yet have any kind of capabilities or policy discovery methods that would allow this. I agree we need those kinds of methods, and can add them separately from this one. In terms of the exception, I agree something would be useful but I'm not sure how general (PolicyException) or specific (PasswordStrengthException) to go.
>-- I am OK updateAuthNMaterials at the level of the IContext, but apps will still need to be able to query the value and metadata of AuthNMaterials attributes at the IDigitalSubject level. This would only be possible when the authn identity is also a digital subject. If that is the case, then the application would need to know what those attributes are.
>Apps need to be able to query meta-data (e.g. expiration date, last changed date, password history, password policy, etc.). If supported by the repository, the ability to read the hashed or encrypted value is also useful for migrating or exporting digital subjects to other registries, while preserving the authn materials.
Would you want to be able to do this regardless of whether or not the authentication identity is represented as a digital subject?
>-- This comment is nit: Using the convention of specifying a value for oldMaterials and null newMaterials to cause IAuthNAttributesMaterials to be generated seems a little awkward to me, because there are no old materials in use. I guess I'm assuming that authentication materials may (even typically) consist of two kinds of data: non-secret data which is used more to specify the authentication identity, and secret data which is used to verify that identity. In cases where this is true (such as authentication materials which consist of username and password), the oldMaterials may be partially populated (with the identity data -- like username) when the caller doesn't need to specify the secret data for whatever reason.
>New materials may need to be passed in as part of the oldMaterials object, in order for the CP to be able to generate the new IAuthNAttributesMaterials. The example I can think of is passing in a certificate request as oldMaterials to cause the CP to generate, store, and return a certificate. This maybe an invalid use case.
Hmm, I can see there being a case like that (caller needs to provide a little bit of data -- like a seed -- such that the generated materials may be produced). Well, do we want to provide for that now, or push that off until we refactor IContet.open (as well as this method)?
Thanks for the feedback. Jim
|