Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [higgins-dev] Updating Password with IdAS

Yeah, if the policy of the context allows this, and the materials object is specified in such a way that the authz identity can be identified within the materials without also specifying the password, then you would be able to.

>>> "Daniel Sanders" <dsanders@xxxxxxxxxx> 7/11/07 3:36 PM >>>
Will this allow the reset use case? as follows:
I'm admin user, don't know and don't care what the old password was, just want to reset some user's password.  I presume that my oldMaterials would only have username, but no password, and that my newMaterials would have username and password.

>>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 7/11/2007 2:21 PM >>>
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 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.

>>> "Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx> 6/20/07 7:15 PM >>>


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.


>>> "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;
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 Sermersheim" <jimse@xxxxxxxxxx> 6/18/07 5:43 PM >>>
Specifically for updatePassword:  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 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 but haven't done anything beyond that.


>>> "Daniel Sanders" <dsanders@xxxxxxxxxx> 6/18/07 3:25 PM >>>

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.


higgins-dev mailing list

Back to the top