Сегодня веб-технологии прочно вошли в нашу жизнь. Все больше корпоративных приложений переходят на веб-интерфейс, особенно когда требуется доступ широкого круга сотрудников, в том числе за пределами корпоративной сети. Пользовательский интерфейс на веб уже принят де-факто как стандарт для разработки новых приложений. Развитие веб-технологий несомненно способствовало росту числа пользовательских сервисов, и не только внутрикорпоративных. Современный офисный сотрудник любой компании имеет в своем распоряжении не менее пяти бизнес-систем, принадлежащих как работодателю, так и партнерам или клиентам. Бизнес-коммуникации уже давно находятся в цифровой плоскости и взаимный доступ к корпоративным приложениям партнерских организаций сегодня не редкость. Можно привести множество подобных примеров. Это, в частности, доступ дилеров к ERP-системе производителя для оформления заказов, торговой документации и отслеживания поставок, или к CRM-системам, для работы с внешними агентами. Системы управления проектами с доступом подрядных организаций либо наоборот доступ клиентов к системе подрядчика по управлению проектными задачами. Причем контрагенты могут быть как независимыми организациями, так и аффилированными в рамках холдинга или корпорации.

Стикер на мониторе

Но бурная автоматизация корпоративных сервисов принесла не только безусловные преимущества, но и ряд проблем, требующих технологического решения. Ввиду конфиденциальности информации практически любой бизнес-сервис предполагает ограниченность использования, что обеспечивается механизмами аутентификации (проверка подлинности пользователя) и авторизации (предоставление доступа к функциям системы после аутентификации на основании полномочий пользователя). При этом, как правило, данные механизмы для разных приложений не интегрированы между собой. С точки зрения пользователя каждое приложение требует отдельного ввода логина и пароля, чтобы предоставить ему возможность работы. Если таких приложений около десятка, это становится проблемой, и сотрудник старается облегчить себе жизнь. Чтобы не забыть пароли, он записывает и хранит их в удобном месте для ежедневной работы. Чаще это стикер на мониторе или записка под клавиатурой. Еще один вариант упрощения —"слабый", легко запоминающийся пароль. Если система не требовательна к паролям, они обычно состоят из цифр, например дня рождения, или простого слова.

В обоих случаях техника взлома пароля через перебор быстро принесет результат. Однако если найти способ заставить пользователя запоминать и регулярно менять сложные пароли для разных систем, это однозначно не окажет положительного влияния на его производительность. Да и нагрузка на ИТ-службы по сбросу паролей резко возрастет. Другая проблема в рамках управления доступом пользователей к нескольким приложениям — несвоевременная блокировка всех учетных записей в случае увольнения сотрудника. Нередко блокируются учетные записи к основным системам, но могут остаться доступными учетные записи в других менее популярных, хотя не менее критичных системах. Особенно актуально это становится, когда системы построены на базе вет-технологий, с доступом к ним сторонних организаций за пределами корпоративной сети. Ведь информация об увольнении сотрудника внешней организации вряд ли оперативно дойдет до соответствующего ИТ-специалиста.

SSO-технологии

Решение подобных проблем стало возможным благодаря появлению SSO-технологий. Основной принцип SSO (SingleSign-On) заключается в однократной аутентификации пользователя. То есть, введя один раз логин и пароль, например при входе в компьютер или одну из систем, во все другие системы, куда пользователь имеет права доступа, он проходит «прозрачно» без ввода аутентифицирующей информации. Первые реализации данного подхода подразумевали достаточно простую технологию— перехват окон приложений после их запуска и автоматическая подстановка аутентифицирующих данных сотрудника, в частности, логина и пароля. Такая технология эмулировала действия пользователя, не заменяя логику аутентификации приложения. Причем пары логинов и паролей для разных приложений хранились в защищенном профиле пользователя, доступ к которому мог усиливаться дополнительной аутентификацией. Словом, чтобы усилить такую однократную аутентификацию, может дополнительно использоваться смарт-карта или USB-токен с пин-кодом. Фактически пароль заменяется фактором «то, что имею» — токен плюс фактор «то, что знаю» —пин-код. В качестве альтернативных методов аутентификации употребляется биометрия, например отпечаток пальца, или одноразовые пароли. Данная SSO-технология перехвата окон аутентификации активно применяется и в настоящее время. Но у такой «простой» технологии есть и свои недостатки. Для того чтобы перехватывать окна приложений и подставлять в них данные пользователя, необходимо наличие программного агента на компьютере пользователя. Это значительно ограничивает применение технологии при доступе к приложениям большого числа пользователей, в том числе за пределами корпоративной сети, особенно когда они не являются сотрудниками организации, владеющей системой. Вот почему соответствующие продукты принято называть «корпоративным SSO», подразумевая внутренний характер распространения данной системы, в основном для приложений с «толстым» клиентом.

