Jim,
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
From:
higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Jim Sermersheim
Sent: Thursday, July 12, 2007 4:40
PM
To: 'Higgins (Trust Framework)
Project developer discussions'
Subject: 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 >>>
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.
>>> 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
|