Skip to content
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

Merged
merged 20 commits into from
Aug 22, 2022

Conversation

C0rby
Copy link
Contributor

@C0rby C0rby commented Aug 10, 2022

@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

  graph TD;
      OTHER_MIDDLEWARE-->OIDC;
      OIDC-->BASIC;
      BASIC-->SIGNED_URL;
      SIGNED_URL-->PUBLIC_SHARE;
      PUBLIC_SHARE-->TARGET;
Loading

Now instead of having multiple authentication middlewares sequentially, we have one authentication middleware which can invoke multiple authenticators

flowchart TD;
    OTHER_MIDDLEWARE-->AUTHENTICATION;
    subgraph AUTHENTICATION
    OIDC
    BASIC
    SIGNED_URL
    PUBLIC_SHARE
    end
   AUTHENTICATION-->A{Authenticated?}
   A{Authenticated?}--YES-->Target
   A{Authenticated?}--NO-->401_Response
Loading

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.

@C0rby C0rby self-assigned this Aug 10, 2022
@update-docs
Copy link

update-docs bot commented Aug 10, 2022

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.

@ownclouders
Copy link
Contributor

ownclouders commented Aug 10, 2022

💥 Acceptance test Core-API-Tests-ocis-storage-1 failed. Further test are cancelled...

Copy link
Collaborator

@kobergj kobergj left a comment

Choose a reason for hiding this comment

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

Some questions/remarks

services/proxy/pkg/middleware/oidc_auth.go Show resolved Hide resolved
services/proxy/pkg/middleware/oidc_auth.go Show resolved Hide resolved
services/proxy/pkg/middleware/oidc_auth.go Show resolved Hide resolved
services/proxy/pkg/middleware/basic_auth.go Show resolved Hide resolved
services/proxy/pkg/middleware/basic_auth.go Show resolved Hide resolved
services/proxy/pkg/middleware/oidc_auth.go Outdated Show resolved Hide resolved
services/proxy/pkg/middleware/basic_auth.go Show resolved Hide resolved
services/proxy/pkg/middleware/basic_auth.go Show resolved Hide resolved
Copy link
Contributor

@wkloucek wkloucek left a 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:

@C0rby C0rby changed the title Rewrite of the authentication middleware [full-ci] Rewrite of the authentication middleware Aug 11, 2022
@C0rby C0rby force-pushed the rewrite-auth-middleware branch from 558fe42 to ace9bca Compare August 11, 2022 10:56
@C0rby C0rby marked this pull request as draft August 11, 2022 11:14
@C0rby
Copy link
Contributor Author

C0rby commented Aug 11, 2022

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 https://github.com/owncloud/ocis/blob/cf8533cbb90dd8128ec614db8f36103f9453bbc5/deployments/examples/oc10_ocis_parallel/config/ocis/proxy.yaml#L60-L65
    )

Yeah, I think the code still needs some more changes.
I noticed that many things just happened implicitly because the requests still got routed to e.g. reva and there is more authentication logic...

David Christofas added 12 commits August 12, 2022 10:47
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.
@C0rby C0rby force-pushed the rewrite-auth-middleware branch from ace9bca to 5d45f0e Compare August 12, 2022 08:48
@C0rby C0rby marked this pull request as ready for review August 16, 2022 13:45
@C0rby C0rby requested review from wkloucek and kobergj August 16, 2022 13:45
@C0rby
Copy link
Contributor Author

C0rby commented Aug 16, 2022

I tested the example parallel deployment and the example wopi deployment and they worked for me. 👍

@wkloucek
Copy link
Contributor

I tested the example parallel deployment and the example wopi deployment and they worked for me. +1

I can confirm this in the case of the wopi example 👍
But the parallel deployment is still not working on my side. Marie still gets a 401 on https://cloud.owncloud.test/apps/files/ 🤔

@C0rby
Copy link
Contributor Author

C0rby commented Aug 17, 2022

Ok, let me check again.

@C0rby
Copy link
Contributor Author

C0rby commented Aug 17, 2022

You're right. I must've forgotten to replace the docker tag or something.
But it seems like to properly support the parallel deployment we would need to refactor the authentication middleware some more like I described it in the initial comment.

Copy link
Collaborator

@kobergj kobergj left a 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

services/proxy/pkg/middleware/authentication.go Outdated Show resolved Hide resolved
}

return res.Records[0].Value, nil
}

func (m SignedURLAuthenticator) Authenticate(r *http.Request) (*http.Request, bool) {
Copy link
Collaborator

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

@butonic
Copy link
Member

butonic commented Aug 18, 2022

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 🤔

@C0rby C0rby force-pushed the rewrite-auth-middleware branch from 2bbdfaa to 12d42e0 Compare August 22, 2022 12:24
@C0rby
Copy link
Contributor Author

C0rby commented Aug 22, 2022

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.

@C0rby C0rby force-pushed the rewrite-auth-middleware branch from 4b4be08 to dfe7032 Compare August 22, 2022 13:26
@wkloucek wkloucek dismissed their stale review August 22, 2022 13:28

outdated review

@sonarqubecloud
Copy link

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 4 Code Smells

15.6% 15.6% Coverage
0.0% 0.0% Duplication

@C0rby C0rby merged commit c4881f5 into master Aug 22, 2022
@delete-merged-branch delete-merged-branch bot deleted the rewrite-auth-middleware branch August 22, 2022 14:39
ownclouders pushed a commit that referenced this pull request Aug 22, 2022
Merge: 976a91c dfe7032
Author: David Christofas <[email protected]>
Date:   Mon Aug 22 16:39:03 2022 +0200

    Merge pull request #4374 from owncloud/rewrite-auth-middleware

    [full-ci] Rewrite of the authentication middleware
@wkloucek wkloucek mentioned this pull request Sep 16, 2022
9 tasks
@dragonchaser dragonchaser mentioned this pull request Nov 29, 2023
3 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants