OAuth provider: Auth0

[qrkourier]

Currently supported OIDC providers are Google, GitHub

Enabling Auth0 would allow a single OAuth provider configuration to support all the providers supported by Auth0 transitively

Personally, I'd prefer to have Auth0 before Okta because Auth0 allows the use of their own third-party client id/client secret, e.g. Google OAuth account, which is convenient for development and tiny scale testing.

With Okta, it's necessary to set up my own Google client id/secret, which is limited to allowed email addresses, so it's considerably more work for the dev to get things running.

[lukasmrtvy]

I would suggest https://github.com/dexidp/dex

[qrkourier]

@lukasmrtvy Correct me if this saved-you-a-click summary is inaccurate.

It looks like Dex could accelerate zrok compatibility with many OIDC providers, which is in the same spirit as the idea of adding an Auth0 implementation.

Supporting Dex would mean deploying zrok and Dex in tandem, Dex would replace the zrok frontend's OAuth endpoint that currently listens on a discrete port and is typically reached through a separate domain name like oauth.{{zrok_zone}}.

Instead of an OIDC implementation for each provider (google.go, github.go), zrok would have a single implementation for Dex (dex.go), and Dex would hold all OIDC client id/secret creds for providers (Auth0 [an example of a transitive provider], Google, Github, etc.).

[lukasmrtvy]

oidc.go ( https://github.com/coreos/go-oidc ) generic OIDC provider has to be introduced, with dexidp in tandem one would have the option to "plug-in" other providers

[maltegrosse]

would be great to see go-oidc used here (similar headscale is doing it) - so I could add my keycloak oidc....

[icsy7867]

Adding here as well, would also love to see a generic OIDC provider, so that I can use my organizations SSO capabilities.

[icsy7867]

I think I found a work around for anyone who is interested. We are using ADFS in my corporation, which supports oauth/oidc. I have this working for zrok links!

I did have to make a small modification, and build the zrok binary manually. But I added caddy-security as a module in endpoints/caddyListener.go, endpoints/proxy/caddyRequestsMiddleware.go endpoints/proxy/caddyWebBackend.go. I added:
_ "github.com/greenpau/caddy-security"

And then followed the build instructions, which worked fine.

I then used the caddy backend:

{
	order authenticate before respond
	# order authorize before reverse_proxy
	security {
		oauth identity provider generic {
			realm generic
			driver generic
			client_id oidc-client-ID-here
			client_secret my-client-secret-here
			scopes openid email profile
			base_auth_url https://my.company.com/adfs
			metadata_url https://my.company.com/adfs/.well-known/openid-configuration
		}

		authentication portal myportal {
			crypto default token lifetime 3600
			enable identity provider generic
			cookie domain zrok.fqdn.com
			ui {
				links {
					"My Identity" "/whoami" icon "las la-user"
					"app" "/app/" icon "las la-user"
				}
			}
			transform user {
				match realm generic
				action add role authp/user
			}
		}

		authorization policy mypolicy {
			set auth url /auth
			inject headers with claims
			allow roles authp/admin authp/user
		}

	}
}
http:// {
    # Bind to the zrok share
    bind {{ .ZrokBindAddress }}
    route /auth* {
	authenticate with myportal
    }
    authenticate with myportal

    # All other traffic goes to localhost:3000
    # authorize with mypolicy
    route /* {
        authorize with mypolicy
        uri strip_prefix /app
        reverse_proxy localhost:8080 {
            header_up Host localhost:8080
	    header_up X-Real-IP {http.request.header.x-forwarded-for}
        }
    }
}

[michaelquigley]

Very nice! That's for sure a change we can make for the next zrok release.

Any chance you'd want to do a write-up on it? Would love to put something in the docs for it.

[icsy7867]

Would love to! But it might not be until next week until I can write something up. Though it's really not that bad, just adding in the caddy module to the backend, and then writing a caddyfile to do what you want.

Also I am not sure if the module needs to be added to all of these:
endpoints/caddyListener.go, endpoints/proxy/caddyRequestsMiddleware.go endpoints/proxy/caddyWebBackend.go.
But i did anyways as a catch all. I can see if I can narrow that down.

[michaelquigley]

No rush! I don't think it particularly matters where the import is placed, as long as it's imported with _, it'll make sure that code is linked so you can write Caddyfiles using caddy-security.

I'll go ahead and get this integrated for v0.4.35, which probably won't come out until next week sometime anyway.

But if you do get a minute to write this up, especially as a page for the docs, that would be amazing. Thank you for sharing it at all. Cool stuff.

[michaelquigley]

There was an issue open to explore this concept, but we haven't gotten around to it yet...

See: #402

We can get the import merged for the next release, write something up for this, and basically close that feature issue.

[michaelquigley]

I did have to make a small modification, and build the zrok binary manually. But I added caddy-security as a module in endpoints/caddyListener.go, endpoints/proxy/caddyRequestsMiddleware.go endpoints/proxy/caddyWebBackend.go. I added:
_ "github.com/greenpau/caddy-security"

I would expect that this should work just fine with the import only in caddyWebBackend.go, rather than in all 3 places. Any chance you could verify that for me?

[michaelquigley]

I went ahead and confirmed the Caddyfile above did not work with zrok v0.4.34, and then added the import for github.com/greenpau/caddy-security, and then it did successfully load. The example errors out for obvious reasons.

v0.4.35 will be coming out today, most likely. @icsy7867 could you test your Caddyfile with it once it comes out?

[icsy7867]

Yep! I will definitely give it a whirl.

Also, I have a new implementation. The above works well for one offs, or if you have a reserved zrok name. Since OIDC needs to be pointed to a specific endpoint, but it can accept wildcards as well. So for a single use case this works really well!

However, for an enterprise environment, you dont want to give out a single OIDC/OAUTH ID and secret to everyone. So I reworked things. I know have a caddy-security proxy container in front of my ZROK frontend.

I used some caddy proxy magic to listen on two domains:
https://.zrok.company.com
and
https://.sso.zrok.company.com
(Similar idea to the above, but this is handled sever side.)

And then on the client, I check for an auth header, if it doesnt exist, I can force someone through the *.sso.zrok.company.com side, enforcing SSO. I will try to post this later as well :D

[michaelquigley]

Nice! It would be awesome to write some of this stuff up as a guide in the docs. Appreciate you working on this stuff!

[michaelquigley]

Just dropped v0.4.35.

https://github.com/openziti/zrok/releases/tag/v0.4.35

[icsy7867]

Yeah, I am going through my SSO when using this.

However I am getting a bunch of redirects, and eventually a load error, but I believe ZROK is working fine and as intended. I think this is due to my new global SSO change. So I believe your zrok build is working as intended!

[michaelquigley]

Ok! Thank you for checking... this means the caddy-security module should be generally available as part of zrok now. 👍