Товарищ рассматривал одну систему, которая умеет делать аутентификацию на LDAP. У него сложилось впечатление, что кроме прочего она должна уметь хранить свои роли в этом LDAP. Товарищ мотивирует тем, что он-де участвовал в разработке системы, которая это умела, и что в этом ничего сложного нет. А для меня тут нет ничего неожиданного – для меня это как раз понятно: что позволено в точечной разработке, то не позволено в коробочном продукте (Quod licet Jovi, nоn licet bovi). Для меня лично дело вот в чём:
Условно рассмотрим пример, что у нас есть одна служба каталогов и пять разных независимых приложений от разных поставщиков, которые могут с ним связываться. Дополнительно мы всегда можем установить ещё несколько.
Если мы допускаем хранение ролей в каталоге – значит приложение должно получать доступ к данным каталога на запись, а не “только для чтения”.
Отсюда следует, что:
- Требуется какое-то соглашение об именованиях или расположение данных таким образом, чтобы приложения не путали свои личные данные и чужие. Это всё равно что два разных приложения пускать в одну базу данных – требуется как минимум настраиваемое соглашение о префиксах таблиц.
- Требуется тонкая настройка полномочий для устойчивости системы безопасности – чтобы одни приложения не могли читать данные других приложений. Зная ленивость обслуживающего персонала можно предположить, что в таком случае никто не будет заморачиваться на тонкую настройку – и будет полный доступ, со всеми вытекающими проблемами.
- Требуется доверие к чистоплотности (я уж не говорю о пряморукости) разработчиков *всех* приложений, ибо в таком каталоге данные хранятся очень серьёзные.
- Так как разные приложения могут жить на разных этапах жизни и в разных ландшафтах, то поддержка сложного ландшафта (например: тест+продуктив) становится более проблематичной.
- Условный главный владелец каталога (AD, LDAPAdmin, etc) – не понимает, что за данные в у него находятся и не может оценить их корректность. Он и не рискнёт их изменить, так как в результате в любом приложении может быть достигнут непредсказуемый результат. Ролевые данные очень часто связаны с НСИ, но грузить НСИ в каталог – надеюсь, что такое в голову никому не придёт.
- Структура данных может быть не сильно приспособлена для специфики LDAP – например, плоские табличные данные с составным ключом. Хранить-то можно, просто не удобно.
- Большой объём ролевых данных ставит нам вилку: или часто обращаться к каталогу (получаем проблемы производительности на каждом чихе) или обращаться к каталогу только при входе (получаем необходимость повторного входа для применения изменений в роли).
- И главное – если большое приложение и так имеет своё оперативное хранилище рядом, то какой смысл хранить ролевые данные далеко, в системе с другим уровнем доверия и контроля?
- …
Приходим к выводу:
Найти точку устойчивости в общем случае невозможно или сильно проблематично. Для частной заказной разработки – ещё применимо (хотя и спорно), но для коробочного продукта – идеологически и технологически вредно, даже в опциональном качестве.
Следовательно:
- Ролевые данные следует всегда хранить в базе данных приложения.
- Коробочный продукт получает доступ к каталогу только в режиме чтения.
- Каталог должен содержать только:
- аутентификационные, именные, адресные и прочие данные, не зависящие от приложений
- принадлежность к строго определённым общим группам (реакция приложений может быть настроена)
- Доступ на запись есть только у одного приложения – главного владельца. В крайнем случае – для нескольких очень тесно интегрированных продуктов одного поставщика.
ЗЫ. В Windows 2008 Server есть занятная роль – AD LDS…