Redesign UX flows, onboarding, SSO

[wouter]

This is in fact a multi-circle topic: the redesign of the user/member onboarding flow. In the document I have described the current pain points and some suggestions for redesigning the process in the new website. It should help us discuss the need for a user account / identity management server. We have the offer from IndieHosters to learn from their experience with keycloak. This document is a non-technical approach to explore what we could need short and mid-term.
It also provides ideas for making the meet.coop website the central place for users to deal with and get access to everything meet.coop.

Please have a look in the document, add comments, improvements and corrections as you see fit and feel free to comment here
BTW I have taken the flow diagrams that we initiated on Eileen’s miro board and described the key issues, usecases and possible plans for the future into this document:

[3wc]

I was halfway through making a new post about this when I realised I was basically duplicating your work @wouter. Thank you for starting this! I wonder if it’s worth adding “SSO” to the title to make clear that this is the place to discuss it.

One thing I wanted to add to the “pain points” is that operational members need at least 4 sets of credentials per person: Discourse, Nextcloud, Greenlight (possibly ×2), and Kimai.

And, on the technical platform, I thought it would be helpful to drop in the earlier thoughts from the tech circle:

@decentral1se

I guess we’re leading towards a central LDAP server auth which Greenlight supports. Another option is that I see there is also functional but WIP () work for Greenlight supporting OpenID Connect. This could allow for something like a central Keycloak SSO which can be themed out of the box and administered through a web interface. I’ve also seen that Keycloak can plug-in existing LDAP providers for user federation.

EDIT: there was also talk of https://gitlab.com/commonscloud/onboarding

@unteem

Yep SSO is a game changer . This was actually one of the coming questions from our part, we wondered if you experimented with SSO and bbb. I want to try out this PR for instance https://github.com/bigbluebutton/greenlight/pull/1194 (btw this is something that I like and dislike with bbb, they are quite conservative with PRs or some would say keep their software stable)

We have been using Keycloak for more than 2 year now. It works well. Its a big java software with an old school UI but it does everything and you can configure everything . I probably know only a tiny bit of all its potential.

We use it in a multi-tenant way, each organization/collective has its own realm that they can manage.

I do think that the UI is not really good though. If you want to enable a user to manage its own realm for instance its a bit hard at first for them. You will need to do some training to show them how do it.

One app that I would like to implement at one point is hydra. Tiny go microservices perfectly designed for our kubernetes setup :).

We are sticking to Keycloak for now, because obviously it works well but also because Nextcloud had so far only an integration with SAML (or LDAP) for SSO (now there is a new app for OIDC that is being developed as a core app) and hydra does not provide SAML.

Whats also nice with keycloak is that you can plug it with an ldap directory as a backend (you can have a mix of ldap and postgres for instance). You can also federate ID providers, like we did on https://lab.libreho.st.

A few years back before moving to keycloak we thought about going your way with an ldap directory but most webapps were pretty outdated and we are pretty bad developers so… We also think that even if ldap is pretty solid and well supported, it is also bit old school, not so much web friendly and as we already host postgresql databases in HA, why not having our user based there too

As a post-script, Autonomic uses Keycloak and it’s OK but I share @unteem’s concerns with the UI.

Nextcloud also now does support OIDC so maybe hyda is a better solution, although it doesn’t sound like any of us has personal experience with it.

Last I checked a couple of months ago, Kimai doesn’t support any SSO protocols (LDAP, SAML, or OIDC) and the only option for login integration is LDAP – but I don’t think that should hold us up.

Autonomic could potentially help with implementation, especially if any budget can be allocated to this work.

[wouter]

thanks @3wc for recompiling these posts and the offer to help out with this. As we discussed last week, we look forward to first have an exploratory meeting to study 1) our needs and 2) the possible solution with keycloak. Our needs are somewhat drafty documented and I feel this is a moving target: the more the solution can provide us, the more interesting our needs

We look to plan a dedicated session in the first weeks of January where we get together with @unteem, hopefully @decentral1se and @3wc to get a better feel for keycloak as part of the solution and @georgiamoon, Eileen, @melissamcnab @osb @benhylau @Yurko to think of how we want to streamline our onboarding and user management with SSO. Also I’d like to invite @NickM from Resonate as they are struggling with similar challenges over there.

Here’s a few options

keycloak SSO user management session

• 12/01 10 GMT
• 13/01 10 GMT
• 14/01 10 GMT
• 15/01 10 GMT
• 12/01 14 GMT
• 13/01 14 GMT
• 15/01 14 GMT
• it’s not problematic if I cannot make it

hopefully one of those dates fits most or all!

[wouter]

great, thanks for your votes! 12th and 13th fit all, let’s see who helps to make the final choice
@decentral1se @dvdjaco @NickM ?

[wouter]

Good day, new year and new decade to you all
based on your preferences I conclude that we meet next Wednesday 13th at 14h GMT, see here the event. See you then!

[wouter]

thanks to all for the great session, I learnt a lot and was happy to validate several doubts! Thanks to @unteem in particular. And to @georgiamoon for keeping notes - I have added to them after the meet, and included the links to the recordings of the session. See here the notes.