search

go-gitea / gitea

Git with a cup of tea! Painless self-hosted all-in-one software development service, including Git hosting, code review, team collaboration, package registry and CI/CD
https://gitea.com
MIT License
45.09k stars 5.49k forks source link

Add support for federated OpenID-Connect logins #1299

Open strk opened 7 years ago

strk commented 7 years ago

OpenID-Connect is already supported via the OAuth2 LoginSource, this ticket is to add support for the federated features of the spec: http://openid.net/specs/openid-connect-federation-1_0.html

NOTE: federated OpenID-2.0 is already supported (#618) See #1010 for some previous discussion about OpenID-Connect and federation.

strk commented 7 years ago

Corresponding ticket in the library currently used for OIDC: https://github.com/markbates/goth/issues/148

colemickens commented 6 years ago

Goth supports OpenID Connect now.

strk commented 6 years ago

Since which version @colemickens ? What would it take to make use of it from Gitea ? Just update to current master of Goth ? Do you have an OpenID-Connect provider to test an eventual implementation against ?

colemickens commented 6 years ago

It looks like Goth supported it since before you opened this issue, actually, from what I can tell: https://github.com/markbates/goth/pull/127

Anyway, it also seems like Gitea already has OIDC login... https://github.com/go-gitea/gitea/issues/3644

Also, there's this issue, also from you, where you were using it? https://github.com/go-gitea/gitea/issues/2100

I would be testing against Dex. I haven't stood up Gitea yet, might be a while before I make it back around to.

meredrica commented 6 years ago

Any news on this? Gitea looks really nice but not having SSO is a deal breaker for me :(

coolaj86 commented 6 years ago

This is something that I am working on personally and I'm trying to work slowly and with distinct commits so that it can come into mainline.

Check out https://github.com/go-gitea/gitea/pull/5029 if you're interested (just ux and bug fixes around the existing implementation so far). I also have instructions (in the issue) for giving my branch a test try if you'd like.

cc/ @meredrica

stale[bot] commented 5 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

stale[bot] commented 5 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

deedubs commented 5 years ago

Let me know if you need any help! Even if just testing I have a keycloak OIDC setup I can use to verify it.

strk commented 5 years ago

For testing, see https://github.com/simpleid/simpleid/issues/30#issuecomment-496359846

colemickens commented 5 years ago

I don't understand. The Discovery protocol is provided by the server and consumed by the client. AFAICT that does not implement OpenID Connect (edit, it looks like it implements OIDC, but I don't really like OIDC without Discovery).

Alternatively, https://github.com/dexidp/dex is an OpenID Connect identity provider (broker) that is easy to self-host, and it allows self-registration of clients, supports Discovery, it also can trivial chain into other authentication providers that don't allow self-registration. It's commonly used in "cloud-native" deployments, in conjunction with Go services and often containerized solutions. It would very likely be a good fit to use with Gitea. (edit, and is itself written in Go).

strk commented 5 years ago

What is that you don't understand @colemickens ? The issue here is being able to allow people to just provide an arbitrary URI as an authentication mean... Have you tried doing that with #5029 ?

6543 commented 3 years ago

should be posible now

strk commented 3 years ago

Possible how ? Is there an example of such self-identity provision ? BTW, I see OpenID-2.0 login was disabled on https://try.gitea.io/user/login -- was that intentional ? At the moment I've no way to even try that

strk commented 3 years ago

For reference: https://gitea.com/user/login still has OpenID support active, which shows Gitea-1.15 still supports that (good!) I still don't see any online proof of "federated OpenID-Connect logins" (ie: I enter my own url, as a user, to prove my identity)

6543 commented 3 years ago

ok so the federated part is missing?

strk commented 3 years ago

Yes. The goal is to be able to log into a Gitea instance by passing an arbitrary URL (either accepted or not based on some whitelist/blacklist eventually). Gitea would then delegate authenticating the user to a service discovered from the given URL.