You’ve likely heard of integrating Horizon UAG with OPSWAT, which is an excellent way to ensure endpoints meet compliance requirements without having a full MDM solution on the device. This is especially important when it comes to third-party partners that may already manage your partner company’s devices with their own MDM.
Well, did you know that you can put OPSWAT in the middle of a third-party IdP and Workspace ONE Access? OPSWAT MetaDefender IT-OT Access allows for this! The solution looks like below, which was taken from OPSWAT’s docs, but I threw Access and Entra in here to give a better idea on how it looks:
The tricky part with this setup is that OPSWAT acts as a man-in-the-middle between the SP (Access) and the IdP (Entra). OPSWAT will actually re-sign the SAML assertion before passing it back to Access, since it has to be the one determining whether or not the authentication succeeds (eg., if the device is compliant). This takes some modifications of the IdP metadata you give to Access from Azure AD. Not only does it need to trust the certificate from the metadata that gets signed, but it also needs to know where to send users for auth in the case of a SP-initiated auth, which is pretty much always the workflow when it comes to Workspace ONE Access.
This assumes you already have Azure AD setup with Access. The nice thing about this is that you can setup a completely separate IdP in Access and test at your lesiure in a separate policy, while just adding the Reply/ACS URL from OPSWAT.
1) First thing, head over to your OPSWAT MetaDefender IT-OT Access console after you get your account provisioned. Go to Secure Access > Protected Apps and enable Secure Access.
2) Then, go to Secure Access > Access Methods. Under Identity Providers, create a new one. Grab the certificate from the WS1 app in the Entra/Identity/AAD Admin console in toe SSO section of your app. Go ahead and grab the Federation Metadata XML (aka the IdP metadata) and save it; you’ll need that in a bit.
Use the Base64 certificate you downloaded to upload to the IdP certificate for the IdP in OPSWAT. Click Save and head to Protected Apps.
3. Next, go to Add Protected Application for the IdP Method:
Choose your IdP you just created (I named mine Azure AD earlier for old habit’s sake). Click Continue.
4. Head back to the Entra Admin console. Under Section 4 of the SSO section, grab the Sign-On URL and paste it into IdP Login URL, App ACS URL, and Logout URL:
Click the bottom checkbox so you can record the username from the SAML attribute of who is trying to login. Click Continue.
5. Copy the URL into your clipboard and download the certificate.
6. Head back to the Entra. Under the SSO Section, edit Step 1 (Basic SAML Configuration) and add a new Reply URL. Paste the URL from the previous step and set it as default. Having both allows Entra accept logins from both Access directly, as it is today, as well as OPSWAT.
7. Edit the OPSWAT certificate you downloaded with Notepad. Copy all of the contents -between- BEGIN CERTIFICATE and END CERTIFICATE. Edit the Federation Metadata XML you downloaded from step 2. There are 3 places in the metadata you’ll need to replace the certificate contents with, since OPSWAT is re-signing the assertion. Each is the property for <X509Certificate>. Replace/paste the certificate contents in between these 3 locations that start with <X509Certificate> lotsofcharacters </X509Certificate>.
8. At the very end of the XML metadata, you’ll see two SingleSignOnService Bindings, one for HTTP-Redirect and one for HTTP-POST. Replace the login.microsoftonline.com URLs with the OPSWAT ACS URL copied from step 5.
(Before/After)
9. Finally, save the XML. Head into the WS1 Access Admin Console and create a new SAML Identity Provider. Paste the newly-edited XML contents into the IdP Metadata and click Process IdP Metadata. Set all of the same settings you had in your original Azure AD / Entra settings. Name the Authentication Method something unique, like AzureADwithOPSWAT
…
10. Edit your default Access Policy to a specific network range for testing, or even apply it to a custom policy for a specific app.
11. Now, try to authenticate without the OPSWAT agent running. If everything is setup correctly and OPSWAT is set to Enforce back in Step 4, you’ll get the following:
12. Back in the OPSWAT MetaDefender Console, Under Secure Access > Activities, you’ll see the attempt logged. Even though the agent is not installed, it will still record the username from the SAML attribute that OPSWAT grabs:
In conclusion, this is a great way to allow for Zero Trust Access and ensure compliance for BYOD scenarios, where full device management for compliance checking is not feasible (such as between Access/UEM).
I will also note that OPSWAT can supposedly act as a full IdP, which would be a thousand times cleaner, since you could just require both Azure AD/Entra + OPSWAT auth in your Access policy vs doing the man-in-the-middle approach. I just can’t seem to get it to accept Access’ SP metadata for some reason:
I have a ticket open with OPSWAT on this and will update this post if we find a solution. If anyone has any ideas, I would love to hear them! As always, feel free to shoot me an email if you have any questions.
UPDATE: A fix has been found for the IdP MFA solution above! See my Part TWO post for more details!