Why do we add this issue?
Since Akvo does not want to manage the hosting of a Keycloak server we're looking at other options.
Looking out in the future we are also planning to retire tenant user management.
The thought is that every user will have access to what Lumen provides but permissions will be applied based on the (probably) organization and permissions on data.
Other solutions would be openid connect alternatives.
Problem or idea
Today Lumen use Keycloak for Authentication and authorization. For the authorization part, we use the Keycloak "groups" & "roles" features to enforce who can access what tenant and if the user is a member or an admin. Lumen also includes a tenant member admin where admins can invite, and promote & promote members to admins.
Problems:
SSO for Lumen and Flow
What user is allowed into what instance/tenant
How to enforce Flow permissions in Lumen (efficient)
Where do instance/tenant admins manage their users? Today Lumen has an admin for managing the keycloak groups.
Be able to efficient list what instance/tenant each user has access to.
Requests for new instance/tenants need to be handled in some way. Today in Lumen we have scripts that create databases, Keycloak groups configure the openid connect client etc.
Solution or next step
Move the group handing from Keycloak to some other mean. This will probably be a temporary solution while the proper grouping things app is defined and built. But it will enable us to move from Keycloak to some other auth provider.
Possible alternatives:
Use new auth providers custom features (e.g. Auth0 groups)
This would be a port from Keycloak to Auth0 custom feature.
Handle users within each tenant db
Let each tenant store references to users and only require authentication from an external provider.
Have a separate service that handles the tenant membership as well as entity ownership. Porting from Keycloak would probably not be too difficult but unsure how easy populating a custom model from the unilog data is.
Context
Why do we add this issue? Since Akvo does not want to manage the hosting of a Keycloak server we're looking at other options. Looking out in the future we are also planning to retire tenant user management.
The thought is that every user will have access to what Lumen provides but permissions will be applied based on the (probably) organization and permissions on data.
Other solutions would be openid connect alternatives.
Problem or idea
Today Lumen use Keycloak for Authentication and authorization. For the authorization part, we use the Keycloak "groups" & "roles" features to enforce who can access what tenant and if the user is a member or an admin. Lumen also includes a tenant member admin where admins can invite, and promote & promote members to admins.
Problems:
Solution or next step
Move the group handing from Keycloak to some other mean. This will probably be a temporary solution while the proper grouping things app is defined and built. But it will enable us to move from Keycloak to some other auth provider.
Possible alternatives:
Use new auth providers custom features (e.g. Auth0 groups)
This would be a port from Keycloak to Auth0 custom feature.
Handle users within each tenant db
Let each tenant store references to users and only require authentication from an external provider.
Use Flow
Handle the Lumen permissions in Flow
Use Keycloak for authorization?
https://stackoverflow.com/questions/54997031/using-auth0-with-keycloak
Grouping things app
Have a separate service that handles the tenant membership as well as entity ownership. Porting from Keycloak would probably not be too difficult but unsure how easy populating a custom model from the unilog data is.