|RE: [higgins-dev] Updating Password with IdAS|
I may as well move in the direction I think this will go and start exploring more questions.
Assuming no one else feels compelled to have this operation at the IContext layer, and instead have it at IDigitalSubject, let's try to minimize the issues below.
First, we have to tell ourselves that one cannot update the credentials of an authn identity which is not a subject in a context, and that's ok -- consumers will have to deal with it.
Next, we should decide whether we need a special operation like IDigitalSubject.updateCredentials, or simply hijack the existing update operations.
Using existing operations means keeping the API set minimal. Introducing an updateCredentails operation allows us to do things like specify old credentials, and pass instructions regarding the generation of credentials.
Another useful aspect of introducing updateCredentials is that it allows us to still maintain some symmetry with open. Where do we need this? Today we need it when updating the cardKeyHash credential. The manager of cardKeyHash should present the values as a triplet as they do when calling open with an AuthNSelfIssuedMaterials. The manager cannot pass the cardKeyHash value -- especially if its passed as an "oldCredential" assertion.
This alleviates the third problem below, and I suppose we could agree that the first two problems are acceptable.
>>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 7/12/07 4:46 PM >>>
In essence, you seem to be arguing against what was suggested in http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg02775.html.
The request is that there be a way to update any kind of authentication materials (not just passwords).
It felt natural to me to draw symmetry between the validation of authentication materials (which is what we do with IContext.open), and the management of authentication materials.
You argue that when the authentication identity is not represented as a subject in the context, then management of that identity's credentials should not be done using IdAS. And that when the authentication identity is represented as a subject, then the management of that identity is done by operating on the IDigitalSubject.
My worry is that this creates two problems for the IdAS consumer. First, they now have to figure out whether or not the authentication identity to be managed exists as a subject in the context. Second, they have to know how to use one or more non-IdAS management APIs to deal with cases where the identity falls outside the context.
The IdAS consumer doesn't have to call different APIs to authenticate depending on the nature/location of the authn identity. Do we really want them to have to know and code to different APIs for management?
There's one other issue for the consumer. Even when the authn identity exists as a subject in the schema, nothing says that the data held in the authentication materials passed to open looks or feels anything like the data held on the corresponding digital subject. Unless we mandate to CPs that there is a 1:1 relationship between the authn data passed to open and that held in the subject's attributes, the consumer may need to know how to map between the two.
If there is truly no use case where the authentication identity is not also represented as a subject in the context, then let's change open to take a subject ID and credentials. I think people believe there are use cases though. I think there are kerberos and saml assertion based use cases where this may be true. In essence, someone may be able to call IContext.open() where the authentication materials constitute a trusted assertion, or something that can be proven and trusted without there being any subject in the context being represented as the entity being authenticated.
You may be right, it may be best to manage credentials by performing operations on a digital subject. And the problems listed above may not actually be of any consequence if we do it that way.
What do others think?
>>> David Kuehr-McLaren <dkuehrmc@xxxxxxxxxx> 7/12/07 9:55 AM >>>
Thanks for the response. Some further comments and responses to your questions.
>>-- 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?
Because the sematics of null newMaterials and oldMaterials has the meaning of "generate materials", then a more generic exception would be fine, because the application should know the meaning. I am hung up on the word "Permitted". It makes me think authorization. I would suggest OperationNotImplemented
>>-- 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.
I agree with this statement for "open". A context can accept a connection by an identity that is defined outside of the context. But I have difficiculty understanding this for "update". What other object in the Context can be updated with the new materials if not a Digital Subject? Can the Context have an internal set of identities that are not represented as DigitalSubjects? Can you give me an example of this?
>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 would authentication materials be persisted and retrieved? In order to query metadata about the authn material (last changed, expiration, policy), management apps would need to be able to get oldMaterials from a DigitalSubject from attributes with the type of IAuthNAttributesMaterials. Also, there would need to be a way to call updateAuthNMaterials so that the metadata can be updated, without updating or nulling out the actual authn materials.
>>-- 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 always envisioned the password strength policy as metadata that could be queried from the password attribute of a DigitalSubject. The policy for each DigitalSubject and each password attribute could be different.
>>-- 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.
This splits the interface for updating across IContext and IDigitalSubject, where the materials are updated at the IContext level, and the metadata about the materials is accesses on the IDigitalSubject.
>>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?
I am having a hard time understanding the use case where the identity is not represented as a DigitalSubject in some Context and can have a managed set of authn materials. I think my answer is yes, but I do not understand the non-DS use case where authn materials can be updated.
>>-- 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)?
This still works using oldMaterials, if the oldMaterials object can contain new data. Like I said, a nit about semantics.
However, this brings up the assumption that the interface for authenticating to a Context should be the same or similar to the interface for managing the authn materials. They are not related and have different requirements. A JAAS like interface for open makes perfect sense. However, JAAS Subject does not contain the capabilities for managing the life cycle of authn materials used for credentials. I think you actually need other APIs, like verifyAuthNMaterials in order to support creating a JAAS subject.
From a management perspective, my assumption is that IdAS Digital Subject is the interface I would use to manage the authn materials (passwords, keys, certificates, tokens. etc.) for a user, application, or device. If the authentication identity is managed outside of IdAS, then I would be using some other API to managed the authn materials.
Thanks for your consideration here,
Back to the top