user autoprovsioning lacking support for renames

[rhafer]

Describe the bug

Currently the auto provisioning feature in the ocis proxy relies on the confgured PROXY_USER_OIDC_CLAIM (email by default) to be stable. If a user gets renamed (or changes its mail address) in the external IDP the proxy would provision an new user with a new user id for that. Resulting in that user to have access to files and shares anymore. (Note: this is nothing new it behaves similar to what the auto provision via accounts service did in this regard)

Ideally the auto provisioning feature would keep track of the iss/sub claims of the users and store that together with the user (the MS graph identities property seems like a good fit for such data). As the combination of the iss and sub claims is supposed to be stable the auto provisioning feature could use that data to detect renames and apply them accordingly.

[kaivol]

What is the status on this or are there any workarounds one could use?

I tried setting the PROXY_USER_OIDC_CLAIM variable to different values, but that does not seem to have any effect.

[skeletorXVI]

What is the status on this or are there any workarounds one could use?

I tried setting the PROXY_USER_OIDC_CLAIM variable to different values, but that does not seem to have any effect.

Even in 3.0.0-rc.1 PROXY_USER_OIDC_CLAIM still doesn't do anything, so i tried setting user_oidc_claim in the proxy.yaml and that entirely bricked authentication:

In the pod logs I am seeing the following errors:

{"level":"debug","service":"gateway","pkg":"rgrpc","traceid":"00000000000000000000000000000000","user-agent":"grpc-go/1.56.2","from":"tcp://127.0.0.1:32812","uri":"/cs3.gateway.v1beta1.GatewayAPI/Authenticate","start":"20/Aug/2023:17:55:01 +0000","end":"20/Aug/2023:17:55:01 +0000","time_ns":22948144,"code":"OK","time":"2023-08-20T17:55:01.182811632Z","line":"github.com/cs3org/reva/v2@v2.15.1-0.20230731132956-0fb5212d0551/internal/grpc/interceptors/log/log.go:69","message":"unary"}
2023/08/20 17:55:01 http: panic serving 10.42.1.37:39542: runtime error: invalid memory address or nil pointer dereference
goroutine 5189 [running]:
	net/http/server.go:2122 +0x2f
github.com/owncloud/ocis/v2/services/proxy/pkg/middleware.OIDCWellKnownRewrite.func1.1({0x7f239703c000, 0xc0022baa40}, 0xc001a2cf00?)
	github.com/owncloud/ocis/v2/services/proxy/pkg/middleware/oidc_well-known.go:45 +0x313
net/http.HandlerFunc.ServeHTTP(0xc001fe79b0?, {0x7f239703c000?, 0xc0022baa40?}, 0xccb7c5?)
	net/http/server.go:2122 +0x2f
github.com/owncloud/ocis/v2/services/proxy/pkg/middleware.HTTPSRedirect.func1({0x7f239703c000, 0xc0022baa40}, 0xc001a2cf00)
	github.com/owncloud/ocis/v2/services/proxy/pkg/middleware/https_redirect.go:17 +0x142
net/http.HandlerFunc.ServeHTTP(0x4520130?, {0x7f239703c000?, 0xc0022baa40?}, 0xc?)
	net/http/server.go:2122 +0x2f
github.com/owncloud/ocis/v2/services/proxy/pkg/middleware.AccessLog.func1.1({0x4520130, 0xc002651c20}, 0xc001a2cf00)
	github.com/owncloud/ocis/v2/services/proxy/pkg/middleware/accesslog.go:20 +0x1e7
net/http.HandlerFunc.ServeHTTP(0x4520868?, {0x4520130?, 0xc002651c20?}, 0x3c11168?)
	net/http/server.go:2122 +0x2f
github.com/go-chi/chi/v5/middleware.RequestID.func1({0x4520130, 0xc002651c20}, 0xc001a2ce00)
	github.com/go-chi/chi/v5@v5.0.8/middleware/request_id.go:76 +0x22d
net/http.HandlerFunc.ServeHTTP(0xc001a2ce00?, {0x4520130?, 0xc002651c20?}, 0xc000fdbc00?)
	net/http/server.go:2122 +0x2f
github.com/go-chi/chi/v5/middleware.RealIP.func1({0x4520130, 0xc002651c20}, 0xc001a2ce00)
	github.com/go-chi/chi/v5@v5.0.8/middleware/realip.go:36 +0x9e
net/http.HandlerFunc.ServeHTTP(0x100?, {0x4520130?, 0xc002651c20?}, 0x451f680?)
	net/http/server.go:2122 +0x2f
github.com/owncloud/ocis/v2/ocis-pkg/middleware.TraceContext.func1({0x4520130, 0xc002651c20}, 0xc001a2cd00)
	github.com/owncloud/ocis/v2/ocis-pkg/middleware/tracing.go:19 +0x184
