We’ve started integrating Azure AD SSO with some of the products we work with. Naturally, I’m very curious on how ZeroTier One could be integrated with Azure AD. Assuming the Azure AD account is MFA enforced, this may help ZeroTier One meet MFA remote access requirements being leveraged by insurance companies. I wanted to start a discussion on how this could be done, as the current SSO configuration guidance from ZeroTier is quite sparse (probably because it’s so new).
Idea #1: Integrate directly with Azure AD
ZeroTier One ← OIDC → Azure AD
ZeroTier One supports OIDC for SSO. Azure AD seems to work better with SAML, not OIDC. The Microsoft documentation on OIDC isn’t great. The preferred method is to add the pre-registered vendor app from the Azure AD Gallery. ZeroTier hasn’t registered a SSO app in the Gallery yet, and I wouldn’t hold my breath for this. The other option is to register the app yourself. This is probably the best way to go, but I’m not experienced enough with OIDC to understand what’s happening here.
This guide shows how to setup Azure AD as an OIDC identity provider on Keycloak. It seems you need to create a certificate in Azure AD (that expires after 1-3 yrs), and then load that cert into Keycloak. Because of the certificate, I’m not sure if these instructions can be adapted to the ZeroTier One client.
Idea #2: Use Keycloak as a middleman between ZeroTier One and Azure AD
ZeroTier One ← OIDC → Keycloak ← SAML → Azure AD
Using Azure AD as a SAML identity provider doesn’t require a certificate to be setup, as seen in this guide on how to setup Azure AD as a SAML identity provider on Keycloak. That’s great for sustainability, since we don’t have to worry about rotating/renewing the cert. Since ZeroTier One doesn’t support SAML, we would need to use an intermediary like Keycloak. The second half of this guide shows how to configure an OIDC compatible app (HCL Compass) to use Keycloak for SSO. I feel like this has a higher chance of success, than doing SSO to Azure AD directly. The downside is that you need to standup, host and maintain a high-availability Keycloak server.
#1 is probably the way to go where you register the app yourself, and set the callback URL to http://localhost:9993/sso. That’s to pass the code & token to ZeroTier itself so it can do its magic & auth you on the network. Also ensure that it supports PKCE.
From there, all you need to enter on the Central Account page is the Client ID & Issuer UR and you should be good to go.
Keycloak does work as a SAML middleman as well. We use that internally to connect our Google Workspace accounts (because Google Workspace’s SPA config doesn’t support PKCE yet )
Thanks for the feedback @zt-grant! We still need to get our billing updated to the new model, so I can’t test this out just yet. But looking forward to playing with this in the near future.
I went through the process registering an app myself, it will call through and sign in via microsoft but then the response in the client is Invalid Token Response. First call does seem to create a new Azure Enterprise App for zerotier.
I assume there is something not quite matching up here.
It’ll be a few weeks before I can really dig into this myself as I’m traveling until the 22nd.
First thing, make sure your clients are on 1.10.1. Beyond that, ensure the OIDC client you’ve set up in Azure is configured as a public client for an SPA.
If all that is set correctly and you’re still running into the same issue, then I’ll likely have to dig in deeper to find out what’s going on. In that case, any directions you can point me at for getting AzureAD up and running to the point where I can set up an OIDC client are much appreciated. I’m that well versed in the Microsoft ecosystem.
So, when joining this network now I get prompted for SSO, this correctly takes me to a Microsoft Sign in page which completes. The URL jumps to the return url of localhost 9993/sso with the Invalid token response message. A review of the Azure sign-in logs says that the sign-in was successful on that side.
Hope all that helps to get to where I am at, happy to work through it with you as needed. We are evaluating ZT at the moment for a corporate deploy but obviously we need to get this working to go further.
** sorry only allowed to post 2 links so abbreviated the localhost redirect uri
I’m back from vacation and got to dig into this a bit this morning.
Rather than selecting SPA, I set “Public client/native (Mobile & Desktop)” as the type for Application Registration, then set the redirect URI. After that it just worked. Screenshot of the config page below.
)