Hi Francesco I’ve created a JIRA issue - https://issues.apache.org/jira/browse/SYNCOPE-1388
But I tend to disagree with the behavior about allowing to get the user
information.
IMHO whenever the flag is set, any request should return 403 except the paths
/accesstoken and /users/self/mustChangePassword
If an application only requires the user information, it will never be enforced
that the password is changed. And this is usually the intension of an
administrator if this flag is used.
I intend to use this flag in a custom password policy, which requires to change
the password every eg. 90 days. (A requirement which still exists in many
company policies today.)
If the password change is not enforced then the policy is somewhat useless.
What do you think?
Regards, Lukas
On 23/10/18 08:34, Francesco Chicchiriccò wrote:
Hi Lukas,
On 22/10/18 15:37, Lukas Funk wrote:
Hi,
I’ve a question regarding «mustChangePassword» flag for users.
How is the behavior for this flag intended?
I’d expect, that if this flag is set, I can obtain a temporary access token but
I can’t perform any actions other than “/users/self/mustChangePassword”.
So I must change the password before I can even get my own user information.
I would say this is the intended feature.
The observed behavior is quite different using the REST API:
(We’re using 2.0.8 but I verified the same behavior in the demo environment
which is 2.1.2-snapshot)
Given the admin has set the “mustChangePassword” flag to “true” for user
“rossini”
When the user “rossini” acquire an accesstoken, then the access token is
returned. (I haven’t tested the behavior with basic Auth.)
This is expected: if no authentication occurs (either basic authentication or
JWT) there is no way to enforce authorization - e.g. recognize the user, get
owned entitlements, apply security rules.
When the user “rossini” queries GET /users/self, then the user object is
returned and the header “x-syncope-entitlements: {"MUST_CHANGE_PASSWORD":[]}”
is set.
Correct.
I don't see reasons to restrict reading own profile, in this case.
When the user “rossini” uses PATCH /users/self and sets the
“mustChangePassword” flag to “false”, then the user object is updated (status
200).
I see two problems here: first, one shouldn't be allowed to reset his own
mustChangePassword flag; and second, PATCH (or PUT, or whatever self-modifying
operation) shouldn't be allowed when the MUST_CHANGE_PASSWORD entitlement is
owned.
Especially the last step is somewhat strange in my opinion and the question
arouse how is the use of this flag intended.
Please open an issue on JIRA for the defects above.
smime.p7s
Description: S/MIME cryptographic signature
