Desktop and Application Streaming

How Verint Uses Amazon WorkSpaces Web to Securely Access Internal Resources

Amazon WorkSpaces Web is a low-cost, fully managed, secure browser built to facilitate secure access to internal websites and software as a service (SaaS) applications from existing web browsers, without the administrative burden of appliances or specialized client software. Protect internal content with enterprise controls, while providing access to all the web-based productivity tools users need from any browser.

About Verint

Verint helps the world’s most iconic brands build enduring customer relationships by connecting work, data, and experiences across the enterprise. They help organizations adapt to the future of work, reduce the inefficiencies created by organizational and data silos, and consistently deliver differentiated experiences at scale.

The Challenge

Verint had a large number of users across the globe that needed secure access to internal websites to complete product development tasks. These users have varying technical backgrounds and the solution needed to allow access to internal websites without the use of a full virtual desktop. The solution needed to have minimal administrative overhead to stand up and maintain. The solution needed to be easily secured with MFA, Active Directory, and HTTPS to adhere to internal policies. The internal websites were hosted out of several accounts, Regions, and networks, this required a central landing zone to access these resources.

The first target use case was users accessing an internal Jenkins instance. The existing solution for this use case was allow listing users public IPs for access. However, users had dynamic public IPs, and this became difficult to maintain and a new approach was needed.

Using WorkSpaces Web to Securely Access Internal Resources

Verint selected WorkSpaces Web to provide secure access to internal resources. By leveraging WorkSpaces Web, we were able to remove the need to maintain individual network access and replace it with a personalized web portal.

Overview of the Solution

The solution utilizes several services to complement the WorkSpaces Web deployment. These services include Transit Gateway, Route 53 Resolver, PrivateLink, CloudFront, and AWS Certificate Manager (ACM). The final solution provides an easy to access web portal for users to login via their browser and securely access resources within Verint’s network. This blog provides a high-level design overview for Verint’s use case and not step-by-step guidance.

Figure 1 – High-Level Architecture

This solution accounts for several design considerations:

  • WorkSpaces Web configuration
  • Custom domain name for the WorkSpaces Web user portal
  • Internal name resolution from the WorkSpaces Web session
  • Network access to internal resources in separate Virtual Private Cloud (Amazon VPC)

  1. WorkSpaces Web Configuration

The WorkSpaces Web portal was configured within its own account and Amazon VPC, across multiple Availability Zones within a single Region. A separate account and VPC was used to isolate the Workspaces Web resources from other shared services and provide clear cost visibility for the solution. When you select a VPC and subnets, WorkSpaces Web creates cross-account Elastic Network Interfaces (X-ENIs) and places them within your subnets. The instances attached to the X-ENIs run in a managed AWS account. The Amazon VPC was connected to the existing Transit Gateway to provide direct routing for domain name resolution requests.

Figure 2 – Workspaces Web customer owned dedicated account

  1. Custom Domain Name

In order to facilitate easy user access, a custom domain name was needed for the WorkSpaces Web user portal. Using Amazon Route 53, AWS Certificate Manager (ACM), and Amazon CloudFront, we were able to configure a custom friendly domain name for users to securely access the WorkSpaces Web portal.

Note that this is not a full custom domain solution, and the user will be redirected to Workspaces Web portal URL to sign in.

The following steps outline the required steps:

  • Register a public domain (workspacess-web.example.com) with Route 53
  • Generate a public certificate request for the portal’s friendly name (workspacess-web.example.com) using ACM
  • Create a Amazon CloudFront distribution to route users to the WorkSpaces Web Portal endpoint
    • Set the Origin to the WorkSpaces Web Portal endpoint (your-portal-id.workspaces-web.com) and the protocol to HTTPS only
    • Add the portal’s friendly name (workspacess-web.example.com) as an alternate name to the CloudFront distribution
      • Assign the ACM certificate previously created to the CloudFront distribution
    • Change the CloudFront Viewer Protocol Policy to Redirect HTTP to HTTPS
  • Create a CloudFront function to add a redirect for CloudFront distribution
    • The function code should look like below:
