Every time the OIDC middleware sees a new access token (i.e when it needs
to update the userinfo cache) we consider that as a new login. In this case
the middleware add a new flag to the context, which is then used by the
accountresolver middleware to publish a UserSignedIn event.
The event needs to be sent by the accountresolver middleware, because only
at that point we know the user id of the user that just logged in.
(It would probably makes sense to merge the auth and account middleware into a
single component to avoid passing flags around via context)
When auto-provisioning user accounts we used a fixed mapping for claims
for the userinfo response to user attributes. This change introduces
configuration options to defined which claims should be user for the
username, display name and email address of the auto-provisioned
accounts.
This also removes the automatic fallback to use the 'mail' claim as the
username when the 'preferred_username' claim does not exist.
Fixes: #8635
* feat: add CSP and other security related headers in the oCIS proxy service
* fix: consolidate security related headers - drop middleware.Secure
* fix: use github.com/DeepDiver1975/secure
* fix: acceptance tests
* feat: support env var replacements in csp.yaml
This gets us a rid of the need to configure the reva jwt secret in the
proxy. Also we no longer need to fake an internal admin user for
autoprovsioning user and/or assigning the roles to users from oidc
claims.
* Move away from global tracers.
This PR moves away from global tracers and instead initialises
a tracer provider at Service setup and passes it where it needs to be.
* Change tracing provider to be set via options.
Also change name for GetServiceTraceProvider.
* Add changelog.
* enhancement: use reva client pool selectors
register mock service to registry and pass tests
* enhancement: bump reva
* Fix a couple of linter issues
---------
Co-authored-by: Ralf Haferkamp <rhaferkamp@owncloud.com>
This reverts commit 52951b42b0.
The change broke authentication for at least the desktop client when
using the builtin idp. There seem to be issues in the IDP (lico) which
result in the implicit scoped not being added correctly in some case.
When that scope is missing the `lg.uuid` claim will not be present in
the userinfo and we can correctly match users by id.
This reverts back to the old behaviour of matching users by name. Which
also brings some aspects of https://github.com/owncloud/ocis/issues/904Fixes#6415
Reconfigure the oidc clients for lico, so that lico adds the "lg.uuid" to
tokens and userinfo by default. That claim will contain the userid. So
we can now use the userid for matching users when using the default
idm/idp configuration. This fixes further problems so that users being
recreated with the same name are correctly treated as differnt users.
Fixes: #904
