autoprovision new users on login

[butonic]

when the accounts service does not know an account (either by email, username, or custom claim) ocis-proxy should provision the user on the fly. should happen in a dedicated middleware that can be disabled via the config.

followup tasks

• only for certain email domains?
• only when the user is known in ldap?

[C0rby]

Who will authenticate the user in that situation?
konnectd, ldab or something else?

[kulmann]

I guess the normal request flow would be that this happens after the OIDC and account_uuid middlewares in ocis-proxy, so the user should be authenticated already. Just not provisioned in the accounts service, yet.

[kulmann]

In fact, it could happen within the account_uuid middleware

[C0rby]

From my understanding the plan is this

client -requests-> ocis-konnectd -requests-> ocis-glauth -requests-> ocis-account.
And this is how the authentication would work.

But if the ocis-accounts service doesn't know about a user then the above chain would not work since the authentication would fail in the ocis-accounts service.
Maybe my understanding is wrong.

[C0rby]

Here the diagram that @butonic drew.

[kulmann]

Step 1 is authenticated already. You only have a bearer token after a successful authentication. So this prerequisite: oidc auth is a blackbox for the authentication. Happens without any involvement of ocis-accounts.

[kulmann]

Or maybe I'm not up to date with how we store users. If glauth needs ocis-accounts in the future to do anything, then you're right. But I thought that glauth will continue to have a config file for the available "LDAP" users and not rely on ocis-accounts for that.

[C0rby]

Yeah, I think we should clarify that. 😄

[kulmann]

Hm... just thinking, this ticket is probably not about glauth, but only about scenarios where we have a real LDAP.

[C0rby]

Ok the scenario is as follows:

The idp has a source other than ocis-glauth/ocis-accounts and authenticates the user.
When the bearer token (may not be a jwt) reaches the ocis-proxy, it validates the token using the userinfo endpoint at the idp
if the token is valid the proxy tries to get the account from ocis-accounts.
If the service doesn't return an account ocis-proxy should create it.