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()?
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.
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
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