Integrating Google Enterprise Browser with Omnissa Workspace One

Opening

If you've been following my recent articles, you'll have noticed that I've been fascinated with enterprise browser technology lately, and I've been laser-focusing on one specific enterprise browser. In fact, I've spent quite a bit of time walking through how that enterprise browser integrates with Omnissa technologies like Horizon and Access to show off capabilities and integrations that are not too well documented. Well, in this one, I want to shift gears a bit and explore the same space but from the perspective of another enterprise browser, Google's Chrome Enterprise Browser, which brings some interesting opportunities for organizations that are already invested in Chrome as their enterprise standard.

Much like the previously written articles about enterprise browsers, the Chrome Enterprise Browser provides centralized management, control, and integration with identity providers (IDPs). Google specifically manages Chrome via the Google Admin Console, which serves as the control plane for all enterprise browser security and functions. Omnissa Access plays the role of the trusted identity provider, brokering authentication and presenting the enterprise portal that unifies SaaS, VDI, and conditional access into a single user experience. Meanwhile, Workspace ONE UEM serves as the configuration and enrollment engine across operating systems—delivering tokens, enforcing policy, and ensuring that Chrome Enterprise on Windows, macOS, Android, and iOS devices is automatically enrolled and governed.

My goal here is not to start a holy war over which enterprise browser is "better" nor is it to go through an exhaustive feature-by-feature comparison; I'll leave that to a workshop. Instead, this article explores the specific use case of integrating Omnissa's Workspace ONE UEM and Access with Chrome Enterprise Browser. Enhancing Chrome Enterprises already strong offering in the enterprise browser market.

The building blocks

Now that we've got that out of the way, before we dive into the steps, let's set the stage with the components:

• Chrome Enterprise Browser: At its core, this is the normal Chrome browser all users are accustomed to but supercharged to make it enterprise grade. The browser features and functions are managed through the Google Admin Console, from which IT admins can enforce policies, control sign-in behaviors, and integrate with third-party SAML-based SSOs. Management spans across Windows, macOS, Android, and iOS for a consistent experience.
• Omnissa Access: I've always felt the Omnissa Access portal has been an underutilized asset by the customer base that provides more value than folks are aware of. Access acts as the identity and access manager that provides an enterprise portal to the end user base. It further can be used as a conditional access manager for the enterprise applications that are integrated into the portal. All of this enables secure authentication and single sign-on (SSO) to all your SaaS and VDI based enterprise apps from one place.
• SAML Integration: Among the many features available via the Google Admin Console, it can be configured to integrate with SAML-based SSO providers to ensure only authorized users can access the browser. In this article, we'll integrate Chrome Enterprise Browser with Omnissa Access, which will act as the identity manager. Omnissa Access can also federate with legacy Active Directory, extending SAML authentication to legacy identity infrastructures.
• Workspace ONE UEM: A key accelerator in this setup is using a Unified Endpoint Management (UEM) product like Workspace ONE UEM to deliver enrollment tokens and configure Chrome for enterprise use. Whether on Windows, macOS, Android, or iOS, UEM can push down the necessary enrollment token and policies so that Chrome Enterprise Browser automatically enrolls into the correct domain. This is incredibly useful for IT because it means no manual user enrollment is required—devices come pre-configured and policy-ready out of the gate.
  • Multi-OS Enrollment at a Glance
    • To make it easier to see how Chrome Enterprise Browser enrollment works across platforms, here's a quick reference table:

• This shows that while the delivery mechanics vary slightly by OS, the end result is the same: Chrome Enterprise Browser launches in a managed, policy-driven state.

How it's done

Step 1: Generate Enrollment Token in Google Admin Console

Before Workspace ONE UEM can do its job, you need to create the Chrome enrollment token in the Google Admin Console.

1. Navigate to Devices > Chrome Browser > Managed browsers.
2. Create a Windows enrollment token. This token uniquely identifies your domain.
3. Save the token for import into Workspace ONE UEM.

Step 2: Configure Workspace ONE UEM for Browser Enrollment

Once you have the enrollment token, configure Workspace ONE UEM to handle delivery and policy on Windows devices.

1. Import the token into Workspace ONE UEM
   In the UEM console, create a Windows configuration profile and add the enrollment token. This allows UEM to automatically pass the token to Chrome on managed Windows devices.
