swift
swift copied to clipboard
Implement federated (v3oidcaccesstoken) auth
v3oidcaccesstoken requires two authentication requests:
- Retrieving an unscoped token using an oidc access token
- Retrieving a scoped token using the unscoped token (already implemented in v3auth)
Change summary:
- Extracted method for auth request handling
- Added missing fields to Connection, e.g. IdentityProvider
- Added mappings to the relevant openstack environment variables
- Added interface TwoStageAuthenticator
- Implemented PrelimRequest and PrelimResponse for v3auth
Sadly I saw no reasonable way to test these changes, but I'm completely open to suggestions. This includes the way I extended the authentication handling, which may or may not be optimal.
These changes are a follow up to this forum thread: https://forum.rclone.org/t/swift-env-auth-true-env-os-access-token-http-error-404-404-not-found/22520
Just thinking about the testability for a moment...
Currently we have an integration test which tests against a swift all in one docker
https://github.com/ncw/swift/blob/master/integration_test.sh
Could you add tests to that?
Hi,
in integration_test.sh
, you write v2 auth does't work for unknown reasons!
.
According to this issue, the reason seems to be that docker-swift (successor to bouncestorage/swift-aio) only mocks the authentication. For testing v2 and v3 auth, we would need a real keystone server instance.
I can certainly try to set this up if you think its reasonable.
Cheers,
Lukas
Hi, in
integration_test.sh
, you writev2 auth does't work for unknown reasons!
. According to this issue, the reason seems to be that docker-swift (successor to bouncestorage/swift-aio) only mocks the authentication.
Ah, ha!
For testing v2 and v3 auth, we would need a real keystone server instance. I can certainly try to set this up if you think its reasonable.
It would make the integration tests much more realistic.
How difficult would it be? If we could use docker to run a few containers other people maintain that would be fine.