The legacy OC-Signature path already rejects methods outside
PRE_SIGNED_URL_ALLOWED_HTTP_METHODS, the JWT path did not. A leaked
signed download url could be used for PUT, DELETE, MOVE or PROPFIND
as the signing user for the lifetime of the signature.
This fixes error logs like
RR error when calling Createhome error="gateway: grpc failed with code CODE_INVALID_ARGUMENT" line=github.com/opencloud-eu/opencloud/services/proxy/pkg/middleware/create_home.go:87 service=proxy
e.g. during internal requests to the data provider.
This is to reduce the number of "proxy->gateway->users->ldap" roundtrips
for the tenant id mapping.
The cache currently has a non-configurable ttl of 10 min.
Related: #2310
When the tenant id coming in via the OIDC claims doesn't match the
tenant id on the provisioned user, a mapping can be configured and
resolved via the reva TenantAPI service (now started as part of the
"users" service).
Closes: #2310
When multi-tenancy is enable we now allow to specify an OIDC claim
against which the tenantid of the user resolved via CS3 apis is matched.
Partial: #2310
When the userinfo claims store in the usercache is found to be expired,
do not return an error but ignore the cached entry and force a
re-verification of the access token (either via parsing the JWT again or
via a UserInfo lookup).
This is required for setups with non-JWT access tokes where the expiry
date set in the cached claims does not reflect the actual token expiry,
but just the CacheTTL.
Fixes: #1493
With the ocdav service being able to provided signed download URLs we
need the proxy to be able to verify the signatures.
This should also be a first step towards phasing out the weird ocs based
client side signed urls.
Related Tickets: #1104
After autoprovisioning a user, we need to get a reva token via
`auth-machine`. If that fails the code would panic because the logger
tried to access the `user` object returned from the GetUserByClaims
call. Which is `nil`in case failure.
Fixes#936
This introduces the "additional_headers", "remote_user_header" and
"skip_x_access_token" config keys to allow configuring routes to
external services that require addtional headers to be set.
"remote_user_header": defines the name of a Header that will carry the
userid of the authenticated user on the outgoing request.
"additional_headers": defines a list of header names and values that will
be added to outgoing requests on matching routes.
"skip_x_access_token": when set to true the reva access token will not
be added to the outgoing request.
Needed for #206
When successfully authenticating a user via apptoken, resolve the user's
roles and add the user and the token returned by the auth service to the
request context. Rely on the account_resolve middleware to add the reva
token to the outgoing request as the other auth middlewares do.
Alex Ababii