[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [higgins-dev] Updating Password with IdAS
|
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.
-- 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.
-- 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?
-- 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. 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.
-- 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. 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.
David
David Kuehr-McLaren
Tivoli Security
919.224.1960
"Jim Sermersheim"
<jimse@xxxxxxxxxx>
Sent by: higgins-dev-bounces@xxxxxxxxxxx
07/11/2007 04:21 PM
Please respond to
"Higgins \(Trust Framework\) Project developer discussions"
<higgins-dev@xxxxxxxxxxx> |
|
To
| "'Higgins (Trust Framework) Project
developer discussions'" <higgins-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
| RE: [higgins-dev] Updating Password
with IdAS |
|
So here's a newly proposed stab at the method (on IContext)
/**
* Adds or changes authentication materials.
* @param oldMaterials May be null. Specifies the existing authentication
materials
* which are being modified.
* The way in which this matches a known authentication
identity and associated
* materials is specified by
the definition of the authentication materials object
* (that specification includes
instructions as to which data in the materials are
* required to be present and
which are not).
* When null, this operation
is to be treated as a request to "add authentication materials".
* That is, the value of newMaterials
will be used to create a new authentication
* identity and its associated
materials.
* @param newMaterials May be null. Specifies the value of the new
authetication materials.
* When null, oldMaterials
must be specified, and this operation is treated as a request
* to "generate authentication
materials"
* @return May be null. When newMaterials is null,
a generated authentication materials object
* is returned. Otherwise
the return value is null.
* @throws IdASException
*/
public Object updateAuthNMaterials(Object oldMaterials, Object newMaterials)
throws IdASException;
As Paul points out earlier, this as well as the open method
are scheduled to change to a more JAAS-like model eventually.
Jim
>>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 6/21/07
10:29 AM >>>
Speaking of the open method, Duane was wondering if it
might be better to call this thing something like updateCredentials or
updateAuthNMaterials. and instead of being limited to passwords, allow
any kind of credential to be updated.
So it might be better to be more symmetrical with the
way we authenticate. Properties of the way we authenticate differ
from those of my first proposal, specifically:
- An authN identity may or may not exist as a subject
in the context for open, but must be a subject for updatePassword
- Open can handle any kind of identity/credential. updatePassword
only handles passwords.
If we did an updateAuthNMaterials(Object oldMaterials,
Object newMaterials) at the IContext level, we could get more symmetry
and might be able to re-use existing implementations of IAuthNAttributesMaterials.
Jim
>>> "Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx>
6/20/07 7:15 PM >>>
+1.
As we’ve discussed before,
the ‘open’ method (from an auth POV) is temporary. It needs to be replaced
with something that supports more JAAS-like/complex auth interactions.
But for now this is a good step. -Paul
From: higgins-dev-bounces@xxxxxxxxxxx
[mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Daniel Sanders
Sent: Wednesday, June 20, 2007 6:19 PM
To: higgins-dev@xxxxxxxxxxx
Subject: Re: [higgins-dev] Updating Password with IdAS
Looks good to me too - agree with Tom on
both 1 & 2.
>>> "Tom Doman" <TDoman@xxxxxxxxxx> 6/20/2007
4:08 PM >>>
1. Should we have both?
2. Yeah, that seems right to me.
Tom
>>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 6/20/2007
2:37 PM >>>
Here's a stab at the method (on IDigitalSubject)
/**
* Adds or changes the password for this digital subject.
* This method assumes this digital subject has the notion of a "password"
* used to authenticate the subject (as in when {@link IContext#open(Object)}
is called).
* @param newPassword May be null. Specifies the password to be set
in {@link String} form.
* When null, specifies that the password will
be machine-generated and
* returned in the return argument.
* @param oldPassword May be null. Specifies the old password.
* This may be required by some systems in order
to update an existing
* password.
* @return May be null. When newPassword is null, a generated password
is returned.
* Otherwise the return value is null.
* @throws IdASException
*/
public String updatePassword(String newPassword, String oldPassword) throws
IdASException;
Questions:
1) Should the password fields be String or something else (like byte[])?
2) Since this is technically an update operation, do we say it needs to
be followed by a call to IContext.applyUpdates()?
Jim
>>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 6/18/07
5:43 PM >>>
Specifically for updatePassword: https://bugs.eclipse.org/bugs/show_bug.cgi?id=193223.
David originally brought this up. It would be good if people
could visit that bug and add any characteristics they believe that method
should have.
I'll log another for the general case of blind updates (Tom pointed out
that at least the JNDI using LDAP CP is not completely capable of knowing
when an attr is present yet non-readable versus non-present).
On the IRC, Dale also mentioned the need for a verifyPassword operation.
I'll log another for that.
Jim
>>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 6/18/07
4:05 PM >>>
Well, the IdAS data access model we arrived at was one somewhat analogous
to the way one typically navigates, accesses, and updates other kind of
hierarchical data. Prior to that model, we had one where the caller
specified the data, action, and value being performed for updates (people
disliked that).
With the current access model, I think you'd have to get the CP to cooperate
for most cases like this.
First, I'm not sure why it should fail if you ask for any attribute which
it doesn't have. I assumed the call to IDigitalSubject.getSubject(String
cuid, Iterator attrSelectionList) would silently ignore any attributes
in the attrSelectionList that don't exist or are not returnable for the
subject being read. This needs to be documented in the Javadoc.
In cases where an attribute exists, can't be read, but can be updated,
I think the CP could return an attribute with zero values. This again
would need to be clarified in the javadoc (a note added that an attribute
with zero values is allowed when the consumer is not allowed to view the
values). Of course, this would be subject to any other access controls
which might deny the consumer from seeing even an empty attribute.
For passwords specifically though; David brought up some password
modify use cases at the Austin F2F and noted that maybe password modify
was a unique enough operation that it deserves its own API. Something
that can accommodate proof of old password, challenge/response negotiation,
CP-generated password, etc. I made a quick note in http://wiki.eclipse.org/index.php/IdAS_ToDo
but haven't done anything beyond that.
Jim
>>> "Daniel Sanders" <dsanders@xxxxxxxxxx> 6/18/07
3:25 PM >>>
Jim,
Currently, it appears to me that I can only change existing attribute values
on a digital subject if I first "get" them. But a digital
subject's password is sort of a special case. The JNDI provider cannot
really "get" that particular attribute. It will fail if
I ask for it specifically, and it will not return it if I simply ask for
all attributes. I need a way to change an attribute's value without
getting it first. Is there any way to do that in IdAS today?
I guess in general, this is needed for attributes where you are allowed
to update them, but cannot to read them.
Thanks,
Daniel
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev