routing and authentication clarification

[butonic]

Currently, the idea is that the gateway serves the cs3 api to the outside world and any client like the ocdav service. It is a facade that is used to authenticate requests and route the request to the correct cs3 service. Authentication and routing go hand in hand, because the user may have an influence on the routing decision.

For larger deployments oidc or at least ldap are used. Both have a way to return user metadata as part of the user authorization process, which is why we want to be able to read them during authentication: https://github.com/cs3org/reva/pull/384

We still only use the userid from that response and send it to a user manager that will return the actual user object: https://github.com/cs3org/reva/blob/master/internal/grpc/services/gateway/authprovider.go#L93

Regarding authentication

• [ ] get rid of the user metadata lookup. The auth manager drivers can return a proper user object. This is authentication. oidc and ldap can return all the necessary user metadata. The user identifier might not be as stable as we want, but we need a cli tool to change it anyway (tracked in https://github.com/owncloud/ocis/issues/58).
• [ ] add an optional identity middleware that maps the user to a stable id: it will get a full userobject and can be used to maintain a mapping to a uuid based userid. For example a basic auth against an ldap server could use an identitiy middleware to lookup a stable user id in a SCIM services using his email. It would then replace the id in the user object with that id. If for whatever reason the email, the dn ort the uuid in ldap chinges reva can still identify the user using the SCIM service (this obviously only makes sense if SCIM is also configured as a user provider to handle tho userid to metadata lookup, eg. when listing file metadata)

Regarding authorization:

• [ ] we need to be able to add roles and permissions in a yet to implement account middleware, because oidc does not specify how they should be sent as claims. not every idp will be able to handle the permissions we want to use in reva / cs3

Regarding Credentials: In some cases a service might want to send its own credentials to the client, eg. WOPI. Thes credentials need to be passed on to the service, even if the CS3 api is used to wrap it. Another example is a windows network drive storage provider which needs to be able to send the WWW-Authenticate header in order to send the challenge to the client: https://tools.ietf.org/html/rfc4559#section-4.1. And finally we want to pass on the oidc bearer token to other services (see https://github.com/owncloud/ocis/issues/53)

We currently replace the whatever credentials were given with a JWT that services behind the gateway use to authenticate requests. The idea is to keep auth in a single place, just like tracing and logging. That might not be sustainable:

1. As mentioned above, some services need more control over the authentication
2. traces should reveal which service is affected. Piping everything through the gateway would show all requests, but not exactly what is going on where. Meanwhile every reva instance can be configured to enable tracing. So we are not even using the gateway for that anymore.
3. the situation with logging is the same as for tracing

In effect we use the gateway as an auth middleware AND a router. Some requests may require the user id for routing. If that is the case we should put the id inside the endpoint url or as a parameter to the grpc call.

Every service should use the auth (identity and account) middleware as necessary. That would get rid of the whitelisting in the gateway: the oidc provider does not require authentication on the login page, phoenix does not need any authentication at all.

The reva gateway should only handle the routing. And it should not need an authenticated user to make routing decisions. The services that do need authentication can do so on the credentials using the middleware that is part of their configuration. It can even return the generated JWT to let clients do further requests without having to do the same authentication again.

Anyway ... something I'll look into more thoroughly next week.

[butonic]

Another idea is to add a config option to the oidc auth provider to choose which attribute to use as the opaqueid. sub is useless, because it is not reversible. It could be set to another claim like mail, preferred_username, scim_id or a custom claim. The gernerated userid will be used by the user manager to look up the user object. This happens in the gateways Authenticate method, so we can replace the id with whatever the user manager decides. To get truly stable user identifiers an oidc auth provider could be used to use the preferred_username as the opaque id together with an scim user provider that uses the username to look up the user and then use the scim_id as the opaque id.

[butonic]

Ok, that helps me implement a scim and graph user manager that can use a custom id to look up the user metadata.

• [ ] the oidc auth provider might not have to do the userinfo call to lookup user metadata it is ignored anyway, as it will be replaced with what the user provider returns. currently, the oidc user provider is broken because it expects the claims to be stored in the context by the oidc auth provider. Instead the oidc auth provider should use a claim like preferred_username or email to look up the user by that userid in the ldap user provider.

• [ ] how we pass on claims or at least authorization headers is still not clear. But related. we could pass on the auth header as is ... that would also allow the oidc auth provider to only authenticate the user and the user manager to continue and do the userinfo lookup.

• [ ] for wnd we would need to have a way back from the storage provider to let the gateway know that a different authentication is necessary. this is something for next week.