---
myst:
  html_meta:
    "description lang=en": "How to use utlize Kasm to publish Protected Web Apps."
    "keywords": "Kasm, How to, How-to, Web, Web Apps, Protected Web Apps"
    "property=og:locale": "en_US"
---
```{title} Protected Web Apps 
```

# Protected Web Apps

The following is a guide for configuring Kasm to provide secure access via Protected Web Apps.

Protected Web Apps are browser based applications that are either hosted internally on protected enclaves or are other SaaS based 
web applications that administrators wish to publish to end user while employing the robust authentication and DLP controls of Kasm.



```{figure} /images/protected_web_apps/diagram.png
:align: center
**Protected Web App Diagram**
```


## Configuring a Browser-based Workspace

1. Log into the Kasm UI as an administrator.
2. From the Admin panel, expand  **Workspaces**, and select **Registry**
3. The Kasm Workspace Registry entries should be visible. Select the Chrome Workspaces from the list, then select **Edit**

```{figure} /images/protected_web_apps/add_chrome_workspace.png
:align: center
**Chrome Workspace from Registry**
```

4. Update the name description of the workspace to something helpful. In this example we will use `Gitlab`.

5. In the **Docker Run Config Override** section enter the following data to configure the chrome browser to open to a specified URL (e.g `https://gitlab.com/users/sign_in`).

```json
{
  "environment": {
    "LAUNCH_URL": "https://gitlab.com/users/sign_in"
  }
}
```

```{figure} /images/protected_web_apps/launch_url.png
:align: center
**Chrome Workspace from Registry**
```

6. Adding a URL to a thumbnail of the target application will help user's quickly identify the workspace (e.g `https://gitlab.com/favicon.png`). Once done, click **Save**


## Launching the Workspace

1. Back on the Workspace dashboard, the new `Gitlab` workspace should be visible.
   

```{figure} /images/protected_web_apps/launch_workspace.png
:align: center
**Gitlab Workspace**
```

2. Launch the workspace and confirm the browser navigates to the desired web app.

```{figure} /images/protected_web_apps/session1.png
:align: center
**Protected Web App**
```

## (Optional) Kiosk Mode

In the last example, you will notice that the containerized chrome browser fully loads within the end user's browser. This will give a "browser in browser" effect that may or may not be desirable.

If you'd like to remove the navigation bar from within the Chrome workspace, change the Docker Run Config Override setting 
for the `Gitlab` (Chrome) Workspace to include the `--kiosk` argument for the `LAUNCH_URL` environment variable.

```json
{
  "environment": {
    "LAUNCH_URL": "--kiosk https://gitlab.com/users/sign_in"
  }
}
```

The difference between the default behavior and kiosk mode can be seen below.

```{figure} /images/protected_web_apps/kiosk_comparison.png
:align: center
**Protected Web App**
```

## (Optional) Managed Browser Policies

Administrators may wish to add and/or enforce certain capabilities within the containerized browsers such as pre-defining bookmarks, adding extensions or disabling features like developer tools.
The best way to do this is via the [Chrome's Managed Policies Guide](../how_to/chrome_managed_policies).

```{raw} html
<iframe src="https://www.youtube.com/embed/i49fszQtHEI" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>
```


## (Optional) Web Filter

Administrators my wish to employ the Web Filter to restrict users from accessing web content outside of the approved web app.

1. Log into the Kasm UI as an administrator.
2. From the Admin panel, expand  **Settings**, and select **Web Filter**
3. Select Add Policy
4. Give the Policy a name (e.g `Gitlab Policy`) and select **Deny by Default**.
5. In this example we want to block all access except for the gitlab domain ad any other required domains needed (e.g for authentication with google). Add the approved domains to the **Whitelist**.
   
```{figure} /images/protected_web_apps/gitlab_policy.png
:align: center
**Protected Web App**
```

6. Click Save.
7. Edit the previously defined workspace, update the Web Filter Policy to the use the `Gitlab Policy`.

```{figure} /images/protected_web_apps/workspace_web_filter.png
:align: center
**Protected Web App**
```

8. Test access to the Protected Web App. Ensure proper functionality is allowed. Navigating to an unapproved site should result in a blockage.

```{figure} /images/protected_web_apps/web_filter_block.png
:align: center
**Protected Web App**
```



## (Optional) Watermarking

Administrators may wish to apply a graphic or text based watermark to be displayed during the session. Utilize the 
following File Mapping example, to apply a watermark to the {ref}`file-mapping-kasmvnc` Workspace.

```{figure} /images/protected_web_apps/watermark.png
:align: center
**Protected Web App**
```


## (Optional) DLP Controls

Administrators may wish to apply additional data loss prevention settings such as restricting the user's ability to 
upload/download files, copy and paste text/image via the clipboard etc. 
Most of these items can be applied via Group Settings and are explained in the [Data Loss Prevention Guide](../security/data_loss_prevention.md)

It may be helpful to review how Group Settings can be applied and layered. A walkthrough is available in the video below

```{raw} html
<iframe src="https://www.youtube.com/embed/JkYF20Kq4G8?start=75" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>
```