Доделитесь, пожалуйста, информацией по реализации аутентификации и авторизации
на базе LDAP. Интересуют концептуальные моменты: вся ли логика по созданию пользователей и их групп перемещается в LDAP или же какая-то часть остается в приложении? Если все в LDAP, то каким образом реализуется обратная связь между LDAP? (например, когда новая группа в LDAP должна появится после появления новых "данных" в системе — пример — новый территориальный регион). Что делать в ситуации, когда число групп и их разновидностей становится большим и их управление через стандартную management console (в случае AD) становится неудобным — писать свой add-in?

От Заказчика удается пока что заполучить поток сознания о том, что
"хочется централизации".

Здравствуйте, sergunok, Вы писали:

S>Доделитесь, пожалуйста, информацией по реализации аутентификации и авторизации
S>на базе LDAP. Интересуют концептуальные моменты: вся ли логика по созданию пользователей и их групп перемещается в LDAP или же какая-то часть остается в приложении? Если все в LDAP, то каким образом реализуется обратная связь между LDAP? (например, когда новая группа в LDAP должна появится после появления новых "данных" в системе — пример — новый территориальный регион). Что делать в ситуации, когда число групп и их разновидностей становится большим и их управление через стандартную management console (в случае AD) становится неудобным — писать свой add-in?

S>От Заказчика удается пока что заполучить поток сознания о том, что
S>"хочется централизации".

В MS Shrepoint есть интеграция с AD, но группы там используются свои.

G>В MS Shrepoint есть интеграция с AD, но группы там используются свои.
Ну и зря.
Индус с китайцем не договорился.

Здравствуйте, VGn, Вы писали:

G>>В MS Shrepoint есть интеграция с AD, но группы там используются свои.
VGn>Ну и зря.
VGn>Индус с китайцем не договорился.
Совешенно не зря.
Зачем в SP Administrators, Power Users, Backup Operators и прочие группы?

Кроме того группы ползователей в SP локальны для сайта.

G>Совешенно не зря.
G>Зачем в SP Administrators, Power Users, Backup Operators и прочие группы?
G>Кроме того группы ползователей в SP локальны для сайта.

Это вопрос реализации.
SP — корпоративный портал. Разграничение прав — вопрос безопасности.
Почему вопросы безопасности не могут управляться из одной точки?
Почему информация безопасности не может находиться в одном хранилище?

Здравствуйте, sergunok, Вы писали:

[skipped]
Рекомендую не изобретать велосипеды.
Эта тема называется управлением идентификациями (identity management), серьезная, перспективная и относительно неплохо проработана к данному моменту крупными вендорами. Смотрите реализации:

• Microsoft Identity Integration Server (MIIS).
  
• SUN Identity Manager.
  
• IBM Tivoli Identity Manager.
  
• Oracle Identity Manager (OIM, Xellerate Identity provisioning).

На основе одной из этих систем в одном из телекомов (пардон, NDA таки подписан) мы (соседний проект, на который меня изредка аутсорсят) внедряем сейчас централизованную систему управления идентификациями. Функционал можно описать банальным примером: при найме нового сотрудника в административной консоли OIM его наделяют соответствующими его должности полномочиями, автоматически происходит создание идентификаций с соответствующими привилегиями во всех системах, которые необходимы для выполнения его должностных обязанностей. Пределов никаких практически, сейчас в работе контроллеры доменов на основе Active Directiry и Sun Directory Server, почтовые сервера Exchange и postfix, а также всевозможные legacy-системы — и все это пляшет под одну дудку. Счастье админов.

Здравствуйте, rsn81, Вы писали:

R>Здравствуйте, sergunok, Вы писали:

R>[skipped]
R>Рекомендую не изобретать велосипеды.
R>Эта тема называется управлением идентификациями (identity management), серьезная, перспективная и относительно неплохо проработана к данному моменту крупными вендорами. Смотрите реализации:

• Microsoft Identity Integration Server (MIIS).
  R>
• SUN Identity Manager.
  R>
• IBM Tivoli Identity Manager.
  R>
• Oracle Identity Manager (OIM, Xellerate Identity provisioning).

На основе одной из этих систем в одном из телекомов (пардон, NDA таки подписан) мы (соседний проект, на который меня изредка аутсорсят) внедряем сейчас централизованную систему управления идентификациями. Функционал можно описать банальным примером: при найме нового сотрудника в административной консоли OIM его наделяют соответствующими его должности полномочиями, автоматически происходит создание идентификаций с соответствующими привилегиями во всех системах, которые необходимы для выполнения его должностных обязанностей. Пределов никаких практически, сейчас в работе контроллеры доменов на основе Active Directiry и Sun Directory Server, почтовые сервера Exchange и postfix, а также всевозможные legacy-системы — и все это пляшет под одну дудку. Счастье админов.

