About Web@Work

Web@Work is a secure browser that allows enterprise users to securely access web content in their corporate intranet. Using Web@Work you can limit access to enterprise data to authorized users. When Web@Work is deployed in conjunction with AppTunnel, you secure the enterprise data in motion. The Docs@Work app for iOS is an AppConnect enabled app. The Web@Work app for Android is an AppConnect wrapped app.

Web@Work for Android, like all secure apps for Android, can only be distributed as an in-house app. When you distribute Web@Work, distributing the Secure Apps Manager is required.

You make Web@Work for Android available to device users as an in-house app in the App Catalog in the Core Admin Portal (under Apps > App Catalog > In-House). The device user launches Mobile@Work for Android to discover and install Web@Work, where it will appear under Secure Apps within the Mobile@Work app.

Web@Work for Android is available in two flavors Android AppConnect and Android AppStation.

Web@Work Android AppConnect

Web@Work is available as an Android AppConnect app.

AppConnect feature containerizes apps to protect data on Android devices. Each AppConnect-wrapped app becomes a secure container whose data is encrypted, and protected from unauthorized access. Because each user has multiple business apps, each app container is also connected to other secure app containers. This connection allows the AppConnect apps to share data, such as documents. AppConnect apps are managed using policies configured in a Unified Endpoint Management (UEM) platform. The UEM platform is either Core or Cloud.

As an AppConnect app, all Web@Work data is secured. The app interacts with other apps according to the data loss prevention policies that you specify. You can also take advantage of AppConnect features such as app authorization and app configuration.

For information about AppConnect features and configuration beyond Web@Work for Android, see AppConnect and AppTunnel Guide.

Web@Work for Android AppStation

Web@Work is available as an Android AppStation app for Cloud only. AppStation is specifically designed as the UEM client for a MAM-only deployment with Cloud. In a AppStation MAM-only deployment, only apps available through AppStation are managed. The following types of apps are supported:

  • AppConnect apps (wrapped with Secure Apps Manager for AppStation)
  • Non-AppConnect apps (in-house or from the Google Play Store)

Multi-factor authentication and authorization for device users

Device users can use Web@Work only if the following are true:

  • The device and user are registered with Core. Registering a device with Core authenticates the device user.
  • The device is authorized to use Web@Work. Using the Admin Portal, you authorize a device to use Web@Work. You use Core’s labeling mechanism to indicate which devices are authorized to use Web@Work. If the device is not authorized to use Web@Work, the device user cannot use it even for accessing public websites.
  • The device is in compliance with the security policy applied to the device. Using the Admin Portal, you can set up security policies to block access to Web@Work if the device fails to meet conditions that you specify. When access is blocked, the device becomes unauthorized to use Web@Work. Also, all AppTunnel access is blocked, which blocks access to enterprise websites. On iOS devices, be sure to require a device passcode on the security policy, since a device passcode enables iOS data encryption capabilities. Web@Work uses iOS data encryption capabilities to encrypt browser data.
  • Device users are logged in with their secure apps passcode. Web@Work is an AppConnect app, and therefore, you can optionally require the device user to enter a secure apps passcode to use it. The device user uses one secure apps passcode to access all AppConnect apps. When device users first launch Web@Work, they are prompted to create a secure apps passcode if they had not already created one to use some other AppConnect app. On subsequent launches of Web@Work, users are prompted to enter the secure apps passcode, unless they had recently entered it to use some other AppConnect app.

After device users have registered the device with Core and, if required, entered their secure apps passcode, they require no further Web@Work setup.

A device user cannot specify Web@Work as the default browser on the device. This prohibition ensures that the device user always has easy access to a browser for non-enterprise browsing, even if the device becomes unauthorized to use Web@Work.

Secure enterprise web content access using AppTunnel

Web@Work uses AppTunnel technology to securely access web content behind your enterprise’s firewall. This technology allows you to:

  • Set up Web@Work to access enterprise websites without requiring the device user to set up VPN.
  • Support Single Sign On using Kerberos Constrained Delegation (KCD). Device users register Mobile@Work with Core by entering their Ivanticredentials. They can then use Web@Work to access an enterprise app server without having to enter any further credentials. This support depends on the environment being set up to use KCD, and the necessary AppTunnel configuration.
  • Limit enterprise access to Web@Work. Other apps, such as mobile email and calendar synchronization, are not impacted by Web@Work’s enterprise access. Therefore, unlike when you use VPN for enterprise access, you do not have to retest the behavior of these existing apps.
  • Limit the enterprise sites that a device user can access. You can specify accessible sites in the tunneling configuration. Specifically, as long as the device stays on the external network, internal sites that are not specified in the tunneling configuration remain inaccessible. Furthermore, you can vary the accessible sites according to device and user attributes, such as user membership in the enterprise directory.
  • Terminate enterprise website access based on compliance policies. Using the security policy for a device, you can specify which non-compliance situations block AppTunnel access.
  • Perform URL filtering to audit and enforce web use policies. If you direct all outgoing traffic through a filtering proxy, you can direct traffic that you tunnel through the proxy, too. For example, by setting up Web@Work to tunnel all requests to www.SomeExternalWebSite.com, you can set the URL rules in your filtering proxy to block access to that site.
  • Benefit from split-tunneling. You can allow device users to access some public websites without tunneling, while enforcing tunneling for other external as well as enterprise websites. By setting up this split-tunneling, your device users can access public sites without incurring additional load on enterprise network infrastructure. In addition, split-tunneling allows users to access public websites without visibility to the enterprise. Regional privacy regulations sometimes require this for personally-owned devices.
  • Secure tunneled web traffic using multi-factor authentication and authorization. To use Web@Work:
    • A device must be registered with Core and authorized to use Web@Work.
    • You can optionally require a secure apps passcode to access Web@Work, in addition to the device passcode. Note that for Android devices running Secure Apps Manager 7.0 and earlier, a secure apps passcode is mandatory.

Furthermore, establishing an AppTunnel requires a unique client-side certificate, ensuring that only managed and authorized devices can access enterprise websites. You can get certificates from a third-party certificate authority (CA) or from the CA built into Core.

Enable Access for Web@Work

Web@Work now supports Access, which is a cloud service that secures access to enterprise content in business cloud services such as Office 365, G Suite, Salesforce, Box, and Dropbox. For information about Access as a service and how to set up the service with Core, see the Access Guide.