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:
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:
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.
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.
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!
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.
thanks @decentral1se for bringing this up. We havenāt really made progress on the SSO ambition yet. Still keycloak seems like a powerful solution, but with various UX challenges, as you (also) seem to point out.
In your keycloak-collective-portal extension code, I read that all new signups have the same global permission level. But I imagine that some users may have an admin role or other to allow them to perform certain administrative tasks. Thatās distinguished, right?
I imagine it useful that a collective when joining, would have the possibility to administer members inside their collective. Imagine Collective X signs up for a multi-user service, they could then have their member accounts access a specific service (say greenlight-for-collectiveX.meet.coop like we have now for a series of members). Some of the accounts can be part of more than 1 collective.
In this prototype, anyone who has an account with the Keycloak, can do any administrative action because I use a client generated on the Keycloak side that has full adminstrative powers. But I could generate a less powerful client and use that for making access. Right now, either way, only invites are supported in the web interface UI.
I imagine it useful that a collective when joining, would have the possibility to administer members inside their collective. Imagine Collective X signs up for a multi-user service, they could then have their member accounts access a specific service (say greenlight-for-collectiveX.meet.coop like we have now for a series of members). Some of the accounts can be part of more than 1 collective.
I think accounts are tied to a āRealmā in Keycloak unless you are the global administrator so unsure if cross-collective members could have access to different collectives without also have more administration powers than desired. This could be worked around though, I guess.
But otherwise, what you describe is totally possible. Each BBB instance can have a specific client which can be connected in the Keycloak and in the collective portal to match each collective.
This would require some planning and mapping things out but I am excited to be finally able to say that complex sign-up workflows look implementable now that BBB supports OpenID Connect and Iāve discovered that the Keycloak REST API is extensive and allows for administration from external sources (the portal).
I invite you to try to break some of what youāve described above into smaller pieces and open up the discussion on Issues Ā· Autonomic-Cooperative/keycloak-collective-portal Ā· GitHub. The smaller the piece the better. At least we can put pen to paper on what would be useful on the issue tracker. Funding that work is another thing but good to put in the theory work now.
Thank you @wouter, much appreciated! I will try to think through these ideas and propose how to tackle them soon when I get time. I think it would be really great to suppor these suggested modes of operating.
We approved SSO for the first Bounty! Yay.
And I took on a task to āspecā out what we want from a Product Circle perspective but, as @benhylau pointed out:
The āaskā can be high level. There is no need to drill into specific implementations. Thatās the job of the tech circle.
So hereās the āAskā:
Essential:
Automated sign up process so that:
New customers can sign up online (via Open Collective / Stripe / other)
Their User accounts on .ca and .de are created automatically
They are emailed Welcome and Login details automatically
Password reset which effects all accounts
Access to Account Management (to upgrade, downgrade or unsubscribe) using the same login
Nice to have / Phase 2
Forum linked with SSO - So new user accounts are automatically created for the Forum too - and details of this are included in the (auto generated) Welcome email
SSO (using the same details as above) for Ops Members in our Next Cloud
SSO (using the same details as above) for Ops Members in our Chat channel
I think thatās what we want, please do add any more thoughts / feedbackā¦
Over to Tech Circle to tell us if this is doable, how, and how much time it might take!?
@osb did you read the āFraming of SSOā¦ā a few days ago? It includes 4 high level product view objectives.
At this moment weāll only want to do part of that, but still there are a few relevant thoughts in there that I think we should reflect on.
Can we OWN the onboarding instead of OC owning it? This would make things much better for us, not the least for the 2nd comment just below.
Not everyone needing an account will need to pay: to start all people willing to join the forum, or demo or any other free service we could have. So I think weāll want to give people the ability to a) sign up and then b) subscribe to a membership & service level. All elements in your āaskā are relevant, but Iād hope we can make sure the onboarding takes these two elements in account.
My view is still as per the above Ask - but this is only my opinion - I think it is now up to Tech Circle to provide rough time / cost estimates for the work
Iād be interested to follow the progress and read the design documents. Is it possible for someone with no account on https://cloud.meet.coop/ to see the cards etc.?
