adr: Add thoughts about guest users#2183
Conversation
The approach to take has not been decide yet. This just reflects the current research/concept work.
rhafer
requested review from
aduffeck,
db-ot,
dragonchaser,
dragotin,
micbar and
tbsbdr
|
|
||
| ## Additional thoughts | ||
|
|
||
| If OpenCloud were responsible for allocating the UserIDs of all users |
There was a problem hiding this comment.
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.
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.
| using the Keycloak Admin API | ||
| - As part of the user creation keycloak triggers an email to be sent to | ||
| the invited user to get him to verify his email address and set a | ||
| password. This is not really and invitation email. |
There was a problem hiding this comment.
That is not enough. We need to be in control of that EMail probably.
There was a problem hiding this comment.
What exactly do you mean by that?
| - Permissions on spaces are currently not tracked in the share | ||
| manager, the are purely managed via grants. So currently the share | ||
| manager service currently does not know anything about (invited) | ||
| users being assigned to spaces |
There was a problem hiding this comment.
Why does the share manager need to know about invited or even accepted guest users? Is't that just a second call to the invitation manager to get that info where needed?
There was a problem hiding this comment.
Is't that just a second call to the invitation manager to get that info where needed?
Could you please elaborate on that?
docs/adr/0003-guest-users.md
Outdated
| invite. And could skip the step of creating a "pending" Share with an | ||
| invitation assigned. As we have an ID already we could just create a | ||
| "normal" share an even populated the grants on the filesystem for that | ||
| share (or space) |
There was a problem hiding this comment.
| invite. And could skip the step of creating a "pending" Share with an | |
| invitation assigned. As we have an ID already we could just create a | |
| "normal" share an even populated the grants on the filesystem for that | |
| share (or space) | |
| invite. That would allow to skip the step of creating a "pending" Share with an | |
| invitation assigned. As we have an ID already, we could just create a | |
| "normal" share and even populate the grants on the filesystem for that | |
| share (or space) |
| ## Questions still to be answered | ||
|
|
||
| - what's the life cycle of a guest user? | ||
| - Who's responsible for deprovisioning? |
|
|
||
| - what's the life cycle of a guest user? | ||
| - Who's responsible for deprovisioning? | ||
| - Do guest users expire after a certain time? |
There was a problem hiding this comment.
default: guest user accounts expire after 120 days of inactivity (=no login), can be configured. the invitation expires after 30 days per default. can be configured.
There was a problem hiding this comment.
default: guest user accounts expire after 120 days of inactivity (=no login), can be configured
This is where the whole thing gets murky again. I don't think we can reliably provide such a feature and keep the promise of working with all kinds external IDPs. Locking inactive user accounts is usually a feature of the IDP, we're not an IDP.
the invitation expires after 30 days per default. can be configured.
| - what's the life cycle of a guest user? | ||
| - Who's responsible for deprovisioning? | ||
| - Do guest users expire after a certain time? | ||
| - Do we need to keep track of who invited whom and when? (not just in |
There was a problem hiding this comment.
yes. there needs to be a lowlevel option to manage guest users eg. via cmd.
Guest user management must also be possible via a dashboard which is by default an external system with these options in the ui (same options should be availbale via cmd):
list all email adresses:
- email adress (=guest user)
- status (invitation accepted / pending)
- invited by
- invitation date
- if accepted: invitation accepted date
- last login
- days left until expiration + absolute date (updates after every login)
actions:
- export list as CSV
- deactivate/activate login (triggers infomail to guestuser)
- delete invite/user (triggers infomail to guestuser)
There was a problem hiding this comment.
deactivate/activate login (triggers infomail to guestuser)
delete invite/user (triggers infomail to guestuser)
See my other comment above. In a "normal" setup with an external IDP the OpenCloud admin is not able to delete users. As "guest" users are supposed to come from the same IDP, we will also not be able to delete those.
Somehow I think we need to get a common understand of the whole "lifecycle of an OpenCloud user". I have the feeling everybody has a different understanding of what OpenCloud really should provide in that area.
docs/adr/0003-guest-users.md
Outdated
| - who can see the list of guest users? | ||
| - once a guest user is created, is everyone in the organization able to | ||
| share with that guest user? | ||
| - what are guest user allowed to do? (are they able to share, lookup |
There was a problem hiding this comment.
- guestusers can not share or invite other users to a space or create public links. (primary focus of the feature is to provide a simple way to grant external, authorized access. anything else like resharing would undermine regular user accounts).
the default should be, that guestusers can not see who else has access.postponed for now- guestusers can use the desktop and mobile client to access their shares or spaces
guest users can not get the role "can manage" spacespostponed for now
There was a problem hiding this comment.
there must be an option on the keycloak selfregistration form to accept the "terms of service"
acceptance date per user must be logged
There was a problem hiding this comment.
guestusers can not share or invite other users to a space or create public links. (primary focus of the feature is to provide a simple way to grant external, authorized access. anything else like resharing would undermine regular user accounts).
the default should be, that guestusers can not see who else has access.postponed for nowguestusers can use the desktop and mobile client to access their shares or spaces
guest users can not get the role "can manage" spacespostponed for now
I've added those. What about looking up or search for other users? Currently we don't have any restriction on the respective graph API endpoints regarding that.
|
5 participants
The approach to take has not been decided yet. This just reflects the current research/concept work.