Workspace ONE Access has a URL that presents the public key in PEM format, and the UAG can dynamically fetch the public key for trust. The only thing you need to configure here is that and the Dynamic Public Key URL. Name the JWT source a friendly name, such as WS1 Access. Setting this up fairly simple! Head over to your UAG and underneath Advanced Settings, click the JWT Settings gear. This allows us to have the UAG be the gatekeeper and keep all of our Connection Servers set to Allowed for SAML, so no more separating out internal vs external Connection Servers! With JWT, we are taking an additional layer and wrapping that artifact with a signature from Workspace ONE, which is validated by the UAG, and then the normal SAML artifact is passed onto the Connection Server for validation.

When launching a Horizon resource from Workspace ONE Access, a SAML artifact is presented with the launch URI and is validated by the Connection Server. You may have noticed when configuring your Horizon launch URLs from Workspace ONE Access, you have a mysterious option for “Wrap artifact in JWT.” JWT stands for JSON Web Token and is an IETF standard for signing a payload. You could set them all the same (required), but if you have zero clients internally or workflows that require accessing the Horizon Client directly, this requires you to have two separate configurations and VIPs. While this is a great way to do this, you are separating your “internal” and “external” Connection Servers. When pointing the UAG to a Connection Server with this, it only accepts launches from Workspace ONE Access. When combined with UAG, a common scenario is to separate out Connection Servers and place them in Workspace ONE mode and setting SAML to required, like this:

If you’re leveraging Workspace ONE Access with Horizon and allowing external access, you are likely leveraging multifactor authentication for additional security from the outside.

Uag airwatch