Thoughts on Business SSO integration with Azure AD

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 Like

#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 :man_facepalming: )

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.

Has anyone had any success here with AzureAD.

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.

Hey @MikeW

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.

-grant

Hi,

Thanks for the response. I’ve just set up a small test network with it and the client is 1.10.1. I did check that public flow is enabled.

I setup using the following:

Azure Active Directory → App Registration → Register new application

→ Setup screen setttings

  • Accounts in this organizational directory only (single tenant)

  • Redirect URI to the localhost 9993 from the docs

From there have set the following on the app registration that was created.

→ Authentication

  • Platform is SPA with redirect uri of http://localhost:9993/sso

  • Enabled Implicit grants of “Access Tokens” and “ID Tokens”

  • Supported accounts - this organization only

  • Advanced settings, Allow public client flows.

→ Token Configuration

  • Added email to the optional claims, not sure if this was needed but tried to to ensure we meet the claims requested. I believe Azure meets those.

In ZeroTier the Issuer is https://login.microsoftonline.com/{Tenant GUID}/v2.0
Client ID is the application ID of the app registration

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

Hey @MikeW,

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.

This “Just Worked” after setting the OIDC endpoint & client ID in Central

Thank you!

I have just configured as described and yes it works as expected. I guess I should have thought to try the mobile/desktop flow.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.