Как реализовать однократную аутентификацию (SSO) при доступе к приложениям

Рассмотрим задачу: обеспечить однократную аутентификацию пользователей в рамках предприятия.

Разберемся: в каких точках выполняется аутентификация пользователя.
Во-первых, это корпоративные приложения – почта, управление ресурсами, совместная работа, базы данных. Серверная часть приложения, размещаемая в ЦОД, запрашивает аутентификацию при установлении нового клиентского подключения.
Во-вторых, это сетевые устройства, контролирующие доступ:
— в точке включения в локальную сеть (коммутатор или точка беспроводного доступа);
— в точке взаимодействия с Интернет и другими смежными системами (устройства UTM, управляющие доступом в/из КСПД).
В-третьих, это собственно рабочая станция, где пользователь запускает приложения (при использовании технологии VDI можно в принципе исключить эту точку).

Далее будем рассматривать SSO при доступе к корпоративным приложениям.

Проблемой выступает зоопарк приложений. В контексте SSO на первый план выступают ограничения в части поддерживаемых приложениями механизмов аутентификации. Нередко приложения разработаны без учета требований SSO, используют собственные базы учетных записей, а также не предусматривают иных способов аутентификации пользователя, кроме как форма или окно для ввода идентификатора и пароля.

Что же требуется для обеспечения SSO? Каким требованиям должны удовлетворять приложения?
Серверная часть приложения должна использовать API операционной системы в процессе аутентификации клиента, – при этом ОС берет на себя реализацию необходимых механизмов и протоколов аутентификации. Альтернативой может быть реализация непосредственно в приложении механизмов и протоколов для проверки аутентификационных данных по центральной базе учетных записей.
Клиентская часть приложения должна использовать API операционной системы в процессе аутентификации, – при этом операционная система берет на себя реализацию необходимых механизмов и протоколов аутентификации, а также хранение (кэширование) необходимых данных учетной записи в течение сеанса пользователя. Альтернативой  может быть сохранение идентификатора и пароля (или производных значений) в кэше клиентской части.
Протокол взаимодействия между клиентской и серверной частью должен поддерживать внешние механизмы аутентификации. Иначе говоря, протокол должен позволять клиенту и серверу обмениваться «аутентификационными токенами», формируемыми с помощью API.
От операционной системы требуется реализовать соответствующий API и нижележащие механизмы и протоколы аутентификации.