Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature] Add support for OIDC/SAML/LDAP #171

Open
craftbyte opened this issue Jul 15, 2022 · 3 comments
Open

[Feature] Add support for OIDC/SAML/LDAP #171

craftbyte opened this issue Jul 15, 2022 · 3 comments
Labels
enhancement New feature or request

Comments

@craftbyte
Copy link

It would be nice to see support for an identity federation protocol, as a lot of bigger CTF teams have Keycloak/Authentik instances for their members. Another nice integration is GitHub OAuth with org membership checking.

@XeR
Copy link
Contributor

XeR commented Jul 21, 2022

Hey, thanks for the suggestion.

This is somewhat related to #32. All the protocols you mentioned are also supported by Hedgedoc.
I'm not familiar with federation protocols. How does this usually work in practice ? Applications create local user accounts on-the-fly ?
@B-i-t-K maybe you've already implemented something similar before ?

Another nice integration is GitHub OAuth with org membership checking.

I'm not a big fan of implementing features that rely on third party accounts. (Especially Microsoft !)
Isn't OAuth supposed to be standard ? Specify the URL, client ID, client secret and the magic happens.
What needs to be done for GitHub specifically ? Checking whether a user belongs to a group ?

People from other teams: if your team uses federation for other services, what protocol would you like to see implemented ?

@XeR XeR added the enhancement New feature or request label Jul 21, 2022
@lkempf
Copy link
Contributor

lkempf commented Oct 13, 2022

My team uses a custom gitlab-like oauth server and we have decided that we should probably port #20 (and our custom patch on top of that) to the current version of CTFNote and try to get this merged.

The provider specific implementation in our case is needed to fetch profile information so that a proper username is assigned when registering via oauth. As far as I know using plain oauth only returns a client_id and this id might not be suited as a human readable username. However, using a different oauth-provider requires only a few changes to the code and it shouldn't be a problem to maintain a custom fork for this and only support plain oauth officially.

I don't think it matters which protocols hedgehog supports since I don't think hedgehog supports being an oauth provider and adding additional protocols would mean modifying hedgehog instead of just modifying CTFNote.

@JJ-8
Copy link
Collaborator

JJ-8 commented Oct 14, 2022

@lkempf, I think it is better to start with the latest version of CTFNote and try to put the changes of #20 on top of that (so the other way around).

Moreover, you are probably talking about OAuth in CTFNote itself. XeR is talking about OAuth in Hedgedoc itself (since Hedgedoc has a separate account system, but CTFNote uses it as anonymous users). This is something completely different, but it would be nice if you can also attach Hedgedoc to the OAuth if you have OAuth configured for CTFNote.

If you want to submit a PR for the feature you are building, feel free to do so! I would happily review your changes :)

@XeR XeR mentioned this issue Sep 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants