Аутентификация по сертификатам для удаленного доступа зачастую является ключевым требованием безопасности.

Наиболее распространённый сценарий встречающийся у заказчиков следующий. Пользователям выдают USB-токен, на котором находится пользовательский сертификат, защищенный пин-кодом. Пользователь вставляет USB-токен в свой ноутбук, драйвер токена запрашивает пин-код. Далее пользователь запускает CitrixReceiver и подключается к XA/XD ферме. В момент подключения его просят выбрать сертификат для аутентификации из списка, среди которых находятся сертификаты, установленные в операционной системе и в том числе сертификат находящийся на usb-токене.

Что на самом деле представляет из себя аутентификация по сертификату? Пользователь, подключаясь к серверу, сообщает примерно следующее: «я Василий, покажи мне плиз страничку ххх.рф». Сервер ему в ответ говорит: «Докажи, что ты Василий! Я знаю и умею безошибочно проверять подпись Василия. Распишитесь, пожалуйста, под этим документом».

Цифровая подпись под чем-то цифровым представляет собой следующее. Sign = F(x), где

X – это цифровая версия подписываемого документа, например, побайтовая сумма всех символов.

F – необратимая математическая функция. Например MOD5 – целочисленный остаток от деления на 5. MOD5(7)=(7-5*n)=(7-5*1)=2. MOD5(18)= (18-5*n)=(18-5*3)=3. Под необратимостью подразумевается, что зная X и зная SIGN (имея документ и видя подпись), невозможно определить, какая именно F используется, чтобы злоумышленнику самому потом тайком от чужого имени подписывать документы. MOD567(1234)=100; (1234=567*2+100). А теперь представьте, что «567» Вам не известно, а известно, что MODX(1234)=100. Найдите Х? А если числа используются 1000-значные…

F будем называть закрытым ключом для подписи.

Пользовательскому приложению закрытый ключ подписи Василия не доступен в явном виде– это было бы не безопасно – хранить закрытый ключ на компьютере таким образом, чтобы любое приложение могло бы его себе взять. Поэтому приложение вызывает системное API SignMyMessage(“message text”) – прошу операционную систему подписать закрытым ключом это сообщение. Если ключ находится в хранилище ОС, то API обращается к этому хранилищу за закрытым ключом, подписывает и выдает подпись. Если ключ находится на usb-токене, то API обращается к драйверу токена, драйвер запрашивает у пользователя pin-код, если pin верный, то драйвер выдает API-функции закрытый ключ, или алгоритмом API подписывает сам.

Сложность в том, что в мобильных OS, например, в iOS, нет общедоступных API для доступа к пользовательским сертификатам. API доступны только для некоторых приложений, например для Cisco VPN client.

XenMobile MDM умеет автоматически при энролменте выписывать пользовательские сертификаты и устанавливать их в хранилище мобильной ОС. В версии XenMobile Enterprise Edition 8.6 можно автоматически устанавливать сертификаты не только в хранилище ОС, но и в отдельное хранилище WorxHome. Но Citrix Receiver не может использовать ни установленные в ОС сертификаты, ни сертификат находящийся в WorxHome – такова архитектура мобильной ОС.

Поэтому придуман следующий трюк.

Citrix Receiver аутентифицируется на NS с помощью технологии STA – secure ticket authority. Ticket представляет из себя какую-то уникальную строку типа «FE0A7B2CE2E77DDC17C7FD3EE7959E79». Но для того, чтобы получить ticket необходимо аутентифицироваться по сертификату. По сертификату аутентифицируется WorxHome, так как в его хранилище имеется сертификат.

  1. Worx Home подключается к VIP NSG (Virtual IP Adress) (Netscaler Gateway). NSG смотрит в настроенные политики, видит, что для аутентификации требуется сертификат и username:password из AD. NSG запрашивает эти данные и WH высылает их.
  2. После успешной аутентификации запрос отправляется на Application Controller AppC. WH просит список приложений и их параметры для данного пользователя.
  3. AppC от имени пользователя запрашивает у StoreFront список XA/XD приложений для данного пользователя.
  4. SF выдает список XA/XD приложений. Не описывая процесс более сложно, условимся, что в этот момент на SF создается STA тикет и генерируются ICA-файлы для доступа к XA/XD приложениям. В реальности STA и ICA создаются не в тот момент, когда пользователю генерируется список доступных приложений, а тогда, когда пользователь нажимает на иконку конкретного XA/XD приложения. Внутри ICA файла в том числе находится STA тикет.
  5. ICA выдаются AppC.
  6. Список XA/XD приложений добавляется к списку приложений AppC (это MDX, native mobile apps, WEB/SaaS) и отсылается в WH для отрисовки на экране мобильного устройства.

После предыдущих шагов, с точки зрения XA/XD, на мобильном устройстве оказываются ICA файлы, в которых содержится STA-тикет, необходимый для аутентификации и подключения с серверу XA/XD.

  1. Пользователь нажимает иконку XA/XD приложения. ICA файл ассоциированный с этой иконкой открывается в Citrix Receiver CR. В ICA файле имеется адрес NSG шлюза. CR подключается к NSG и предоставляет ему STA-тикет.
  2. NSG проверяет валидность STA-тикета у SF.
  3. SF подтверждает валидность STA-тикета.
  4. NSG подключается к XA/XD серверу на котором запускается Windows приложение.
  5. Картинка от Windows приложения передается на мобильное устройство.

Подробности по конкретным настройкам можно посмотреть тут: /blogs/2014/01/17/xenmobile-enable-hdx-apps-with-certificate-based-authentication/

Применимо для Citrix XenMobile Enterprise 8.6.