net/http.HandlerFunc.ServeHTTP(0x4520868?, {0x4520130?, 0xc002651c20?}, 0x451f680?)
	net/http/server.go:2122 +0x2f
github.com/owncloud/ocis/v2/services/proxy/pkg/middleware.tracer.ServeHTTP({{0x450a280?, 0xc00172a960?}, {0x4509580?, 0x60643a0?}}, {0x4520130, 0xc002651c20}, 0xc001a2cc00)
	github.com/owncloud/ocis/v2/services/proxy/pkg/middleware/tracing.go:50 +0x482
go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp.(*middleware).serveHTTP(0xc001992790, {0x451dc70?, 0xc00178d0a0}, 0xc001a2cb00, {0x4502cc0, 0xc0017bb000})
	go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp@v0.42.1-0.20230608065455-5cc3715df180/handler.go:217 +0x122e
go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp.NewMiddleware.func1.1({0x451dc70?, 0xc00178d0a0?}, 0x40aaf60?)
	go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp@v0.42.1-0.20230608065455-5cc3715df180/handler.go:81 +0x3b
net/http.HandlerFunc.ServeHTTP(0xc001b1a128?, {0x451dc70?, 0xc00178d0a0?}, 0x46ff30?)
	net/http/server.go:2122 +0x2f
net/http.serverHandler.ServeHTTP({0xc001fe7950?}, {0x451dc70, 0xc00178d0a0}, 0xc001a2cb00)
	net/http/server.go:2936 +0x316
net/http.(*conn).serve(0xc001b37050, {0x4520868, 0xc001640de0})
	net/http/server.go:1995 +0x612
created by net/http.(*Server).Serve
	net/http/server.go:3089 +0x5ed

On the browser I am simply seeing

While this is not a major issue for me (only family members and friends are accessing my instance), it is still somewhat of an issue, as the less tech inclined may change their usernames (happened already once).

[kaivol]

Any updates on this? Are there still plans to fix the bug?

[dj4oC]

@nicholas-wilson-au are you aware of it?

[nicholas-wilson-au]

I am using PROXY_USER_OIDC_CLAIM: "sub" successfully. Not sure if this issue still exists in its entirety.

[micbar]

@nicholas-wilson-au @dj4oC You setting has no effect. See #8635

[kaivol]

With the recent changes in #8956, #8952, does OCIS now support OIDC providers without stable preferred_username and email?

And if so, which environment variables do I have to set?
I've seen an example configuration here, is that all that's required (in addition to the standard OIDC configuration)?

[rhafer]

And if so, which environment variables do I have to set?
I've seen an example configuration here, is that all that's required (in addition to the standard OIDC configuration)?

Yes. That should be it. But please be aware, that that configuration will result in the usernames of the autoprovisioned users in ocis will be populated with the value of the "sub" claim. I.e. they'll be more or less looking like randon string or UUIDs (depending on your IDP)

[kaivol]

Thanks for the clarification!

But please be aware, that that configuration will result in the usernames of the autoprovisioned users in ocis will be populated with the value of the "sub" claim

Does this have any (negative) consequences that I am not aware of?
Is the username even shown anywhere except on the Account overview page?

---

AIso, is it possible to migrate form the default configuration to a custom one, and if so, what do I have to consider in this process?

[rhafer]

Does this have any (negative) consequences that I am not aware of? Is the username even shown anywhere except on the Account overview page?

I think it will have at least and impact when creating shares. E.g. when searching for people to share with we're matching the search term against username, displayname and email. It's probably not a not a big issue, but you might have unexpected results poping up in that search page.

AIso, is it possible to migrate form the default configuration to a custom one, and if so, what do I have to consider in this process?

A manual migration should be possible but might be cumbersome. Basically you would have to update the username for all users that have been provisioned already and change it from the old claim's value to the value of the sub claim. It should be possible to do this via the graph API (https://owncloud.dev/libre-graph-api/#/user/UpdateUser) or via the builtin LDAP server directly (https://owncloud.dev/services/idm/configuration_hints/#access-via-ldap-command-line-tools). As said this is somewhat cumbersome and I'd recommend you to try it out in a test environment first. Please be aware, that deleting all autoprovisioned users and then having them recreated with the new settings will NOT work this would result in a change of the users' unique identifier in ocis and the user won't have access to their data anymore.

[kaivol]

I think it will have at least and impact when creating shares. E.g. when searching for people to share with we're matching the search term against username, displayname and email. It's probably not a not a big issue, but you might have unexpected results poping up in that search page.

Maybe a setting that changes this behavior would make sense?
But then again it is rather unlikely that a search would coincidentally match a (typically randomly generated) sub value.

Also one last question:
If a user changes their Email or Display name, are these changes reflected in OCIS-internal users list?

[rhafer]

If a user changes their Email or Display name, are these changes reflected in OCIS-internal users list?

In latest master yes. (Was added with #9166)