Do we need a Co-op Cloud single sign on solution? #669

New Issue

kawaiipunk · 2025-01-07T16:39:38Z

kawaiipunk commented

2025-01-07 16:39:38 +00:00

We currently have
https://git.coopcloud.tech
https://kimai.coopcloud.tech/

Perhaps we might want to think about oauth SSO if we do need any more platforms? Kimai may become necessary to track out time and manage budgets. We're thinking of moving to a GUI wiki e.g. Dokuwiki

Currently Autonomic, Local IT and Doop Coop all have their own SSO plugged into Gitea. Do we setup a new SSO server for those folks that don't have their own orga that has one?

What do folks think is the way forward?

We currently have https://git.coopcloud.tech https://kimai.coopcloud.tech/ Perhaps we might want to think about oauth SSO if we do need any more platforms? Kimai may become necessary to track out time and manage budgets. We're thinking of moving to a GUI wiki e.g. Dokuwiki Currently Autonomic, Local IT and Doop Coop all have their own SSO plugged into Gitea. Do we setup a new SSO server for those folks that don't have their own orga that has one? What do folks think is the way forward?

kawaiipunk added the

proposal

label 2025-01-07 16:39:38 +00:00

kawaiipunk added a new dependency 2025-01-07 16:42:00 +00:00

#665 A New Docs Platform?

decentral1se commented

2025-01-09 21:43:11 +00:00

Yeh, I would be up for centralising on a single SSO solution. Authentik seems to be the chosen weapon of choice lately and fedi members have experience with it. The existing provider integrations (Autonomic, Local-IT, etc.) could be migrated from the Gitea login to Authentik itself, so people could still retain their SSO setup. It might be a tricky migration but we could manage it.

3wordchant commented

2025-02-11 21:29:43 +00:00

The existing provider integrations (Autonomic, Local-IT, etc.) could be migrated from the Gitea login to Authentik itself, so people could still retain their SSO setup

Yeah, great suggestion.

> The existing provider integrations (Autonomic, Local-IT, etc.) could be migrated from the Gitea login to Authentik itself, so people could still retain their SSO setup Yeah, great suggestion.

decentral1se commented

2025-04-20 06:02:15 +00:00

Current plan:

Use https://github.com/sebadob/rauthy as SSO
@p4u1 is asking if K&M can provide hosting (otherwise, we re-use swarm0 i assume @kawaiipunk)
Wire it up and @sef has offered to help wire up clients / click the buttons

Current plan: * Use https://github.com/sebadob/rauthy as SSO * @p4u1 is asking if K&M can provide hosting (otherwise, we re-use swarm0 i assume @kawaiipunk) * Wire it up and @sef has offered to help wire up clients / click the buttons

decentral1se added this to the Federation project 2025-04-20 06:03:06 +00:00

decentral1se moved this to To Do in Federation on 2025-04-20 06:04:56 +00:00

decentral1se moved this to In Progress in Federation on 2025-04-20 06:09:53 +00:00

decentral1se commented

2025-04-27 15:14:49 +00:00

Holy cow, look at this cursed solution for Kimai x OIDC:

https://github.com/kimai/kimai/discussions/3122#discussioncomment-2708156

rauthy supports AUTH_HEADERS_ENABLE=true:

https://sebadob.github.io/rauthy/config/config.html#reference-config

This means an admin would have to log in and create the matching username/email before you could login from the SSO side of things 😂 I'm not sure I would recommend this but I'd be up for trying to hack it together one of the days if someone else is keen.

Holy cow, look at this cursed solution for Kimai x OIDC: > https://github.com/kimai/kimai/discussions/3122#discussioncomment-2708156 `rauthy` supports `AUTH_HEADERS_ENABLE=true`: > https://sebadob.github.io/rauthy/config/config.html#reference-config This means an admin would have to log in and create the matching username/email before you could login from the SSO side of things 😂 I'm not sure I would recommend this but I'd be up for trying to hack it together one of the days if someone else is keen.

😕 1

3wordchant commented

2025-05-03 21:36:29 +00:00

This means an admin would have to log in and create the matching username/email before you could login from the SSO side of things 😂 I'm not sure I would recommend this but I'd be up for trying to hack it together one of the days if someone else is keen.

I mean I'm not totally against it, I don't expect a million people needing to use Kimai – and maybe the "radical administrator" could help make sure this work doesn't fall through the cracks. Fine with either this or Authentik.

> This means an admin would have to log in and create the matching username/email before you could login from the SSO side of things 😂 I'm not sure I would recommend this but I'd be up for trying to hack it together one of the days if someone else is keen. I mean I'm not totally against it, I don't expect a million people needing to use Kimai – and maybe the "radical administrator" could help make sure this work doesn't fall through the cracks. Fine with either this or Authentik.

decentral1se moved this to To Do in Federation on 2025-06-04 16:21:41 +00:00

kawaiipunk commented

2025-06-05 15:01:23 +00:00

Maybe we could just use something that supports oauth.

3wordchant commented

2025-06-06 19:23:06 +00:00

Maybe we could just use something that supports oauth.

Open to it. Focustime doesn't seem to support SSO at all, and I'm not aware of other Kimai alternatives.

> Maybe we could just use something that supports oauth. Open to it. Focustime doesn't seem to support SSO at all, and I'm not aware of other Kimai alternatives.

Sign in to join this conversation.

3 Participants

Notifications

Due Date

No due date set.

Blocks

#665 A New Docs Platform?

toolshed/organising

Reference: toolshed/organising#669