function handler(event) {
    var response = {
        statusCode: 302,
        statusDescription: 'Found',
        headers: {
            'location': { value: 'https://your-portal-id.workspaces-web.com' }
        }
    };
    return response;
}
  • Publish the function and associate it with the distribution you created above

Alternatively, you can also configure IdP-initiated sign in flow with your SAML 2.0 compliant IdP and configure a custom domain for IdP-initiated sign in through your SAML 2.0 compliant IdP. See WorkSpaces Web Admin guide on how to configure this flow.

  1. Internal Name Resolution

In this solution, we leveraged Route 53 Resolver to handle name resolution across multiple-accounts and Regions. Route 53 resolvers were chosen to allow the default VPC resolver to answer DNS queries for custom internal domain names without needing to adjust DHCP option sets. Route 53 Resolver outbound resolvers and rules are deployed into private subnets in the WorkSpaces Web account and Amazon VPC. The resolver rules are configured to send specific domain name lookup requests to an external DNS provider. In this case, Active Directory integrated DNS servers hosting private domains are running within the accounts and Regions hosting the internal service. These domains are used to create records for the internal resources the WorkSpaces Web users will access.

  1. Network Access

PrivateLink is an alternate design pattern to overcome certain network restrictions. These include overlapping IP space, lack of transit connectivity, and security concerns over attaching sensitive Amazon VPCs to resources shared across account boundaries. Verint selected PrivateLink to provide WorkSpaces Web users access to a number of internal resources in other Amazon VPCs. This was preferred to allow unidirectional traffic from WorkSpaces Web.

Figure 3 – Workspace Web connecting to remote Network Load Balancer via AWS PrivateLink

Outcome

The final solution showcases a multi-account architecture that allows for Workspaces web to connect seamlessly and reliably to all internal web-based tools. By leveraging Native AWS networking services, you can easily connect accounts, Regions, and networks within your organization. Workspaces Web supports user authentication using any SAML 2.0-compliant identity providers allowing flexibility to integrate your existing authentication solution. Route 53 provides easy integration with your existing DNS solution. This modular architecture allows Workspaces Web to easily fit within an existing AWS deployment.

Figure 4 – Multi-Account Architecture

After a successful pilot using Workspaces Web to access Jenkins, Verint decided to roll this out for the remaining internal web-based tools across their organization. An internal tool was used to track all tools that would be onboarded for access. Key data was gathered by each team including application type, source IPs, number of users, and accounts where the tools were hosted. This data was used to configure the necessary network access between the Workspaces Web account and the destination accounts hosting the additional tools.

This information was then used to create a tailored list of published bookmarks that end users would use to access internal tools. These tools get published as managed bookmarks and are presented to the users in the Chrome browser bookmark bar for easy access.

Figure 5 – Managed Bookmarks published in Workspaces Web browser

Conclusion

In this blog post we described how Verint used WorkSpaces Web portal across our organization with a multi-account environment. Once we had WorkSpaces Web portal deployed within our organization, we were able to utilize native AWS services and design patterns to access existing network resources. Our internal resources can exist within that Amazon VPC, in another Amazon VPC, on premises, or on the public internet as long as the Workspaces Web ENIs have network connectivity to the resources.

You can get learn more about getting started with WorkSpaces Web from the AWS Administration Guide. When you are ready to create your first WorkSpaces Web portal, you get started from the WorkSpaces Web AWS Management Console.

About the authors

John Jones is a Manager of Cloud Infrastructure at Verint Systems Inc. John is a Cloud Architect by trade who has led Verint’s transition from a traditional software vendor to a cloud-first SaaS provider. He resides north of Atlanta and enjoys roses, long walks on the beach, and scary movies.
Bill Pfeiffer is a Sr. Solutions Architect at Amazon Web Services. Bill is focused on helping customers design, implement, and evolve secure and cost optimized infrastructure. Bill is passionate about helping customers solve business challenges with technical solutions. Outside of work, Bill enjoys traveling the US with his family in their RV and competing in Spartan Races.