Про LDAP

Товарищ рассматривал одну систему, которая умеет делать аутентификацию на LDAP. У него сложилось впечатление, что кроме прочего она должна уметь хранить свои роли в этом LDAP. Товарищ мотивирует тем, что он-де участвовал в разработке системы, которая это умела, и что в этом ничего сложного нет. А для меня тут нет ничего неожиданного – для меня это как раз понятно: что позволено в точечной разработке, то не позволено в коробочном продукте (Quod licet Jovi, nоn licet bovi).  Для меня лично дело вот в чём:

 

Условно рассмотрим пример, что у нас есть одна служба каталогов и пять разных независимых приложений от разных поставщиков, которые могут с ним связываться. Дополнительно мы всегда можем установить ещё несколько.

Если мы допускаем хранение ролей в каталоге – значит приложение должно получать доступ к данным каталога на запись, а не “только для чтения”. 

Отсюда следует, что:

  • Требуется какое-то соглашение об именованиях или расположение данных таким образом, чтобы приложения не путали свои личные данные и чужие. Это всё равно что два разных приложения пускать в одну базу данных – требуется как минимум настраиваемое соглашение о префиксах таблиц.
  • Требуется тонкая настройка полномочий для устойчивости системы безопасности – чтобы одни приложения не могли читать данные других приложений. Зная ленивость обслуживающего персонала можно предположить, что в таком случае никто не будет заморачиваться на тонкую настройку – и будет полный доступ, со всеми вытекающими проблемами.
  • Требуется доверие к чистоплотности (я уж не говорю о пряморукости) разработчиков *всех* приложений, ибо в таком каталоге данные хранятся очень серьёзные.
  • Так как разные приложения могут жить на разных этапах жизни и в разных ландшафтах, то поддержка сложного ландшафта (например: тест+продуктив) становится более проблематичной. 
  • Условный главный владелец каталога (AD, LDAPAdmin, etc) – не понимает, что за данные в у него находятся и не может оценить их корректность. Он и не рискнёт их изменить, так как в результате в любом приложении может быть достигнут непредсказуемый результат. Ролевые данные очень часто связаны с НСИ, но грузить НСИ в каталог – надеюсь, что такое в голову никому не придёт.
  • Структура данных может быть не сильно приспособлена для специфики LDAP – например, плоские табличные данные с составным ключом. Хранить-то можно, просто не удобно.
  • Большой объём ролевых данных ставит нам вилку: или часто обращаться к каталогу (получаем проблемы производительности на каждом чихе) или обращаться к каталогу только при входе (получаем необходимость повторного входа для применения изменений в роли).
  • И главное – если большое приложение и так имеет своё оперативное хранилище рядом, то какой смысл хранить ролевые данные далеко, в системе с другим уровнем доверия и контроля?

 

Приходим к выводу:

Найти точку устойчивости в общем случае невозможно или сильно проблематично. Для частной заказной разработки – ещё применимо (хотя и спорно), но для коробочного продукта – идеологически и технологически вредно, даже в опциональном качестве.

Следовательно:

  • Ролевые данные следует всегда хранить в базе данных приложения.
  • Коробочный продукт получает доступ к каталогу только в режиме чтения.
  • Каталог должен содержать только:
    • аутентификационные, именные, адресные и прочие данные, не зависящие от приложений
    • принадлежность к строго определённым общим группам (реакция приложений может быть настроена)
  • Доступ на запись есть только у одного приложения – главного владельца. В крайнем случае – для нескольких очень тесно интегрированных продуктов одного поставщика.

 

ЗЫ. В Windows 2008 Server есть занятная роль – AD LDS…

Добавить комментарий

Ваш e-mail не будет опубликован.