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