| RE: [higgins-dev] Updating Password with IdAS |
| "Drummond Reed"
<drummond.reed@xxxxxxxxxxxx>
Sent by: higgins-dev-bounces@xxxxxxxxxxx 07/12/2007 09:44 PM
|
|
I love it when someone answers their own question to help lead the discussion forward ;-)
FWIW, I think you are leading in the right direction. The world is much simpler if, as you put it, the authentication identity is always represented as a subject in the context. This seems like a reasonable constraint, similar to saying you have to register at a site in order to authenticate at a site. A contrarian might point to the OpenID “new user” use case where you can show up at a site at which you’ve never registered and login with your OpenID, but in fact behind the scenes that site is performing a “provisional authentication” followed by (if the authentication is successful) a new user registration (with a recording of the OpenID identifier as the “credential”). So it still follows the rule that the subject must be represented in the context.
=Drummond
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
>>> "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?
Jim
>>> David Kuehr-McLaren <dkuehrmc@xxxxxxxxxx> 7/12/07 9:55
AM >>>
Jim,
Thanks for the response. Some further comments and responses to your
questions.
... snip...
>>-- 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,
David_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev