You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@syncope.apache.org by Lukas Funk <Lu...@united-security-providers.ch> on 2018/10/22 13:37:21 UTC
mustChangePassword flag intended use?
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.
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.)
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.
When the user "rossini" uses PATCH /users/self and sets the "mustChangePassword" flag to "false", then the user object is updated (status 200).
Especially the last step is somewhat strange in my opinion and the question arouse how is the use of this flag intended.
Regards, Lukas
Re: mustChangePassword flag intended use?
Posted by Francesco Chicchiriccò <il...@apache.org>.
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/
RE: mustChangePassword flag intended use?
Posted by Lukas Funk <Lu...@united-security-providers.ch>.
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.
Re: mustChangePassword flag intended use?
Posted by Francesco Chicchiriccò <il...@apache.org>.
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.
Regards.
--
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/