On 23/10/18 10:49, Lukas Funk wrote:
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?
I see your point - and that you've already reported as such in
SYNCOPE-1388, ok.
Regards.
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.
--
Francesco Chicchiriccò
Tirasa - Open Source Excellence
http://www.tirasa.net/
Member at The Apache Software Foundation
Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
http://home.apache.org/~ilgrosso/
