идентификатор asp.net с контроллером домена

Question

Мне нужно добиться аутентификации пользователей своим доменным пользователем/паролем, если они находятся в контроллере домена, но приложение должно быть доступно и для других пользователей, которые должны быть аутентифицированы с их собственным именем пользователя/паролем; это должно быть сохранено в базе данных приложения и их имя пользователя/пароль для проверки на БД.

До сих пор я начал с нового шаблона asp.net в vs2015, выбрав Индивидуальные учетные записи пользователей. Я могу проверить подлинность пользователей контроллера домена снова, но если это удалось, я не могу сохранить пользователя в свойстве HttpContext.User.

В SignInManager я вызываю PasswordSignIn и возвращаю Success или Failure в зависимости от проверки AD.

public SignInStatus PasswordSignIn(string userName, string password, bool isPersistent, bool shouldLockout) { 
    if(AuthenticateAD(userName, password)) { 
// 
// to create identity/principal and assign to HttpContext.User 
// 
    return SignInStatus.Success; 
    } 
    else { 
    return SignInStatus.Failure; 
    } 
} 

public bool AuthenticateAD(string username, string password) { 
    using(var context = new PrincipalContext(ContextType.Domain, "domainname")) { 
    return context.ValidateCredentials(username, password); 
    } 
} 

благодарит за заметку!

Answer 1

Единственный способ, которым это действительно работает, - создать пользователей прокси в приложении для пользователей в AD. По сути, вы просто настроили скрипт, который заполняет новых пользователей/обновляет существующих пользователей на основе данных в AD по расписанию (в ночное время и т. Д., Исходя из ваших потребностей). Затем вы имеете дело только с одним пользователем, независимо от того, являются ли они частью домена или внешним. Единственное изменение, которое вам нужно сделать, это выборочная аутентификация через AD или стандартная аутентификация пароля. В любом случае, один и тот же пользовательский принцип находится в игре.

Answer 2

Вы можете использовать ADFS и разрешать пользователям выбирать, где аутентифицироваться. При использовании шаблона по умолчанию достаточно тривиально. Как и обычные механизмы входа в систему с помощью входа в систему через Google и локальную учетную запись.

Я думаю, что это самый правильный способ сделать что-то, потому что пользователи домена могут оказаться в Kerberos/Ntlm, если они захотят, и это снижает сложность вашей системы.

Вот пример WS-Fed: Using Claims in your Web App is Easier with the new OWIN Security Components

Для других вещей вы можете создавать приложения с шаблоном по умолчанию. Это приложение будет иметь внешний материал аутентификации в качестве примера.