Browser Content Redirection is a technology built around a URL whitelisting mechanism. Two policies are exposed in Studio for that purpose:
i. Browser content redirection Access Control List (ACL) policy settings (a.k.a the ACL policy)
ii. Browser content redirection authentication sites (a.k.a the authentication sites policy)
While the description in edocs tries to cover the general cases, there are some websites using intrinsic redirection mechanisms that make the whitelisting process more difficult.
[Note: websites that rely on Integrated Windows Authentication, or that require a pop-up Windows Security message box are not handled correctly by BCR with CWA 1905 or older. This is because our overlay browser (HdxBrowser.exe or HdxBrowsercef.exe) cannot display that window, hence the user is stuck on a blank page. See CTX230052 (current limitations section)
CWA 1907 for Windows and higher fixes this problem].
As an example of BCR redirections, we will look into Microsoft Teams.
It is essential that the Developer Tools is used to understand the website’s behavior before configuring any policy.
The ‘Preserve Log’ check-box should be ticked, otherwise entries are cleared automatically.
A user typing http://teams.microsoft.com will get an HTTP 307 response from the webserver, repointing the browser to https://teams.microsoft.com
(Hence it is critical that the right syntax is used when whitelisting a website, like http or https, with or without www, etc – otherwise redirection might fail).
From that URL, the resource https://teams.microsoft.com/auth/prelogin is contacted by the browser, which eventually ends up being redirected to:
In this case, the url https://login.microsoftonline.com/* needs to be whitelisted in the ACL policy in Studio.
Since Admins might not want to redirect the entire domain, better granularity can be achieved by leveraging a common parameter in OAuth 2.0 (redirect_uri, where the App name is embedded in the URL).
So whitelisting the following URL in the BCR ACL policy in Studio will achieve the objective, thanks to wildcards:
The Chrome Extension will now be able to inject HdxVideo.js, and the first redirection happens. The user will end up being redirected to an Office 365 Authentication website that is linked to Teams (see screenshot above), but this time the website will be running locally on the endpoint’s overlay browser that is part of Workspace app (HdxBrowserCef.exe).
Important: Please note that any IdP/SSO websites your organization deployed to authenticate users in O365 will also need to be added to the Authentication Sites policy (e.g. https://mycompany.okta.com)
Please also note that Teams will require to add https://login.microsoftonline.com/login* to the Authentication Sites.
After a successful authentication, the overlay browser HdxBrowserCef.exe is pointed back to https://teams.microsoft.com
This URL (https://teams.microsoft.com/*) should now be whitelisted also in the ‘Authentication Sites’ policy in Studio.
Note: This might be somehow counter intuitive as the Authentication site is login.microsoftonline.com, not teams.microsoft.com – yet the problem in Teams is that the Chrome Extension is not loaded fast enough by the Browser and therefore injection fails on teams.microsoft.com.
Browser Content Redirection treats websites whitelisted under the Authentication sites policy as child websites that must remain redirected if the parent website was in the ACL whitelist policy. In the Teams case then, teams.microsoft.com is the child website of the parent login.microsoftonline.com
Note: Peer-to-Peer Video conferencing is currently not available with Teams and Chrome, so it will not work with BCR either. Once Microsoft officially supports Chrome browser for peer to peer video, BCR will support it automatically.
Joining a conference call with video is supported in BCR.
First thing to notice is that navigating to https://gotomeet.me/mymeetingID redirects to https://www.gotomeet.me/mymeetingID
Whitelisting without the ‘www’ will result in failure. So whitelisting https://www.gotomeet.me/* is the solution (in the ACL policy).
Note the use of the wildcard ‘*’ – this allows you to whitelist any path for that URL.
After the webpage is redirected, the user can click ‘Join meeting in browser’, which points to:
Note that this is a different FQDN. So if the user clicks on that link, he will fall back to server-side.
The solution is to whitelist https://app.gotomeeting.com/*
You can either add this to the ACL policy or to the Authentication Sites policy (or both).
The difference is that if you add it only to the ACL policy, if the user clicks on the link it will trigger a re-processing of the URL by the VDA (look up of that URL in the ACL entries), resulting in a few extra redirection steps.
If you add it to the Authentication Sites policy, then since the parent website is https://www.gotomeet.me/* and that is already whitelisted in the ACL policy, a re-processing of the URL by the VDA is not required and the experience is smoother (see last paragraph under the Teams section).
Of course there could be a scenario where the user types https://app.gotomeeting.com/index.html?meetingId=xxxxxxxxxx directly as the first URL in Chrome’s navigation bar. Browser Content Redirection will only kick-in if that URL is on the ACL policy (that is because the Authentication Sites policy is only processed after an ACL match). So in order to prevent this exact scenario from failing, you can add the URL to the ACL and Authentication Sites policies (and hence the reference to ‘both’ in the paragraph above).
Microsoft’s corporate video-sharing platform runs as an Office 365 service.
The URL https://stream.microsoft.com/* needs to be whitelisted in the ACL policy.
That is because whitelisting https://web.microsoftstream.comwill not work, since that page redirects to login.microsoftonline.comusing HTTP response status code 302 Found, and that page in turn redirects to https://stream.microsoft.com.
Once the browser lands on that website, clicking on Sign In will redirect to https://login.microsoftonline.com/common/oauth2/*microsoftstream*
where the user finally will insert his credentials.
Hence the site https://login.microsoftonline.com/*microsoftstream* needs to be added to Authentication Sites.
(This is different from the behavior in Teams).
If you are using SSO solutions like OKTA, or ADFS, the URLs will need to be added under Authentication Sites also.
Finally, also add https://web.microsoftstream.com/* to the Authentication Sites.
Google Meet and Google Hangouts
Add https://meet.google.com/* to the ACL policy.
Add https://hangouts.google.com/* to the ACL policy.
Important: Add https://accounts.google.com/* to the Authentication Sites policy.
Any other website used for SSO (e.g. Okta) must be added to the Authentication Sites policy (it could be more than one).
These websites require WebRTC support, hence you must use Citrix Workspace app 1809 for Windows or higher.
Currently, outgoing screensharing is not supported when using BCR.
Cisco Webex Teams
Add https://teams.webex.com/* to the ACL policy.
Add https://idbroker.webex.com/* to the Authentication Sites policy. This entry might vary depending on your Organization’s SSO configuration and IdP providers. Any website used for SSO must be added to the Authentication Sites policy (it could be more than one).
Cisco Webex Meetings
Currently not supported since this website uses Content Security Policy (CSP). See CTX230052.
Citrix and Cisco are collaborating on this and are aiming to have a solution ready.