The Deep Security team released support today for identity provider integration using SAML 2.0. When you integrate Deep Security with your identity provider, you no longer need to manage users, passwords, and MFA tokens in Deep Security. By offloading user management to your identity provider, you can also use features like password strength / change enforcement, one-time password (OTP), and two-factor / multi-factor authentication (2FA/MFA) with your existing policies. We have tested Deep Security SAML integration with Microsoft Windows Active Directory Federation Services (ADFS), Okta, PingOne, and Shibboleth.

This article will help you integrate your ADFS server with Deep Security. I’ve tested the instructions with ADFS 4.0 (Windows Server 2016), but you can set up the same configuration with older versions of ADFS back to ADFS 2.0.

You can follow the instructions in this article today if you have an account on Deep Security as a Service, Trend Micro’s hosted Deep Security solution. SAML support is coming soon to the AWS Marketplace, Azure Marketplace, and software releases starting with Deep Security 10.1.

Create a SAML Identity Provider and roles in Deep Security

The Deep Security Help Center has a great SAML single sign-on configuration article that will walk you through the steps to set up Deep Security to trust your ADFS server. You’ll need the federation metadata file from your ADFS server, which you can get from https://<your ADFS server name>/FederationMetadata/2007-06/FederationMetadata.xml.

Adding Deep Security as a relying party in ADFS

This is a quick-start blog post, so I won’t get into a lot of detail. There’s a link at the bottom of the article if you want the full reference documentation.

In this example we’ll use the user’s email address as the Deep Security user name (RoleSessionName in Deep Security SAML-speak).

We’re also going to use a handy trick here that lets us use Active Directory groups to manage the role claims that we issue. This trick uses two custom rules, one to extract the Active Directory group information and the second to transform the group information into claims.

To make this work, you’ll need to have a naming convention where your Active Directory group names can be transformed into Deep Security roles. In this example, we’ll use Active Directory group names in the format TMDS-<tenant ID>-<role name>, so TMDS-0123456789-READONLY would be transformed to the URN for the Deep Security role urn:tmds:identity:us-east-ds-1:0123456789:role/ADFS-READONLY.

To create these AD groups, you’ll need the identity provider and role URNs from the Create a SAML Identity Provider and roles in Deep Security procedure described earlier.

We’ll also create a rule that includes a PreferredLanguage claim that takes its value from the preferredLanguage LDAP attribute. This is optional and won’t do any harm if you don’t have this attribute set, but it can be handy if you have a diverse user base.

Finally, we’ll create a rule that includes a SessionDuration claim limiting the user’s sessions to a maximum of eight hours (28800 seconds). This claim attribute is also optional, and the Deep Security administrator can further limit session duration if they want.

Microsoft provides an ADFS Powershell cmdlet that lets you completely configure everything we need in a single command. Run this as admin on your ADFS server to set up Deep Security as a Service as a relying party for your ADFS. If you’re trying to integrate your own Deep Security installation, replace the Name and MetadataURL parameter values, and check to make sure the URNs in the Roles rule match what you have.

 Always read Powershell scripts carefully and make sure you understand what they do before running them. Also, be wary of copy & paste attacks! Always paste into a text editor and review what you’ve copied there before running the script.

Add-AdfsRelyingPartyTrust -Name 'Trend Micro Deep Security as a Service' -MetadataURL 'https://app.deepsecurity.trendmicro.com/saml' -IssuanceAuthorizationRules '@RuleTemplate="AllowAllAuthzRule" => issue(Type = "http://schemas.microsoft.com/authorization/claims/permit", Value="true");' -IssuanceTransformRules '@RuleTemplate = "LdapClaims"
@RuleName = "RoleSessionName"
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]
 => issue(store = "Active Directory", types = ("https://deepsecurity.trendmicro.com/SAML/Attributes/RoleSessionName"), query = ";mail;{0}", param = c.Value);

@RuleName = "Get AD Groups"
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]
 => add(store = "Active Directory", types = ("http://temp/variable"), query = ";tokenGroups;{0}", param = c.Value);

@RuleName = "Roles"
c:[Type == "http://temp/variable", Value =~ "(?i)^TMDS-([^d]+)"]
 => issue(Type = "https://deepsecurity.trendmicro.com/SAML/Attributes/Role", Value = RegExReplace(c.Value, "TMDS-([^d]+)-", "urn:tmds:identity:us-east-ds-1:$1:saml-provider/ADFS,urn:tmds:identity:us-east-ds-1:$1:role/ADFS-"));

@RuleName = "Session Duration"
 => issue(Type = "https://deepsecurity.trendmicro.com/SAML/Attributes/SessionDuration", Value = "28800");

@RuleTemplate = "LdapClaims"
@RuleName = "Preferred Language"
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]
 => issue(store = "Active Directory", types = ("https://deepsecurity.trendmicro.com/SAML/Attributes/PreferredLanguage"), query = ";preferredLanguage;{0}", param = c.Value);'

That’s it!

Well, close to, anyway. You’ll still need to set up groups in Active Directory that match the pattern you defined (in the examples above, TMDS-<tenant ID>-<role name>) and assign users to those groups, but then you’re done!

References