The endpoints are no longer hashed by path name in the directors map since
that made iterating over the endpoints unstable. They are now stored in a
slice in the order in which the are defined in the configuration.
Closes: #4497
Allows /archiver to be used the "public-token" auth middleware. The
archiver is a bit of a special case, because it can be uses in several
ways: using 'normal' authentication (basic, oidc), using signed-urls or
using sharetokens. As only the "sharetoken" part is handled by the
"PublicShareAuth" middleware, we needed to special-case it a bit.
This is a quickfix for #4497. Before evaluating, we now sort the rules
of a specific type by the length of the endpoints and start evaluation
with the most specific endpoint first. There's obviously quite a bit
room for optimization here and this will only fix the issue for routes
of type `PrefixRoute`. But it should solve the immediate issue.
I added an unprotected flag to the proxy routes which is evaluated by
the authentication middleware. This way we won't have to maintain a
hardcoded list of unprotected paths and path prefixes and we will
hopefully reduce the times we encounter the basic auth prompt by web
browsers.
I refactored the proxy so that we execute the routing before the
authentication middleware. This is necessary so that we can determine
which routes are considered unprotected i.e. which routes don't need
authentication.
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.
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.
Allow to switch jwt access token verification and off. Many (most?) IDP
provide JWT encoded access tokens. If ocis is configure to assume jwt
access tokens (access_token_verify_method==jwt) we now properly verify
the tokens signature and a set of standard claims ("exp", "iat" and nbf"
by way of the jwt module's standard verification and "iss" explicitliy).
This change also allows for introduction of other access token verification
mechanism in the future (e.g. through introspection (RFC7662).
We try to parse the access token as a JWT now. Verifying the signature
using the keys downloaded from the jwks_uri of the IDP. Currently we
only use it to extract the expiry information from the JWT. This could
be reworked to extract other claims from the token for authorization
purposes.
Fixes: #3841
