Correct the principle username detection for OAuth 2.0 Client Credentials grant

[ministryofjustice]

Correct the principle username detection for OAuth 2.0 Client Credentials grant

[petergphillips]

For endpoints that create data you need to provide an extra parameter when you create the client credentials of username=<valid nomis user>.

[boydingham]

This one and these other two...

1. Fix o.s.d.DataIntegrityViolationException in /api/offenders/
2. Fix the build/config so that running locally on Windows 'Just Works'

...Will be what I would like to pick your brains on @petergphillips @andymarke, whenever we get a chance to talk off line.

[boydingham]

Thank you @petergphillips,

"...For endpoints that create data you need to provide an extra parameter when you create the client credentials of username=<valid nomis user>..."

I will give that a shot in a few.

I guess that's an example of what they call "Implicit Knowledge" (aka, "Tribal Knowledge"). Right? Because I haven't seen that documented anywhere. And I've read a ton of stuff so far about several different HMPPS/MOJ/DPS projects.

Please correct me if I'm wrong though. Please point me to the documentation of that, that I overlooked? TIA.

[boydingham]

"...<valid nomis user>..."

I will proceed on the assumption that "ITAG_USER" is one such <valid nomis user>.

Or can you share any shortcuts to getting a hold of a known <valid nomis user> @petergphillips ? It might be valuable to share that here; on the off chance that other future non-DPS devs stumble across this same issue. TIA.

[boydingham]

"...<valid nomis user>..."

I will proceed on the assumption that "ITAG_USER" is one such <valid nomis user>...

Dear "other future non-DPS devs",

I am pleased to report that "ITAG_USER" is, indeed, one such <valid nomis user> :)

I confirmed that, @petergphillips, with two curl calls from the command line...

1. Appending username=<valid nomis user> to the token request to hmpps-auth
2. Calling the /api/offenders/{offenderId}/booking endpoint with that access token

Now that leaves only the Spring Security OAuth 2.0 client credentials configuration so that it does those two things on my behalf, under the covers. Right @petergphillips?

If you could share any shortcuts for (or even better, links to documentation of) that configuration, that'd be so super deluxe! TIA.

[boydingham]

...Now that leaves only the Spring Security OAuth 2.0 client credentials configuration so that it does those two things on my behalf, under the covers. Right @petergphillips?...

The Customizing the Access Token Request section of the Spring Security OAuth 2.0 reference documentation offers some pretty decent guidance.

I'm reasonably certain as far as the "What" needs to be customized goes. My first stab at the specifics (i.e., the "How") still needs a little more work though.

In the meantime, any links to hints, tips or suggestions are welcome @petergphillips. TIA.

[boydingham]

...
...My first stab at the specifics (i.e., the "How") still needs a little more work though...

I've worked out a now-working configuration @petergphillips. I found the missing piece of the puzzle in the Spring Security JavaDoc...

...
Use OAuth2AuthorizedClientArgumentResolver(OAuth2AuthorizedClientManager) instead. Create an instance of ClientCredentialsOAuth2AuthorizedClientProvider configured with a DefaultClientCredentialsTokenResponseClient (or a custom one) and than supply it to DefaultOAuth2AuthorizedClientManager
...

The Spring Security OAuth 2.0 configuration I now have in place, now programmatically does the needful "...provide an extra parameter when you create the client credentials of username=<valid nomis user>" step.

Thanks again for sharing that username=<valid nomis user> clue 👍

[petergphillips]

Sorry for the delay. An example of where we configure the web client to add the username can be found in WebClientConfiguration and the code for the converter is CustomOAuth2ClientCredentialsGrantRequestEntityConverter