Как использовать аутентификацию Servicestack с помощью проверки подлинности Active Directory/Windows?

Я создаю безопасную (SSL) общедоступную службу, в которой учетные данные пользователей находятся в Active Directory. Я хочу использовать ServiceStack Authentication и прочитал статью wiki. У меня уже есть код для проверки учетных данных пользователя с AD. У меня есть несколько вопросов.

Какой провайдер Auth я использую? Учетные данные, Basic Auth или Custom? Служба требует SSL, поэтому Basic Auth будет безопасным, однако пароли будут зашифрованы для дополнительной безопасности.
Нужно ли мне сохранять UserAuth и кэшировать AuthUserSession?
Будет ли поддерживаться аутентификация клиента monotouch?

Обновление 2: я действительно создал тестовую службу SS, интегрированную с AD, используя CredentialsAuthProvider. Однако моя конечная цель - иметь 1 сайт, который является api при вызове клиентов. Таким образом, в основном сайт SS MVC.

Update:

Это мое понимание, сделав еще несколько исследований, которые SS рассматривает, делая коммерческий продукт, который может поддерживать аутентификацию Windows в будущем. Я прочитал это в комментарии от мифа на группу SS Google. Причина, по которой я задал этот вопрос, заключается в том, что моя компания строит внутренние приложения с использованием IWA, и использование SS MVC тяжело без IWA. Я думаю, что я прочитал, что вы можете разместить сайт SS MVC с сайта ASP.NET, который использует IWA, но я еще не пробовал это.

Ответ 1

Я также подключил ServiceStack со встроенной проверкой подлинности Windows (для корпоративного приложения), и ключевым моментом было пропустить попытку полностью интегрировать его с ServiceStack AuthProviders, поскольку общий подход IWA не касается учетных данных в вашем код приложения - он обрабатывается веб-сервером. Я сделал это:

Настройте сайт/приложение в IIS, чтобы разрешить только проверку подлинности Windows. (Анонимный доступ не разрешен.) Это означает, что сам IIS позаботится о последовательности запроса-ответа (HTTP 401/200) с неаутентифицированными пользователями и обработает часть аутентификации процесса для вас.
Внедрите ServiceStack IHasRequestFilter (фильтр предварительного запроса HTTP) в качестве атрибута (например, [AdminOnly]). Этот фильтр RequestFilter метод извлекает текущее имя пользователя из HttpContext (HttpContext.User.Identity.Name), ищет его из репозитория (который может быть базой данных SQL, плоским файлом и т.д.), Кэширует результаты, используя ServiceStack ICacheClient (кеш памяти, Redis, и т.д.) и выбрасывает 403 HttpError, если они не авторизованы.

При этом все, что было необходимо, - это добавить атрибут к классам или методам, где это необходимо (который получает эту аутентификацию/авторизацию в конвейере службы по желанию) и зарегистрировать мой желаемый поставщик кеша в моей реализации AppHost, например:

 container.Register<ICacheClient>(new MemoryCacheClient() { FlushOnDispose = false });

Он прекрасно работает.

Ответ 2

Вот что сказал Demis Bellot на twitter. Вероятно, возможно, но нужно больше исследований.

Не что-то, что я исследовал, не работает в Win/Active Справочник больше. Требуется некоторое количество R & D для поиска/устранения проблемы.

В конце концов я получил прототип сервиса, работающего с AD. Я применил CredentialsAuthProvider. Теперь это никак не связано с ASP.NET IWA, но легко проверяет, находится ли пользователь в AD. Надеюсь, это может помочь кому-то.

public class LDAPAuthProvider : CredentialsAuthProvider
{
    public override bool TryAuthenticate(IServiceBase authService, string userName, string password)
                    {
                        //Check to see if the username/password combo is valid, an exception will be thrown if the username or password is wrong
                        try
                        {
                            DirectoryEntry entry = new DirectoryEntry(ConfigurationManager.AppSettings["TargetOU"], userName, password);
                            object nativeObject = entry.NativeObject;
                        }
                        catch (Exception)
                        {
                            //This means the username/password combo failed
                            return false;
                        }

                        return true;
                    }
}