Support other OIDC providers

[etiennej70]

Support other OIDC providers

Summary

URL check performed for discovery URL is too restrictive and can only be compatible with keycloack products. It should be possible to configure other OIDC providers.

Why?

Not using keycloack provider.

How

Modify check on discovery-url in pkg/config/config.go

Currently it is :

func (r *Config) extractDiscoveryURIComponents() error {
	reg := regexp.MustCompile(
		`(?P<legacy>(/auth){0,1})/realms/(?P<realm>[^/]+)(/{0,1}).*`,
	)

	matches := reg.FindStringSubmatch(r.DiscoveryURI.Path)

	if len(matches) == 0 {
		return apperrors.ErrBadDiscoveryURIFormat
	}

	legacyIndex := reg.SubexpIndex("legacy")
	realmIndex := reg.SubexpIndex("realm")

	if matches[legacyIndex] != "" {
		r.IsDiscoverURILegacy = true
	}

	r.Realm = matches[realmIndex]
	return nil
}

Can be modify by inserting directly the /.well-known/openid-configuration in the discovery-url parameter

Acceptance criteria

Be able to use another OIDC provider (google, ping federate, 0Auth, ...)

Additional Information

N/A

[p53]

hi, we already has this request here several times, if we would like to support also other IDP providers it is not just about changing this url, we would need to restrict/remove also other features/refactor/test code to be able to fit also for other providers, so it is not just about changing this one thing it is whole more complex thing. I already tried it with google, that maybe seems good candidate for next provider and i have idea maybe how to do it in a way that would scale but in short term i don't think more providers will be supported (depends on how much time i will have)

[mcassaniti]

Is there a recommended package to use instead if the work required to operate with other OIDC IdPs is too complex? I'm looking to use OIDC with NextCloud (see here).

[Mathieu-Lichtsteiner]

Hello
I also would love to see the possibility to configure more (generic) OIDC providers. Could we maybe define the needed steps for adding a new provider? I could imagine, that a clear outline / roadmap could help to implement such a feature. I am not an experience Go developer myself, but I would definetly try to support or even collaboratively implement a solution. The USP in my eyes is the simplicity to configure access token validation, but also extensive configurability of gatekeeper compared to alternative solutions like oathkeeper or oauth2-proxy

[p53]

Hi,

i already refactored gatekeeper to separate general purpose functionality from provider specific and i have to say that differences between providers are quite big so supporting another provider would be quite a challenge and probably they would differ quite a lot in possible functionality thus starting even one new provider would be quite a challenge to not make not just in terms of writing user facing code but also setting up infrastructure and tests for them, probably best would be to separate some common parts to library and have separate github repo per provider, but as i already mentioned i would not have time to maintain another project

[Mathieu-Lichtsteiner]

Hi @p53

Thanks for your quick awnser. I appreciate your effort building the basis to open this project. I think the approach of splitting into multiple repositories could be a great solution to manage the responsibilities.
Do you already have some kind of plan in mind how a transition / roadmap to a poly-repo solution could look like? I would offer my help, if I can implement specific features / tests and or infrastructure, but I want to respect your code ownership.

Thanks and best regards
Mathieu

[p53]

Hi, maybe it would be good to discuss it e.g. on gatekeeper discord chat, because it is on a little bit bigger discussion, maybe propose some dates/times, for me best time is in the evenings...