ZDEW and Google OIDC

Tunneler Apps Ziti Desktop Edge for Windows
1

Hello everyone,
I've installed controller and router 1.2.2 on a AWS EC2 instance and I've installed the ZDEW 2.5.2.6. I've configured Google Workspace as an external jwt signer. I followed the installation as presented by Clint in the latest Ziti TV about Windows + OIDC. Thanks for this video and the "Add Identity with URL" feature, it was the missing piece to be able to use OpenZiti in our team. I know that it's not an easy feat to get this working, as mentioned by Clint. I'm not an Idp expert, but it's not the first time that I've configured Google as an IdP and I've been able to get it working with other applications.

I have two errors with the ZDEW when I try to authenticate.

The first one is the callback URL sent from the ZDEW, http://localhost:20314/auth/callback, raises the redirect_uri_mismatch error. I'm not so sure that ZDEW should be sending this as callback and if it is, not sure that it is secured.

Ignoring my security concern, I added http://localhost:20314/auth/callback to the authorized
redirect uri's. This raises my second error: Some requested scopes were invalid {valid=[openid,...], invalid=[offline_access]}. I can't find a way to add offline_access in the scopes authorization request list. I've found that offline_access isn't a scope per se for Google authentication, it's an access type. Is there a way to allow this kind of access type? Something to do with refresh token? I wasn't able to find a refresh token scope, either. Do I need to enable an API in my Google project to allow this access or this scope?

Is there someone here that was able to get this working?

2

Hi @andre, welcome to the community and to OpenZiti (and zrok/BrowZer)!

Every idp is different. We have discovered more than one which doesn't allow requesting offline_access. A new release will be coming out in the coming days that removes the tunneler from requesting it. Until then, I don't think there will be a workaround.

I'm working on adding docs for the various idps because like I/you mention, each is different and each has different ways of doing the same thing... I also hit this issue myself when trying to use Google for external auth.

So, I think you'll probably have to just sit tight for another day or two. I'll follow up here after we make another release of the ZDEW and I've gotten Google to work with my own overlay...

1 Like
3

Hi @TheLumberjack,thanks for the swift response. I'm pleased to know that a solution is on the way, your commitment to growing and perfecting OpenZiti is very impressive. If there's anything I can do, I would be glad to help, I know it's not an easy task to build a product that has to interact with that kind of diversified ecosystem.

4

Thanks @andre! The things you can do to help the project is all about marketing. Tell people about OpenZiti and how great it is, write a blog about it and post it on reddit/ycombinator etc. Those sorts of things have a huge effect on bringing people to the project. Those sorts of things are very appreciated by us!

I'll let you know when it's ready... Should be pretty soon...

1 Like
5

Ziti Desktop Edge for Windows 2.5.2.7 was released. This release fixes the offline_access being requested by default and fixes the problem seen in the Ziti TV where the 'external auth url' endeing with a trailing slash caused a problem.

This release has been pushed to the beta stream. If you set your release stream to https://get.openziti.io/zdew/beta.json you'll be able to have it automatically update.

Cheers

1 Like
6

Thanks Clint, I will test this out.

7

Sure. I'm in the midst of testing it myself today and hit:

Audience is not a valid client ID.

If you are a developer of openziti, see [error details](https://accounts.google.com/).

Error 400: invalid_audience

If you are better able to configure google than myself currently, do post back your learnings here? :slight_smile:

Until then, I'll be work on it as well.

8

I Clint, I just tried the new version and it looks like the ZDEW is sending a request with audience=openziti rather than the one specified in the JWT Signer configuration.

9

Yes, that's "the problem" indeed. I'm working through this right now. Google also expects you to submit the client id as the audience. Some IdPs allow you to indicate what audience you want, some force you to use the one they expect... every IdP is different. There are buckets of functionality, but we need to fix this....

I'll post back after I confirm Google WORKS ... :confused:

10

Yep, they all have their quirks and it's not clear at first that Google expect you to use the client_id as audience.

11

This will require a new build of the OpenZiti controller, not just a build of the client. I believe the clients are now good to go as well. Version 2.5.2.8 of the ZDEW was just pushed out there. It adds one vital piece of logging that makes it possible to debug OIDC configurations by logging the payload of the jwt received from the idp. Not the whole token, just the payload, so that when setting up OIDC, you'll be able to see what was submitted to the controller for auth. This is a DEBUG level setting so the user will need to enable DEBUG in order to view the token payload.

I'll post back one last time after the ziti CLI/controller is released and after I verify google.

1 Like
12

Thanks for the update.

13

For clarity, when you say "Google as an IdP" do you mean:

  1. Google's public authentication system for public @gmail.com accounts
  2. Google Authentication in Google Cloud systems
  3. Google Workspace Authentication

While similarly implemented, there are differences.

14

We have Google Workspace for our team, using it as an IdP. I have different configurations for authentication depending on the app requirements. Some apps are configured as web apps with SAML Authentication and others, like Openziti, are configured as a Google cloud project with credentials configured for the app.

15

Thanks @andre, I think we are closing in on a solution that'll work out. It will require both an OpenZiti controller update and Ziti Desktop Edge for Windows update. Google is returning opaque access tokens, unusable by OpenZiti (I'll let @andrew.martinez provide any extra details as he sees fit).

We're looking at having a selectable field allowing you to choose to use the ID token, if the IdP doesn't provide a usable access token in JWT format (non-opaque).

I'm working through this all and have been for the last 'days' so - hopefully we'll have something soon.

16

Thanks, I was actually looking at the new 1.3.3 version, wondering if I was updating or not to it. I've seen some code about the OIDC authRequestID, suspecting it was the necessary update you were talking about.

17

I've upgraded my installation to 1.3.3 and configured a Keycloak server in the meantime. The authentication with our Google Workspace SSO is pretty much seamless with it as a Default Identity Provider in the Identity Provider Redirector config.

1 Like
18

Yeah. It's much, much easier to allow federation via Keycloak. The next controller release should have the required field that allows the operator (you) to configure the ext-jwt-signer to use an ID token for authentication as opposed to an access token.

It's still in the works, fwiw... :slight_smile:

1 Like
19

Cool, I'm following the development. The Keycloak option is interesting and it allows us to test a SSO deployment of OpenZiti.

1 Like