-
Notifications
You must be signed in to change notification settings - Fork 187
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[full-ci] Rewrite of the authentication middleware #4374
Conversation
Thanks for opening this pull request! The maintainers of this repository would appreciate it if you would create a changelog item based on your changes. |
💥 Acceptance test Core-API-Tests-ocis-storage-1 failed. Further test are cancelled... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some questions/remarks
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did a quick testing with following deployment examples:
- oCIS with WOPI / Collabora / OnlyOffice
- opening a document does not work because a 401 on this url: https://ocis.owncloud.test/external/spaces/1284d238-aa92-42ce-bdc4-0b0000009157$7f1c5702-7d39-474c-a882-0235cf282daa/OfficeDocument%20Test%20files/file-sample_1MB.docx?app=Collabora&fileId=1284d238-aa92-42ce-bdc4-0b0000009157%247f1c5702-7d39-474c-a882-
- Parallel deployment
- logging in as Marie does not work, because she is configured to use oC10 which results in a 401 on this url: https://cloud.owncloud.test/apps/openidconnect/redirect (see also proxy config
ocis/deployments/examples/oc10_ocis_parallel/config/ocis/proxy.yaml
Lines 60 to 65 in cf8533c
- name: oc10 routes: - endpoint: "/" backend: http://oc10:8080 - endpoint: "/data" backend: http://localhost:9140
- logging in as Marie does not work, because she is configured to use oC10 which results in a 401 on this url: https://cloud.owncloud.test/apps/openidconnect/redirect (see also proxy config
558fe42
to
ace9bca
Compare
Yeah, I think the code still needs some more changes. |
The old approach of the authentication middlewares had the problem that when an authenticator could not authenticate a request it would still send it to the next handler, in case that the next one can authenticate it. But if no authenticator could successfully authenticate the request, it would still be handled, which leads to unauthorized access.
I admit it would be better to implement the tests but I tried and it is a bit tricky since we can't mock everything we would need to mock. I'll wan to get these changes in first and later in the near future we should revisit the auth middleware architecture and refactor it a bit more to be more testable and future proof.
ace9bca
to
5d45f0e
Compare
I tested the example parallel deployment and the example wopi deployment and they worked for me. 👍 |
I can confirm this in the case of the wopi example 👍 |
Ok, let me check again. |
You're right. I must've forgotten to replace the docker tag or something. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One critical question. Rest is optional
} | ||
|
||
return res.Records[0].Value, nil | ||
} | ||
|
||
func (m SignedURLAuthenticator) Authenticate(r *http.Request) (*http.Request, bool) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still no comment, also for other Authenticate
funcs
in reva http services can maintain a list of unprotected endpoints, eg. for ocdav Since our 'proxy' is actually an API gateway that authenticates requests, I wonder how go micro marks routes as unprotected 🤔 |
2bbdfaa
to
12d42e0
Compare
Can someone mark the "vulnerability" in Sonarcloud as false positive? It's just complaining about a string constant which contains "credential" in the name. I can't do that, probably because the PR is from me. |
4b4be08
to
dfe7032
Compare
Kudos, SonarCloud Quality Gate passed! |
@xoxys found out that it was possible to send unauthenticated requests to the settings service.
As it turned out it was generally possible to send unauthenticated requests to any service. The reason for this that we had multiple authentication middlewares which were called sequentially. When the current authenticator wasn't able to authenticate the request it would just pass it onto the next http handler in case any following middleware could authenticate it. In the end when no authenticator was able to authenticate the request the request still continued to the target service and was handled.
Here is a simplified diagram of the old behavior
Now instead of having multiple authentication middlewares sequentially, we have one authentication middleware which can invoke multiple authenticators
While this is already an improvement, this also introduced new problems. The requests for the static resources of the web client aren't authenticated, which means they would be blocked by the authentication middleware. To work around this I had to introduce a static list of paths and path prefixes for "unprotected" paths i.e. paths which don't require authentication.
Maintaining that list will probably be a large pain so to make that cleaner and future proof we should consider something like adding an "unprotected" flag to the proxy routes. Then we could resolve the routes before the authentication middlewares are invoked so we have that extra information while handling the authentication of the request.
I left this out of this PR so that it won't get too big and I didn't want to introduce too many changes to a critical part like authentication.