Hi Brion, There can be multiple use cases where the users need to change the password such as forgot password recovery and changing the password manually as they required.
So in this case we provide the option to change the users password manually without any recovery options. Therefore as Ruwan mentioned we need to request the existing password as a security measure. So it's better to go with that option and it should be validated as well other than just doing it for improve the user experience. So you may use the provided existing password to authenticate the /Me API and if It's successful only, the new password will be updated. Thanks, Ashen On Tue, Aug 6, 2019 at 3:12 PM Ruwan Abeykoon <[email protected]> wrote: > Hi Brion, > > The reason we ask to provide the current password is a security measure. > Someone have the users session should not be able to update the password or > any primary security related data without proving he has access to that > information. > > For password, the user has to prove that he knows the(existing) password > for phone number, user has to prove that he owns the phone (OTP) > for email, he has to prove that he has access to that email account. > (email confirmation link) > > Hence this needs to be done in a generic way, something like verifiable > claim. > > I do not see a problem attaching the existing password as basic auth, > provided the API is authorized with different mechanism (Token) > Ideally these kind of data update would need to obtain one time short > lived token for the patch operation and the token should be revoked after > first use. > > > Cheers, > Ruwan A > > > On Tue, Aug 6, 2019 at 2:54 PM Brion Silva <[email protected]> wrote: > >> >> >> On Tue, Aug 6, 2019 at 2:51 PM Brion Silva <[email protected]> wrote: >> >>> Hi All, >>> >>> I'm in the process of implementing the password reset gadget in the new >>> IS user portal. >>> >>> In the new user-portal, we consume the SCIM2 Me endpoint and we have the >>> option to update the user's password using the PATCH operation[1]. This >>> operation does not expect the current password and only rely on the >>> authentication mechanism enforced for the API. So we need to clarify >>> following, >>> >>> 1. Current user-dashboard have the UI to capture the existing >>> password. So there will be a difference in user experience. >>> 2. Will it be aligned with the general practice of the IAM solutions? >>> >>> As a workaround we can capture the existing password from the new UI and >>> call this PATCH operation using a basic auth header. But it will only >>> provide the existing user-experience. >>> >>> Appreciate your inputs on this. >>> >>> [1] >>> https://docs.wso2.com/display/IS570/apidocs/SCIM2-endpoints/#!/operations#MeEndpoint#patchUserMe >>> >>> Thanks and Best Regards. >>> -- >>> *Brion Silva* | Software Engineer | WSO2 Inc. >>> (m) +94777933830 | (e) [email protected] >>> >>> <https://wso2.com/signature> >>> >> >> >> -- >> *Brion Silva* | Software Engineer | WSO2 Inc. >> (m) +94777933830 | (e) [email protected] >> >> <https://wso2.com/signature> >> > > > -- > Ruwan Abeykoon | Director/Architect | WSO2 Inc. > (w) +947435800 | Email: [email protected] > > _______________________________________________ > Dev mailing list > [email protected] > http://wso2.org/cgi-bin/mailman/listinfo/dev > -- Ashen Weerathunga | Senior Software Engineer | WSO2 Inc. (m) +94716042995 | (w) +94112145345 | Email: [email protected] <http://wso2.com/signature>
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