немного мимо кассы.
Речь идет не о identity management, а об авторизации в конкретном приложении при наличии централизованного identity management.

Здравствуйте, gandjustas, Вы писали:

G>немного мимо кассы.
G>Речь идет не о identity management,
По-моему, как раз о нем и речь.

G>а об авторизации в конкретном приложении при наличии централизованного identity management.
Аутентифицироваться из одного домена безопасности в другом, которые не связаны или о чем? Если на этот раз угадал, тогда поможет Single Sign-On (технология единого логина, сквозной аутентфиикации), есть также от множества вендоров: Microsoft, IBM, Citrix и т.п. — кстати, в MOSS, который вы выше обсуждали также есть SSO.

Здравствуйте, rsn81, Вы писали:

R>Здравствуйте, gandjustas, Вы писали:

G>>немного мимо кассы.
G>>Речь идет не о identity management,
R> По-моему, как раз о нем и речь.

G>>а об авторизации в конкретном приложении при наличии централизованного identity management.
R>Аутентифицироваться из одного домена безопасности в другом, которые не связаны или о чем? Если на этот раз угадал, тогда поможет Single Sign-On (технология единого логина, сквозной аутентфиикации), есть также от множества вендоров: Microsoft, IBM, Citrix и т.п. — кстати, в MOSS, который вы выше обсуждали также есть SSO.

Угу, вот у нас любой механиз сквозной аутентификации. Вошли мы на сайт SP — какими правами будем обладать? Где эти права задавать?
Имхо эти вопросы должны решаться в самом приложении, а не в службе LDAP или чем-то таком.

Здравствуйте, gandjustas, Вы писали:

G>Угу, вот у нас любой механиз сквозной аутентификации. Вошли мы на сайт SP — какими правами будем обладать? Где эти права задавать?
G>Имхо эти вопросы должны решаться в самом приложении, а не в службе LDAP или чем-то таком.
SSO — механизм скозной аутентификации, при котором достаточно помнить, к примеру, только одну свою идентификацию в контроллере домена, чтобы тебя узнал каждый сервис в доменной сети, чем этот процесс отличается от авторизации — знаете?

Здравствуйте, rsn81, Вы писали:

R>Здравствуйте, gandjustas, Вы писали:

G>>Угу, вот у нас любой механиз сквозной аутентификации. Вошли мы на сайт SP — какими правами будем обладать? Где эти права задавать?
G>>Имхо эти вопросы должны решаться в самом приложении, а не в службе LDAP или чем-то таком.
R>SSO — механизм скозной аутентификации, при котором достаточно помнить, к примеру, только одну свою идентификацию в контроллере домена, чтобы тебя узнал каждый сервис в доменной сети, чем этот процесс отличается от авторизации — знаете?
Отлично знаю, вот тем как раз об авторизации.

Здравствуйте, rsn81, Вы писали:

R>Здравствуйте, gandjustas, Вы писали:

G>>Угу, вот у нас любой механиз сквозной аутентификации. Вошли мы на сайт SP — какими правами будем обладать? Где эти права задавать?
G>>Имхо эти вопросы должны решаться в самом приложении, а не в службе LDAP или чем-то таком.
R>SSO — механизм скозной аутентификации, при котором достаточно помнить, к примеру, только одну свою идентификацию в контроллере домена, чтобы тебя узнал каждый сервис в доменной сети, чем этот процесс отличается от авторизации — знаете?
Ну а правила авторизации где хранятся? Вопрос об этом задавался. Мне вот тоже интересны плюсы и минусы обоих реализаций.

Здравствуйте, vb-develop, Вы писали:

VD>Ну а правила авторизации где хранятся? Вопрос об этом задавался. Мне вот тоже интересны плюсы и минусы обоих реализаций.

Правила авторизации (так называемые, профили приложений — куда подставлять логин-пароль) могут храниться на сервере.

Здравствуйте, Debussy, Вы писали:

D>Здравствуйте, vb-develop, Вы писали:

VD>>Ну а правила авторизации где хранятся? Вопрос об этом задавался. Мне вот тоже интересны плюсы и минусы обоих реализаций.

D>Правила авторизации (так называемые, профили приложений — куда подставлять логин-пароль) могут храниться на сервере.

Или я что-то не понял, или ответ немного не в тему.
Правила авторизации — то, что описывает какому пользователю из LDAP (или его роли пользователя, или группы, не принципиально) доступ к каким данным и действиям разрешен. Где хранится эта информация?

Здравствуйте, vb-develop, Вы писали:

VD>Ну а правила авторизации где хранятся? Вопрос об этом задавался. Мне вот тоже интересны плюсы и минусы обоих реализаций.