Сервис IDP

Для обеспечения однократной аутентификации в веб-приложениях, особенно с доступом большого числа внешних пользователей, нужен другой механизм безагентского сервиса, объединяющий разнородные приложения с точки зрения управления доступом. Появлению таких продуктов способствовало принятие ряда открытых стандартов в области аутентификации и авторизации. Наиболее популярные из них —SAML 2.0 и OAUTH 2.0, в том числе OpenID Connect 1.0 как расширение стандарта OAUTH. Основная цель данных стандартов — поддерживать обмен между сайтами аутентифицирующей информацией для прозрачного входа санкционированных пользователей. Для организации такого обмена обычно предусмотрен внешний сервис, реализованный в виде продуктов различных производителей. Класс таких продуктов принято называть IDP (Identity Provider) или в более широком смысле — WebSSO. Логика работы данного класса продуктов схематично представлена на примере решения Avanpost WebSSO.

Когда пользователь обращается к веб-приложению, оно автоматически перенаправляет его на страницу аутентификации сервиса IDP (это возможно за счет интеграции приложения с IDP). Сервис IDP имеет свой каталог пользователей или интегрируется с существующим корпоративным каталогом, предназначенным для аутентификации пользователей. То есть сотрудник, с помощью своей общей корпоративной учетной записи, проходит аутентификацию на странице сервиса, затем перенаправляется назад на страницу приложения, а сервис IDP отдает приложению так называемый токен, содержащий информацию об успешном прохождении аутентификации и учетные данные пользователя. После этого приложение авторизует его в соответствии с полномочиями. Если пользователь уже проходил процедуру аутентификации, то согласно заданным настройкам сервис IDP хранит текущую сессию и при направлении пользователя приложением на сервис IDP повторно, отдает токен приложению без повторной аутентификации. При этом изначально сотрудник может быть направлен для аутентификации в IDP одним приложением, а впоследствии получить прозрачный доступ в другое. В этом и заключается принцип однократной аутентификации, организованный для веб-приложений на базе единого сервиса аутентификации (IDP) и стандартизованных протоколов (SAML, OpenID Connect).

Давайте рассмотрим, как принцип WebSSO действует для партнерских сетей, ведь в этом случае у нас есть совокупность организаций, в которых необходимо организовать взаимный доступ к приложениям друг друга. Первый вариант — организация общего IDP-сервиса, содержащего общий каталог пользователей, синхронизируемый с каталогами работников организаций. При таком варианте при обращении пользователей к приложениям, они будут перенаправляться на общий сервис аутентификации, который в свою очередь аутентифицирует пользователей в каталоге их организаций. Такой вариант наиболее приемлем для холдинговых структур, где на уровне головной организации можно «поднять» общий IDP-сервис. Если же предприятия не аффилированы между собой или совместно используют облачные приложения, самый подходящий вариант — организовать IDP-сервисы в каждой компании, куда для аутентификации будут перенаправляться пользователи. Описанные принципы называют федеративной аутентификацией, которую мы можем встречать и в нашей социальной жизни. Практически все популярные социальные сервисы используют данный подход для взаимной аутентификации, когда пользователь может войти в одну социальную сеть под аккаунтом другой.

Дополнительная защита

Еще один важный аспект однократной аутентификации в веб-приложениях, как и в случае с корпоративным SSO, — использование дополнительных факторов. Но если в корпоративной сети мы можем обеспечить компьютеры пользователей соответствующими устройствами и драйверами для снятия отпечатков пальцев или работы со смарт-картами и USB-токенами, то сам принцип доступности веб-приложений с любого компьютера, подключенного к Интернету, противоречит применению каких-либо дополнительных устройств или программного обеспечения. А потому наиболее популярное решение для усиленной аутентификации в WebSSO—технологии одноразовых паролей, или OTP (one time password). Сегодня даже в этой технологии есть несколько популярных направлений: генерация одноразового пароля по СМС, специальное мобильное приложение-генератор, а также более современная технология TOTP (Time-based One Time Password), реализованная, скажем, в приложении Google Authenticator.

***
В настоящее время технологии WebSSO востребованы многими организациями. Самая масштабная их реализация в России — аутентификация на сайте госуслуг. Ведь за общий страничкой сайта с однократной аутентификацией стоит множество не связанных между собой сервисов органов исполнительной власти. Но если в обывательском смысле мы уже ощутили преимущества доступа к множеству государственных сервисов под одной учетной записью, то корпоративный сегмент пока находится в начале пути. Но думаю, что бурное развитие там технологий WebSSO не заставит себя долго ждать.

Олег Губка, директор по развитию Аванпост