For some reason LDAP_BIND_PASSWORD was forgotten when all the other global LDAP_
variables got renamed.
Also marks LDAP_BIND_PASSWORD and LDAP_USER_SCHEMA_ID_IS_OCTETSTRING for removal with 5.0.0
Partial: #7176
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
Fixes: 5906
After clarification and renaming th envvar and post a discussion with @rhafer, we should align the yaml name to the envvar name. Note that the backend name (`Insecure`) is not changed.
* In the deployment examples, we use ennvars and no yaml
* ocis init does not use it
This adds support for configuring an LDAP Attribute that can be used as a flag
to disallow users to login. We currently default to 'ownCloudUserEnabled' as
used in the default configuration of the graph service.
* walk and log chi routes, ocs cleanup
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
* make linter happy
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
TLS for the services can be configure by setting the "OCIS_HTTP_TLS_ENABLED",
"OCIS_HTTP_TLS_CERTIFICATE" and "OCIS_HTTP_TLS_KEY" environment variables.
Currently the ocis proxy is this only service that directly accesses backend
services. It determines whether to use TLS or not by looking a the new registry
metadata "use_tls". As specific CA Cert for certificate verification
can be set with the "PROXY_HTTPS_CACERT" environment variable.
* Introduce TLS Settings for go-micro based grpc services and clients
TLS for the services can be configure by setting the OCIS_MICRO_GRPC_TLS_ENABLED"
"OCIS_MICRO_GRPC_TLS_CERTIFICATE" and "OCIS_MICRO_GRPC_TLS_KEY"
enviroment variables.
TLS for the clients can configured by setting the "OCIS_MICRO_GRPC_CLIENT_TLS_MODE"
and "OCIS_MICRO_GRPC_CLIENT_TLS_CACERT" variables.
By default TLS is disabled.
Co-authored-by: Martin <github@diemattels.at>
* Unify TLS configuration for all grpc services
All grpc service (whether they're based on reva) or go-micro use the
same set of config vars now.
TLS for the services can be configure by setting the OCIS_GRPC_TLS_ENABLED,
OCIS_GRPC_TLS_CERTIFICATE and OCIS_GRPC_TLS_KEY enviroment variables.
TLS for the clients can configured by setting the OCIS_GRPC_CLIENT_TLS_MODE
and OCIS_MICRO_GRPC_CLIENT_TLS_CACERT variables.
There are no individual per service config vars currently. If really
needed, per service tls configurations can be specified via config file.
Co-authored-by: Martin <github@diemattels.at>
Co-authored-by: Martin <github@diemattels.at>
Consolidate all services to use the Reva config struct for the shared package.
This works because all services (except 'notifications', 'thumbnails' and
'webdav') where using the same config keys and environment variables for
setting the reva gateway.