2. Assign the configuration to device groups
   Publish the configuration profile to the appropriate smart groups or organizational units so that targeted devices receive the enrollment token.
3. Deploy Chrome policies through UEM
   Google provides details on managing Chrome policies with Windows group policy or MDM. In UEM, you can import the Chrome ADMX templates, configure policies like extensions, sign-in restrictions, or homepage defaults, and push them to endpoints.

With this in place, Windows endpoints provisioned through UEM will automatically enroll Chrome into the enterprise environment without any user interaction.

Other OS Platforms

While this article focuses on Windows as the reference platform, Chrome Enterprise Browser enrollment can also be extended to other operating systems with Workspace ONE UEM:

• macOS – Use Workspace ONE UEM to deliver the Chrome enrollment token through a configuration profile. Google provides instructions for enrolling browsers on macOS.
• Android – Managed configurations can be deployed from UEM to pass the enrollment token to Chrome on managed Android devices. See Google's guidance for enrolling Chrome on Android.
• iOS – Enrollment is handled through profile payloads delivered by UEM. Google documents this process in enrolling Chrome on iOS.

Note: This guide focuses on the major decision points and does not enumerate every possible setting. The Google Admin and Chrome policy docs linked above provide the full configuration matrix. The aim here is to show how Google Admin (token creation), Workspace ONE UEM (delivery and policy), and Omnissa Access (SSO and portal) fit together.

Step 3: Configure Browser Sign-In

One of the key steps is to define how users will authenticate into Chrome. Inside Google Admin Console > Devices > Chrome Browser > Settings > Browser sign-in settings, you'll want to enforce one of the following:

• Enable browser sign-in – allows users to link their Google identity.
• Force users to sign-in – ensures users must authenticate before using the browser.

For enterprise deployments, the latter is recommended.

Step 4: Set Up Omnissa Access as Your SAML IdP

Google provides documentation for SSO setup. The high-level configuration looks like this:

1. Log into Google Admin Console.
2. Navigate to Security > Authentication > SSO with third-party identity providers.
3. Select Add SAML profile.
4. Download the Google IDP metadata and import it into Omnissa Access.
5. Upload the Omnissa Access metadata back into Google.
6. Map attributes (e.g., email, username, groups) to align with Omnissa Access.

Once complete, Chrome Enterprise Browser will defer authentication requests to Omnissa Access for SSO.

Step 5: Enforcing Policy in Chrome

After the IdP is integrated, admins can layer in additional policies for user sessions, extensions, and app access. This ensures that when a user signs into the browser, they inherit corporate policies and gain seamless access to apps published through Omnissa Access.

The end-user experience

From the user's perspective, the flow is simple and polished:

• Chrome Profile Selector – Upon launching Chrome, users are required to either create a new profile or choose to sign in with their enterprise credentials.

• Omnissa Authentication – Once the profile is chosen, they're redirected to Omnissa Access, which acts as the broker for authentication.

• Application Access – After successful login, the user arrives at the Omnissa Access portal, where enterprise apps and resources (VDI desktops, published applications, and SaaS apps) are available.

• Managed Browser Session – The browser session is now fully governed by corporate policies. An end user can verify by selecting the three dots in the top right corner of the browser session. In that drop down menu, Chrome displays "Managed by [your organization]", ensuring the user is in a secure, controlled environment.

Why this matters

Integrating Chrome Enterprise Browser with Omnissa Access gives organizations:

• The familiar Chrome experience for end-users.
• Enterprise-grade policy control for IT.
• Omnissa-powered identity integration, providing secure SSO across all corporate resources.
• Omnissa portal provides an enterprise app store and landing page for users to consume productivity applications from one location.
• Workspace ONE UEM simplifies delivery of enrollment tokens and configurations—especially for Windows, macOS, Android, and iOS devices—so the setup is automated and consistent across your fleet.

Final thoughts

As enterprises evolve their EUC strategy, the browser is increasingly the operating environment of the enterprise. Chrome Enterprise Browser, integrated with Omnissa Access, delivers the secure and streamlined authentication experience users expect—while giving IT the policy controls they need. By layering in Workspace ONE UEM to deliver the enrollment token and push the Chrome configuration, enterprises can ensure a hands-off, consistent, and secure deployment across all major operating systems.