The Single Sign On work is coming nearer, so it seems 
Big on our roadmap. So maybe we take some time to discuss our perspectives. Let’s take the user or product perspective first and then drill down to the technical implementation?
Four high level objectives occur to me for implementing SSO in the context of meet.coop
-
First of all there is the most evident part: one account to login onto different systems. As we grow, this is an increasing need for both users and tech.circle. For users, as they can login with one account. For tech.circle, as that’s less work when deploying new servers, migrating them etc. Systems to think about:
a) first of all the Greenlight instances at de.meet.coop and ca.meet.coop which allow our members to run the meeting rooms. Add the demo and development server(s) for testing new versions before taking into production (see recent discussion)
b) Discourse forum: login with the one account; we’d want to know the user’s membership type, like ops member, inactive ops member, active user member, inactive user member, community member. Depending on the membership type, users can get to vote in certain Discourse categories (so Discourse should check the latest update on this identifier in the Id Mgt server).
c) our NextCloud server, though (now) only authenticated to by ops members. Less urgent, but still an improvement in the management of accounts when we can authenticate here with SSO. It would also allow us to imagine scenarios for other groups of users getting access to our NextCloud, like active user members, without too much admin work
d) Kimai time registration server like c)
e) Other specific services for members, like the event service including live streaming should be accessible by granting specific user accounts access to these services.
f) Other systems in the future -
Owning and automating our onboarding process for new users. Right now we have various loose user registration steps: user members start creating an account at OpenCollective, pay there and then we get an email notification and our contact support desk jumps in to find out the personś email, adds manually to spreadsheet and registers an account at the appropriate Greenlight instance. Terrible for all involved. Apart from users registering their account themselves at Discourse, and for the Demo server.
More than a year ago we already discussed how we then thought a future onboarding process should look like (check thread). In a nutshell: A new process could start off from a registration form at OUR website, providing automatic access to forum and demo and offer payment options which are processed by OpenCollective. Our system should keep track of the payment status to provide automatic access to the production Greenlight servers and disable that when members stop contributing. The (old) document describing the process is here. Thoughts on this? We’d update this document with your inputs.
-
Organisations and individual accounts. Individual accounts should be able to self service their account details (including profile?). Organisations need something more. They’d want to have the ability to manage their user accounts. Right now we’re deploying dedicated Greenlight instances for multi-user accounts. From a product PoV this isn’t ideal; Level 2, Level 3 org accounts have just one host account while multi-user can have infinite hosts at their GL instance. If we didn’t have to deploy GL instances, we could create more interesting products, anything in between those extremes, like Level 3 with a handful of host accounts for example. See threads: review multi-user accounts, product definition & multiple users per account.
This would require then to provide organisational members with a user management interface allowing them to add host accounts “underneath” their org account. I recall that Tim from Indiehosters told us (> 1 year ago) that keycloak’s interface for that does exist but was at the time not all too userfriendly. To be explored in detail when we get there? -
At some point in the future: possibility to federate authentication. We could make arrangements with other collectives to either have them authenticate at our servers against their Identity server and viceversa. We have learnt from Indiehosters that keycloak allows that, and they have that implemented on some services. That’s a strategic capacity that holds promises for our membership and scaling towards sustainability. Not anything urgent on the short term though
