Теория сама по себе никуда не годится, она нужна постольку, по­скольку заставляет нас верить в связь явлений. (И. В. Гете)

WorxWeb (сокращённо WW) – это веб-браузер для мобильных платформ Android и iOS. В отличии от встроенных в мобильные ОС браузеров WorxWeb может доставляться на устройства в виде MDX приложения. MDX позволяет:

– Туннелировать трафик браузера во внутреннюю сеть. При этом трафик пользовательских приложений туннелироваться не будет.

– Блокировать обмен данными между пользовательскими приложениями и браузером. Например, скриншот сделанный в браузере нельзя будет вставить как картинку в Facebook.

– Шифровать данные браузера. Например, файл-документ скаченный в WorxWeb будет сохранен на флэше. Если попытаться открыть этот файл в Facebook для публикации, то вместо картинки приложение получит файл со случайным набором символов.

Но не стоит забывать о другой важной функции WorxWeb – это SSO – single sign on. Функционал SSO заключается в том, что при доступе через WorxWeb-браузер к корпоративным ресурсам вам не надо каждый раз вводить свои username/password. Вы будете автоматически аутентифицироваться под тем пользователем, под которым вы запустили WorxHome (сокращённо WH) на своём мобильном устройстве.

Говоря технически, функционал SSO обеспечивает не WorxWeb, а Netscaler Gateway (сокращённо NSG).

Изначально, когда вы запускаете любое MDX приложение, WorxHome устанавливает microVPN соединение с NSG и просит пользователя аутентифицироваться введя его доменные имя пользователя и пароль. Эти данные хранятся в RAM памяти NSG. В ответ NS отдает WH http-cookies, которые в дальнейшем используются для аутентификации.

Рассмотрим, что происходит, когда WorxWeb пытается открыть по HTTP внутренний портал, требующий аутентификации.

  1. WW инициализирует TCP-соединение. WH перехватывает запрос и туннелирует его в SSL соединение на NSG. Устанавливает SSL соединение и аутентифицируется на NSG с помощью, ранее выданной cookies, или запрашивает AD credential.
  2. Между WorxWeb и NSG устанавливается защищенное TCP соединение.
  3. WW инициирует HTTP запрос http://internal.portal/.
  4. WH заменяет ссылку http://internal.portal/ на https://NSG.address/internal.portal/.
  5. NSG устанавливает соединение на сервер http://internal.portal/
  6. Сервер отвечает HTTP 401 error, что означает что для доступа к этой странице требуется аутентификация.
  7. NSG аутентифицируется на сервере http://internal.portal/ учетными данными пользователя.
  8. Если учетные данные верны, то сервер отвечает HTTP STATUS 200 OK. Эта страница возвращается на WorxWeb.

Не забываем, чтобы WorxWeb SSO работал должны быть соблюдены следующие условия:

  1. Если сервер требует аутентификации username/password в AD, то на NSG в качестве одного из фактора аутентификации должна быть сконфигурирована такая же AD LDAP аутентификация. Если на сервере для аутентификации используется OTP (One Time Password), такой же OTP должен быть сконфигурирован на NSG.
  2. NSG должен «увидеть» HTTP 401. То есть WH должен понимать, что MDX приложение генерирует именно HTTP трафик, а не какой-то другой TCP поток. NSG способен распознать HTTP 401 только в том случае, если сессия http. В случае https SSO работать не будет.

До сих пор описываемый вид VPN называется SecureBrowse – когда WH преобразует ссылки вида http://internal.portal/ в https://NSG.address/internal.portal/.

Допустим, осуществляется доступ к внутреннему WEB-порталу и требуется аутентификация по сертификатам: SSO аутентификация не будет работать, так как у NSG нет клиентского сертификата, и двусторонний SSL будет невозможен.

Для подобного рода исключений NSG поддерживает другой тип VPN называемый microVPN.

Трафик WW не разбирается до уровня HTTP. NSG терминирует на себе клиентское TCP соединение и устанавливает TCP до бэкенд сервера. SSL/TLS устанавливается непосредственно между клиентом и сервером.

3. NSG должен поддерживать тот вид аутентификации, который запрашивает сервер. NSG поддерживает следующие типы аутентификации:

  1. Basic HTTP Authentication
  2. Digest HTTP Authentication
  3. NTLM Authentication
  4. Kerberos Constrained Delegation
  5. SAML Authentication
  6. Form Fill Authentication 

Эта статья является вольным переводом оригинальной статьи: /blogs/2013/12/24/xenmobile-worxweb-single-sign-on-with-netscaler/