Правила авторизации естественно хранятся в приложении. Приложение просто проверяет отношение пользователя к определенной группе. Если нужна row-level security, то тут лучше не завязывать код на специальные группы, типа "Новый территориальный регион", а привязывать SID пользователя к данным в БД и делать проверки уже там.

G>Речь идет не о identity management, а об авторизации в конкретном приложении при наличии централизованного identity management.

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

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

VD>Или я что-то не понял, или ответ немного не в тему.
VD>Правила авторизации — то, что описывает какому пользователю из LDAP (или его роли пользователя, или группы, не принципиально) доступ к каким данным и действиям разрешен. Где хранится эта информация?

Да нет, просто я неправильно понял. Ну в таком случае, соглашусь с Ziaw

Здравствуйте, Ziaw, Вы писали:

Z>Здравствуйте, vb-develop, Вы писали:

VD>>Ну а правила авторизации где хранятся? Вопрос об этом задавался. Мне вот тоже интересны плюсы и минусы обоих реализаций.

Z>Правила авторизации естественно хранятся в приложении. Приложение просто проверяет отношение пользователя к определенной группе. Если нужна row-level security, то тут лучше не завязывать код на специальные группы, типа "Новый территориальный регион", а привязывать SID пользователя к данным в БД и делать проверки уже там.

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

G>В MS Shrepoint есть интеграция с AD, но группы там используются свои.
Чем такое решение лучше?
Есть ли какие-либо преимущества при использовании групп AD в Sharepoint, и т.д.

Здравствуйте, Debussy, Вы писали:

D>Другое дело, что стоит вопрос о более продвинутых инструментах для работы с LDAP-каталогами.
D>Меня тоже интересует идея использования LDAP для управления аккаунтами и правами, так как она выглядит естественней, чем IdM системы, с которыми приходилось сталкиваться.

Из того, что я видел в приложениях — есть несколько уровней интеграции:

• Базовый — LDAP используется исключительно для аутентификации, авторизацию приложение осуществляет самостоятельно. В данному случае управлять безопасностью придётся средствами, предоставленными самим приложением. Большая часть приложений, которые заявляют об "интеграции с AD", относятся к этой группе. Достоинством является предельная простота и быстрота добавления поддержки этой самой интеграции в имеющуюся подсистему безопасности приложения, хотя в целом выглядит как костыль. Недостатки, думаю, очевидны.
  
• Групповой — приложение создаёт и поддерживает в AD набор групп, по членству в которых приложение определяет разрешения. Само отношение "группа — разрешение" прошито в приложении, однако админы вольны комбинировать группы в другие группы и таким образом весьма гибко управлять доступом с помощью ADUC. К достоинствам данного подхода относится относительная простота подсистемы безопасности приложения — она по сути сводится к матчигну групп на разрешённые действия, а также простота управления безопасностью с помощью стандартного снап-ина. Недостаток — таким образом почти невозможно реализовать ACL-based безопасность — только RBC.
  
• "Глубокая интеграция" — расширяется схема AD, все объекты приложения хранятся (или дублируются, что я видел чаще, хотя смысл этого для меня неочевиден) в AD. Соответсвенно подсистема безопасности в приложении как таковая отсутствует — используется контекст безопасности пользователя, и все проверки доступа AD осуществляет самостоятельно. К достоинствам относится доступность всей мощи AD для админов, ACL-безопасность "изкаропки", к недостаткам — относительная сложность реализации и дополнительный гемор в развёртывании.

Какой из уровней использовать — сильно зависит от самого приложения, ибо у каждого имеются свои подводные камни...

Здравствуйте, vb-develop, Вы писали:

VD>Это уже ближе к теме.
VD>Но по-моему как раз о таком решении было сказано в начале темы "индус с китайцем не договорился". Мне же интересно услышать преимущества и недостатки обоих способов реализации, пусть и в теории. Категоричный ответ "делать так и никак иначе" это не совсем то, что я бы хотел услышать в качестве ответа на свой вопрос.

Да вроде понятно, если подумать. Row-level security означает, что пользователь имеет право доступа не ко всем данным, а к определенному срезу. Например по отделу. Чтобы знать к данным какого отдела имеет право обращаться пользователь надо привязать пользователя к отделу. Второй вариант — завести группу "Имеет право видеть данные отдела по снабжению", соответственно этих групп потребуется столько сколько отделов и код превратится в

if (user.MemberOf("Имеет право видеть данные отдела по снабжению"))
{
  sqlFilter += " OR DEPARTMENT = 1"
}

со всеми вытекающими.

G>>В MS Shrepoint есть интеграция с AD, но группы там используются свои.
VD>Чем такое решение лучше?

Понятия не имею, зачем нужны свои группы, возможно и правда "не договорились".