Опубликован: 04.07.2008 | Доступ: свободный | Студентов: 628 / 31 | Оценка: 4.83 / 5.00 | Длительность: 42:11:00
Лекция 7:

Принцип единого входа (Single sign-on)

Аннотация: В этой лекции мы обсудим основные понятия принципа единого входа [single signon (SSO)] и технические методы, которые мы можем использовать для содействия внедрению этого принципа. Собственно говоря, принцип единого входа является термином для описания практики работы конечного пользователя, а не технической реализации

Начнем с представления более строгого определения SSO:

"Механизм, с помощью которого единственное действие по аутентификации и авторизации пользователя может разрешить ему доступ ко всем компьютерам и системам, к которым этот пользователь имеет разрешение на доступ, без необходимости ввода множества паролей".

Это определение взято с Web-сайта компании The Open Group по адресу:

http://www.opengroup.org/

Ключевым моментом здесь является то, что пользователю требуется войти в систему (пройти аутентификацию) для подключения к приложению только один раз, причем в контексте этой же сессии нет необходимости проходить аутентификацию повторно при доступе к другому приложению или серверу.

Этот подход предполагает появление определенного количества важных преимуществ, но имеет также и некоторые недостатки. Преимуществами для конечных пользователей являются следующие положения:

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

Преимущества для администраторов безопасности включают:

  • Запись регистрационных данных пользователя в одном месте для управления и обеспечения безопасности.
  • Возможность ведения общих для организации политик паролирования и обеспечения безопасности, позволяющих обеспечить "сквозную" безопасность, возможно в рамках приложений и систем. Это позволит избежать проблем с несоответствием требований по сложности паролей и периодам их смены в различных системах.
  • Проще контролировать информацию о правах доступа пользователя (user security information) и при необходимости корректировать ее, чем при отслеживании всех отдельных систем, к которым имеет доступ пользователь. Это особенно важно, когда пользователям назначают роли с другими уровнями доступа.

Потенциальные недостатки SSO:

  • попытка первоначальной реализации может быть сложной, в зависимости от количества существующих несопоставимых систем;
  • скомпромитированные входные данные (credentials) пользователя могут привести к доступу к большому числу приложений;
  • производитель либо не использует существующий открытый стандарт, либо использует стандарты, несовместимые со стандартами, используемыми другими приложениями.

Сложность обеспечения SSO связана с функционированием в средах с независимыми архитектурами безопасности, директориями и т. д. для каждой из существующих платформ приложений. Для поддержки SSO нам необходимо заставить все наши приложения использовать общую инфрастуктуру безопасности для сквозной аутентификации между приложениями. Это требует некоторого общего формата для представления аутентификационной информации и параметров доступа пользователя ( credentials ), которые могут понять и правильно обработать ( accept ) все приложения. Также нам нужно иметь возможность проверить достоверность параметров доступа пользователя ( credentials )

C технической точки зрения существует несколько различных методов, или инструментов, которые могут быть использованы, чтобы обеспечить пользователям возможность использования SSO в приложениях, написанных под WebSphere и Lotus. В этой лекции описаны методы обеспечения SSO, которые поддерживают программные продукты компании IBM:

  • заголовки HTTP (HTTP headers);
  • Lightweight Third Party Authentication (LTPA);
  • сертификаты X.509;
  • DSAPI.

7.1 Методы SSO

Все методы SSO должны быть направлены на решение трех проблем:

  1. Аутентификация пользователя.
  2. Установление соответствующих уровней доступа к приложениям на основе идентификационных данных пользователя.
  3. Перевод удостоверения личности (users credentials) пользователя в формат, узнаваемый другими приложениями.

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

7.1.1 Единый пароль или SSO

Обратите внимание на то, что мы проводим различие между понятием SSO и понятием "единого пароля", которое фундаментально отличается от SSO. Единый пароль подразумевает наличие одинакового ID пользователя и пароля [мандата ( credentials )], хранящихся во множестве мест для использования различными приложениями. При таком сценарии у пользователей запрашивалась бы аутентификация для каждого приложения (или сервера), к которым они осуществляют доступ, несмотря на то, что теоретически они бы использовали для этого одни и те же ID и пароль.

Чтобы иметь единый пароль несмотря на то, что каждое приложение использует специализированное хранилище для ID и пароля ( credentials store ), идентификаторы ( ID ) пользователей и пароли должны быть каким-то образом синхронизированы. Так как же можно синхронизировать пароли в различных хранилищах (каталогах)? Самый простой ответ, это пользователи могут вручную поддерживать идентичность своих logon-имен и паролей для различных систем, если у них есть на это соответствующие полномочия. Конечно, это без сомнения, самый недружелюбный к пользователю подход, потому что нагрузка в этом случае полностью ложится на него. Могут ли пароли быть синхронизированы программно? В некоторых случаях могут, хотя на самом деле процесс синхронизации представляет из себя одновременную смену паролей.

Одновременные изменения паролей

Большинство процессов "синхронизации" паролей технически являются процессом одновременного изменения паролей, происходящим в фоновом режиме. К примеру, если вы разрешили синхронизацию паролей Notes и Windows, то при изменении вами своего пароля в Notes введенный новый пароль временно сохраняется в буфере, после чего автоматически передается процессу изменения пароля Windows в фоновом режиме. Процесс очень похож на процесс синхронизации пароля Notes и Domino интернет-паролей. Одновременное изменение эффективно там, где вам необходимо набрать пароль только один раз, и он автоматически будет передан второй парольной системе.

Синхронизация паролей

С точки зрения обеспечения безопасности, возможность синхронизации значения пароля из хранилища, непременно связано с возникновением очень нежелательных слабых мест в системе безопасности. Слабым местом в этом случае была бы возможность извлечения версии пароля пользователя в виде открытого текста для того, чтобы его можно было записать в другой каталог. Безопасные хранилища входных данных не хранят пароль в виде открытого текста, скорее они хранят хеш или зашифрованную версию пароля. Алгоритм хеширования не должен быть реверсивным. Так, чтобы у нас не было возможности прочитать из каталога значение хеша и конвертировать его в текст. А если мы просто перепишем хешированый пароль из одного каталога в другой, то второй каталог будет иметь "хеш"-значение пароля, которое не сможет быть воспроизведено в исходный пароль, и поэтому никогда не пройдет процесс аутентификации или "связывания" ( "bind" ).

Примечание. Domino генерирует MD2-solted хеш при сохранении интернет-пароля в документе Person, если в профиле каталога (Directory Profile) разрешена опция "Use more secure Internet Passwords" ("Использовать более безопасные интернет-пароли"). Другие каталоги могут применять другие алгоритмы хеширования (к примеру, IBM Tivoli Directory Server использует MD5). Также они будут использовать другие ключи шифрования, длины ключей и salt -значения. Значения хеш для одного и того же пароля в разных каталогах будут различными (и разных записей пользователя в том же каталоге, если они используют salted хеш). Значение(величина) хеш не подразумевает переносимости

Если каталог предусматривает доступ администратора или программы для получения пароля в виде открытого текста, это не является безопасным.