-
Notifications
You must be signed in to change notification settings - Fork 158
adr: Add thoughts about guest users #2183
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
The approach to take has not been decide yet. This just reflects the current research/concept work.
|
|
||
| ## Additional thoughts | ||
|
|
||
| If OpenCloud were responsible for allocating the UserIDs of all users |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point! I was wondering also, if that could simplify things in the future and let us get rid of the LDAP dependency.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AFAICT always having opencloud generate a userid would allow us to get rid of the shared ldap deployment mode. The ldap server would only be used to find recipients (users or groups) in an organization. We always only send invitations into some form of inbox of a user. This could literally be an email. Or an internal nats queue with invites.
Then, when he follows the invite link, we not only provision their personal space (guest users don't have one) but the invite they followed (the creat home call can add the grant). Invites are actually not a new concept. IMO it is just a better name for a pending share (they have three states: pending, accepted and declined).
When sharing with 'internal' users the invite service can take the responsibility of creating grants and accepting them instead of creating invites.
Anyway, IIRC we bounced around the idea of exchanging the sub+iss, basic auth or app password credentials in the proxy with a userid generated by opencloud years ago already. It has seeveral benefits:
- we can assign credentials and multiple identities (as in multiple Identity Providers) to an account. This allows migrating accounts from one IdP to another as the grants on disk can keep the same userid.
- we can add a
scim_idas an identitiy, which would make some use cases follow the standard integration of SCIM and OpenID Connect we could use SCIM to provision a guest account in the Identity management system.
The last point addresses the problem that if a user shares with a guest, aka an email address, that needs to trigger an onboarding process for the new guest. If we just create a new user in a keycloak that we have write permission to we are back at the same shadow it user management as before.
We could use OpenID Connect Discovery to find the external issuer and trust that to authenticate users. OIDC in theory is federated. However, in practice our clients would have to dynamically register with the guests IdP ... which does not seem to be widely supported, yet.
I think we should use a list of trusted identity providers, this would allow a single instance to use multiple identity providers, eg for multi tenancy use cases or when organization merge and multiple idps exist for a wile or to better reflect the sovereignty of organizations.
If no idp is responsible for the guest email, we can use a fallback idp that is only used for guest accounts. We already have the webfinger service that we can use for the issuer discovery.
So ... yes, please ... make opencloud generate a userid.
| account in the IDP, and might be external to the organization), it should | ||
| be possible to invite "Guest Users" into and OpenCloud instance. | ||
|
|
||
| ## Requirements |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with the requirements. Maybe we need to add that the process can be asynchonous and take some time because we are crossing a lot of boundaries between different systems.
|
|
||
| To allow collaboration with external Users (Users that don't yet have an | ||
| account in the IDP, and might be external to the organization), it should | ||
| be possible to invite "Guest Users" into and OpenCloud instance. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| be possible to invite "Guest Users" into and OpenCloud instance. | |
| be possible to invite "Guest Users" into an OpenCloud instance. |
The approach to take has not been decided yet. This just reflects the current research/concept work.