Post by josephreynolds1 on Sept 17, 2021 20:59:03 GMT
Should the Redfish spec talk about requiring additional authentication when performing sensitive operations?
For example, changing a local user account password is a "sensitive operation". If a user walks away from an active session (or that session is hacked), a bad actor can POST a new password to the account, which locks out the legitimate user. A common solution is to to require additional authentication, such as providing the old password, when changing the password.
The same issue exists when a Redfish Administrator changes a local user account password as part of a "password reset" scheme.
Part of this is solved already using basic authentication - as every operation includes the "current" password (along with the "new" password in the payload). For session-based authentication, we had discussed early on that implementations were free to force a new session to be created when sensitive data was being changed for exactly this reason - but I don't think that guidance was written into the spec language.
I think this is a matter worth discussing with the group to see if we can get some interoperable behavior here. We may want to create a standard (error) message for "Session closed to force re-authentication for modifying sensitive data" in that case. I prefer this approach because it doesn't require new semantics to use or implement - and it provides flexibility for the implementation (I can choose how old a session is before it needs re-authentication, etc.).
An alternative would be to create "OldPassword" style properties that are not shown in response payloads but are used to provide the current/new settings together. The issue there is that the method is invisible to developers until they read the spec or messages, etc. to learn how that is done. The same can be said for creating an Action to change a password (with new/old as parameters).