Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

@grugna
Copy link
Contributor

@grugna grugna commented Feb 7, 2024

Depends on uc-cdis/arborist#163

New Features

Breaking Changes

Bug Fixes

Improvements

Use POST instead of GET /auth/mapping endpoint to enable client_credentials authentication

Dependency updates

Deployment changes

@paulineribeyre paulineribeyre self-requested a review March 1, 2024 22:55
resourcesEndpoint,
{
method: 'GET',
method: 'POST',
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a breaking change since the POST endpoint in older Arborist versions does not accept a token. I think we should add a retry here to make it backwards compatible - if the POST request doesn't work, try a GET request.

And a comment explaining the situation - we can remove the retry in a little while, when it will likely not cause issues

@paulineribeyre
Copy link
Contributor

@grugna eslint is complaining:

npm run eslint
  shell: /usr/bin/bash -e {0}

> @gen[3](https://github.com/uc-cdis/guppy/actions/runs/8179860773/job/22366757155?pr=254#step:8:3)/[email protected] eslint
> ./node_modules/.bin/eslint --ext js --ext jsx --fix src


/home/runner/work/guppy/guppy/src/server/auth/arboristClient.js
Error:   25:29  error  Expected '===' and instead saw '=='                                    eqeqeq
Error:   35:19  error  'response' is already declared in the upper scope on line 2[4](https://github.com/uc-cdis/guppy/actions/runs/8179860773/job/22366757155?pr=254#step:8:5) column [8](https://github.com/uc-cdis/guppy/actions/runs/8179860773/job/22366757155?pr=254#step:8:9)  no-shadow

✖ 2 problems (2 errors, 0 warnings)

Error: Process completed with exit code 1.

@paulineribeyre paulineribeyre changed the title using POST auth/mapping instead of GET to support client credentials authentication PXP-11248 PXP-11258 using POST auth/mapping instead of GET to support client credentials authentication Mar 6, 2024
@paulineribeyre
Copy link
Contributor

Tested in QA - Arborist logs:

  • Old guppy + old arborist:
172.20.114.101 - - [06/Mar/2024:22:45:09 +0000] "GET /auth/mapping HTTP/1.0" 200
  • Old guppy + new arborist:
172.20.106.8 - - [06/Mar/2024:22:56:44 +0000] "GET /auth/mapping HTTP/1.1" 200
  • New guppy + old arborist:
2024/03/06 22:50:27 server.go:286: INFO: tried to handle auth mapping request but input was invalid: could not parse JSON: unexpected end of JSON input
2024/03/06 22:50:27 server.go:291: INFO: must specify exactly one of `username` or `clientID`
172.20.86.25 - - [06/Mar/2024:22:50:27 +0000] "POST /auth/mapping HTTP/1.1" 400
172.20.86.25 - - [06/Mar/2024:22:50:27 +0000] "GET /auth/mapping HTTP/1.1" 200
  • New guppy + new arborist:
2024/03/06 22:53:47 server.go:325: INFO: No jwt provided, checking request body
2024/03/06 22:53:47 server.go:330: ERROR: tried to handle auth mapping request but input was invalid: could not parse JSON: unexpected end of JSON input
172.20.86.25 - - [06/Mar/2024:22:53:47 +0000] "POST /auth/mapping HTTP/1.1" 400 85 "" "node-fetch/1.0 (+https://github.com/bitinn/node-fetch)"
172.20.86.25 - - [06/Mar/2024:22:53:47 +0000] "GET /auth/mapping HTTP/1.1" 200 3668 "" "node-fetch/1.0 (+https://github.com/bitinn/node-fetch)"

The last one doesn't sound right ^ @grugna
It should only call POST and arborist should see the jwt

@grugna
Copy link
Contributor Author

grugna commented Mar 7, 2024

@paulineribeyre I agree it should only call a POST ( #254 (comment) ). I can't recreate it on my side, which images are you using?

2024/03/07 15:24:50 server.go:542: INFO: handling auth request: arborist.AuthRequest{Username:"[email protected]", ClientID:"", Policies:[]string(nil), Resource:"/analysis", Service:"analysis", Method:"access", stmts:(*arborist.CachedStmts)(0xc00008d3e0)}
2024/03/07 15:24:50 server.go:555: DEBUG: user is authorized
172.32.7.137 - - [07/Mar/2024:15:24:50 +0000] "POST /auth/request HTTP/1.1" 200 13 "" "python-httpx/0.25.0"
172.32.7.171 - - [07/Mar/2024:15:25:20 +0000] "GET /health HTTP/1.1" 200 9 "" "kube-probe/1.22+"
172.32.7.171 - - [07/Mar/2024:15:25:20 +0000] "GET /health HTTP/1.1" 200 9 "" "kube-probe/1.22+"

@paulineribeyre
Copy link
Contributor

@grugna Sorry for the confusion, the logs above are when the user is unauthenticated. No jwt, so it falls back on the request body.
The logs below are when the user is authenticated - it works fine:

  • New guppy + old arborist:
2024/03/07 16:04:59 server.go:286: INFO: tried to handle auth mapping request but input was invalid: could not parse JSON: unexpected end of JSON input
2024/03/07 16:04:59 server.go:291: INFO: must specify exactly one of `username` or `clientID`
172.20.65.253 - - [07/Mar/2024:16:04:59 +0000] "POST /auth/mapping HTTP/1.1" 400
2024/03/07 16:04:59 server.go:237: INFO: Attempting to get username from jwt...
2024/03/07 16:04:59 token.go:31: DEBUG: decoding token: <redacted>
2024/03/07 16:04:59 server.go:249: INFO: found username in jwt: [email protected]
172.20.65.253 - - [07/Mar/2024:16:04:59 +0000] "GET /auth/mapping HTTP/1.1" 200
  • New guppy + new arborist:
2024/03/07 16:08:17 server.go:293: INFO: Attempting to get username or client ID from jwt...
2024/03/07 16:08:17 token.go:31: DEBUG: decoding token: <redacted>
2024/03/07 16:08:17 server.go:312: INFO: found username in jwt: [email protected]
172.20.65.253 - - [07/Mar/2024:16:08:17 +0000] "POST /auth/mapping HTTP/1.1" 200

The concern I have is that when the user is unauthenticated, the endpoints have different behaviors:

  • GET /auth/mapping returns "anonymous" access
  • POST /auth/mapping returns an error

So with this code, for an unauthenticated user, we will always fall back to the GET endpoint and return "anonymous" access. If we ever remove the fallback to the GET endpoint from Guppy, the behavior will change to not supporting unauthenticated requests. I need to think about this a bit more, see if the Arborist logic can be refactored

@grugna
Copy link
Contributor Author

grugna commented Mar 7, 2024

Ah, I see what you are saying. @paulineribeyre I agree this would need to be an arborist change. Let me know if you want me to start another PR for that.

@paulineribeyre
Copy link
Contributor

Hi @grugna, I pushed a fix for the above and wrote down the results of my tests here: uc-cdis/arborist#164

If the changes look good to you, I think we can go ahead and merge this one

@paulineribeyre paulineribeyre merged commit c5e551b into uc-cdis:master Mar 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants