Allow caller with uaa.admin scope to change a user's password

[trevor-morris]

The documentation for the change user password call says, for Authorization:

Access token with password.write or uaa.admin required

However the current configuration only allows the call if the caller has the password.write scope.

This fix changes the configuration to match the documentation. It replaces:

IS_AUTHENTICATED_FULLY,scope=password.write

with the expression:

isFullyAuthenticated() and #oauth2.hasAnyScope('password.write')

The UAA custom version of hasAnyScope has an internal check for the uaa.admin scope. It also removes the passwordResourceAuthenticationFilter, which also insisted on a scope with the password prefix.

[cf-gitbot]

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/171323457

The labels on this github issue will be updated when the story is started.

[linux-foundation-easycla[bot]]

The committers are authorized under a signed CLA.

• :white_check_mark: Trevor Morris (687ef2ee8577b1ef08cd193076d561d2d82e726e)

[trevor-morris]

I've signed the CLA, though it doesn't seem to be showing up here yet

[trevor-morris]

Any way to get rid of the "CLA Not Signed" error? I did sign the CLA over a week ago but I'm not seeing any change on this pull request. I thought I'd try to go through "Easy CLA" again but I guess it does know I signed because it just redirects me back to here, doesn't put up the form to sign any more.

[Birdrock]

@trevor-morris I've reached out to our organization to investigate this. I'll let you know if I hear something.

[cf-gitbot]

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/171614728

The labels on this github issue will be updated when the story is started.

[christopherclark]

Hi all. I asked LF IT To check on this, and they say "I can see that his commit itself isn't authored correctly from GitHub's view, probably the email isn't matching https://help.github.com/en/github/committing-changes-to-your-project/why-are-my-commits-linked-to-the-wrong-user Most people correct that with a force push and the bot should recheck it."

Let me know if this helps (or, if it doesn't). Sorry for the inconvenience!

[trevor-morris]

I wonder if the author email is wrong in my commit? I'll check when I get home - I made the commit on my home machine but it's possible I've got my work email configured on my home machine.

Thanks for looking at this

[trevor-morris]

The email address in the commit was the problem with EasyCLA. I'd pushed from a shell where my user email was set to my work email, so it didn't match my GitHub email (or the one on the signed document).

Thanks to Christopher and Andrew for looking at this

[trevor-morris]

I just saw: https://www.pivotaltracker.com/n/projects/997278/stories/171614728 which suggests that the plan is to update the documentation rather than allow somebody with uaa.admin scope to update the password.

If that's the plan then is there any way a service, using a token allocated via client credentials flow, can change the password of a user in an identity zone other than the default zone? The "password.write" scope doesn't seem to survive the IdentityZoneSwitchingFilter so if you provide an identity zone via the X-Identity-Zone-Id header and the "password.write" scope then the scope gets stripped out by the filter and your call fails

[strehle]

@trevor-morris is this still an issue for you? I would accept this if you add an integration test