Не знаю, как реализовать работу с membership в приложение. Не, аутентификацию-то использую, с ролями работаю, пятое десятое.

Непонятно другое. Например - пользователь забил в систему товар. В товаре, в поле author хранится ProvideUserKey пользователя. И вот теперь вопросы:
1. Завтра мы удалили пользователя - что отображать в поле author? "Пользователя не существует"? А как же хранение истории?
2. Чтобы можно было упорядочивать список товаров, необходима связывание с MembershipUser. Как это реализовать, если в проекте используется ORM? Генерить POCO классы для Membership?
3. Хранение доп. атрибутов пользователя - телефон, номер карточки и т.д. Где хранитЬ, чтобы можно было фильтровать товары(например) по этим данным? Profile не пойдет, придется заводить новую сущность userData?

Может быть, вообще отвязать пользователей приложения, от польователей membership? Сделать как в Sharepoint - есть объект Person, в котором хранится вся информация о пользователе. И к нему привязывается MembershipUser, исключительно для аутентификации. Какие плюсы и минусы у такого решения?

МСУ0. Если корпоративное приложение, зачем нужна forms authentication? Насилуй контроллер домена, это удобно и безопасно.
1. Пользователей удалять нельзя, только блокировать.
2. В случае forms authentication - можешь сделать референс из бизнес таблиц на ProvideUserKey. Не совсем хорошо, но получаем плюшки для автогенерации энтити. В случае windows authentication - создаем отдельную таблицу юзеров из AD (завязка на сиды) и ставим на периодическую синхронизацию. Эту таблицу уже честно референсим из бизнес таблиц без каких-либо проблем. Определить маппинг текущего юзера на табличного - через UserPrincipal.Current.Sid.
3. В случае forms authentication - профиль. Почему он не пойдет? Профиль поддерживает работу со и сложными типами, это ж банальная сериализация. В случае windows authentication - в той самой табличке (ну и многое есть в самом AD).

P.S. Для forms authentication можешь глянуть на новомодный SimpleMembership .
0. Не всегда можно/нужно использовать доменную аутентификацию.
1. Был у нас мендежер Вася Пупкин. Уволился, и пришел к нам его полный тезка - зам. директора Вася Пупкин. Создавать для него новую учетку?
2 и 3. В том-то и дело. Если связать бизнес-таблицы по ProviderUserKey, как осуществлять фильтрации в ORM по атрибутам пользователя? Причем фильтрации на стороне СУБД.

Вообще, вся загвоздка в том, чтобы вкрутить Membership в ORM-модель. На direct SQL все эти джойны на юзеров, на роли делаются очень просто, и скорость запросов не страдает. Если же в ORM заводить non-persistent, то сильно просаживается производительность.

МСУ1. Да.
2-3. Вот так: http://codearticles.ru/home/articleview/469

1. Кривовато, как по мне. Пользователь с логином vpupkin2, "потому что у нас уже был такой".
2-3. То бишь писать sql-запросы? С Linq прощаемся?

МСУ1. Не "кривовато", а единственно верно и правильно. Как ты себе представляешь ситуацию, если придет новый сотрудник и сисадмин выдаст ему "старую" учетку его тезки? Мне даже стрёмно читать твой бред, которой ты пишешь.
2-3. Linq2SQL перестал работать в SQL функциями? Уважаемый, подучи матчасть.


1. Я и предполагаю вариант решения:
авторМожет быть, вообще отвязать пользователей приложения, от польователей membership? Сделать как в Sharepoint - есть объект Person, в котором хранится вся информация о пользователе. И к нему привязывается MembershipUser, исключительно для аутентификации
2-3. С LinqToSQL не работал. А оно поддерживает MySQL, Postgre, Oracle?

МСУА чего тогда про "Linq" речь завёл?
Оно - это что?
Я пишу linq запросы к orm-объектам. Чем отличается LinqToSQL, можно ли в обычном linq использовать sql-функции, работает ли LinqToSQL с СУБД, отличными от MS SQL?

МСУполучаем плюшки для автогенерации энтити
Можно поподробней? Какие "плюшки для автогенерации энтити" мы получим, добавив в бизнес-классы поле ProviderUserKey?

МСУ,

Спасибо за ответы, пойду читать доки)