>>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
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.
>>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