У меня есть приложение ASP.NET MVC, в котором мне нужно разрешить клиентам настраивать MembershipProviders на основе их среды, но при этом иметь возможность сопоставлять это MembershipUser с конкретной моделью User в нашей базе данных.
Membership.GetUser()
даст мне доступ к зарегистрированному пользователю Membership.ProviderUserKey
. Я могу использовать это, чтобы относиться к записи пользователя. Наш пользовательский поставщик SQL просто вернет User.Id, но AD - это другая история. В этом случае ProviderUserKey
является IdentityReference
.
Эти поиски будут происходить очень часто, как вы можете себе представить (хотя кэширование может помочь уменьшить количество поисков на уровне базы данных).
Я не могу решить, какой маршрут лучше выбрать: сохранение SID в виде столбца varbinary или varchar. Этот столбец не будет первичным ключом и не будет иметь кластеризованного индекса. Знание того, что я могу очень хорошо индексировать строки, и чтение SID в строковом формате, конечно, лучше, чем двоичный. Кто-нибудь готов поделиться, как они решили такую ситуацию?
Обновление
Я не знаю, как я пропустил этот ТАК вопрос , когда я искал, прежде чем отправлять сообщения, но кажется довольно ясным, что ActiveDirectoryMembershipProvider
и ActiveDirectoryMembershipUser
не совсем подходят для задачи рука, как они существуют сегодня.
Ответ на этот вопрос SO связал следующую статью , где было указано следующее:
Относительная часть идентификатора
SID уникален по отношению к домену,
поэтому, если домен меняется, относительный
идентификатор также меняется.
Таким образом, когда объект User перемещается из одного
домен в другой, новый SID должен быть
генерируется для учетной записи пользователя и
хранится в свойстве Object-SID.
Однако у каждой группы и пользователя есть Object-GUID, который никогда не изменится, даже если учетная запись перемещена. Следовательно, мне следует использовать Object-GUID в моем классе User, а не Object-SID. В противном случае, чья-либо запись пользователя будет удалена, если он будет перемещен, и, следовательно, нарушит связь между его принципалом и данными, которые он создал.
К сожалению, ActiveDirectoryMembershipUser
не позволяет мне получить Object-GUID. Поэтому мне придется либо преобразовать SID в GUID после того, как ActiveDirectoryMembershipUser
выполнит свою работу, либо создать свой собственный MembershipProvider
, который будет делать все, что мне нужно на месте. К сожалению, это означает, что мне, возможно, придется дублировать уже предпринятые для меня усилия к ActiveDirectoryMembershipProvider
.