Безопасное решение для пароля для аутентификации веб-службы в Active Directory? - PullRequest
Новая
       18

Безопасное решение для пароля для аутентификации веб-службы в Active Directory?

1 голос
/ 08 апреля 2009

Приложение, которое я изменяю, имеет веб-службу, и один из веб-методов этого веб-метода используется для аутентификации пользователя по активному каталогу. Таким образом, текущий код, вызываемый веб-методом AuthenticateUser, выглядит примерно так: 

string domainAndUsername = aDomain + @"\\" + username;
string ldsPath = buildLdsPath(searchBase);
DirectoryEntry entry = new DirectoryEntry(ldsPath, domainAndUsername, 
    password);

try
{
    //Bind to the native AdsObject to force authentication.
    object obj = entry.NativeObject;

    DirectorySearcher search = new DirectorySearcher(entry);

    search.Filter = "(sAMAccountName=" + username + ")";
    search.PropertiesToLoad.Add("cn");
    SearchResult result = search.FindOne();

    // more code to validate the result, etc...
}

Когда я начал смотреть на этот код, первое, что меня беспокоило, - это аргументы веб-метода, выглядящие так: 

[WebMethod]
public ResultObj AddRole(string roleToAdd, string username, string password)
{
    // code that calls above Authentication fragment...
}

Таким образом, текущая веб-служба ожидает строку пароля, предположительно отправленную в открытом виде по сети в виде XML, когда выполняется запрос на страницу service.asmx.

Кто-нибудь имел дело с этим типом проблемы раньше? Существуют ли альтернативные механизмы аутентификации Active Directory, которые я мог бы использовать, чтобы избежать необходимости вводить простой текстовый пароль? Лучший вариант, который я мог бы придумать самостоятельно, - это вызвать WebMethod с использованием зашифрованного пароля, а другой код расшифровать его. Тем не менее, я бы предпочел лучшее решение - например: есть ли способ выполнить поиск по DirectoryEntry, используя односторонний хэш вместо пароля?

Изменить:

Дополнительные сведения: До этого момента я не рассматривал SSL, так как это инструмент, который является внутренним для нашей компании, поэтому он кажется избыточным и, возможно, проблематичным (он будет работать на компания интранет, а внешне не видна). Единственная причина, по которой меня беспокоит безопасность отправки простых текстовых паролей, заключается в том, что в наши дни даже в корпоративных сетях компании растет количество (возможно, обнаружение паролей) вредоносных программ.

Ответы [ 5 ]

4 голосов
/ 08 апреля 2009

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

Однако для клиента это слишком большая работа, и это не слишком "веб-метод".

Поскольку вы отправляете имя пользователя и пароль в качестве параметров, вам следует прибегнуть к транспортной безопасности, в основном к HTTPS, которая требует, чтобы вам выдавали комбинацию открытого и секретного ключей из доверенного центра сертификации.

Следует отметить, что ваша связь зашифрованного канала SSL с внешним сайтом неверна. Смысл зашифровки канала состоит в том, чтобы предотвратить атаки типа «человек посередине», точно так же, как вы пытаетесь это сделать здесь.

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

1 голос
/ 09 апреля 2009

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

В доменах Server 2000 есть опция «Хранить пароли в обратимом формате», которая позволит контроллеру домена вычислять хеши паролей MD5 для сравнения с представленным хешем MD5. MS поняла, что это была небольшая проблема безопасности, поэтому в Server 2003 была реализована «расширенная» дайджест-аутентификация, которая предварительно вычисляет хэш.

При входе в LDAP в качестве типа аутентификации следует выбрать MD5 Digest, указать имя пользователя и затем ввести MD5-хэш пароля. Обычные клиенты LDAP, вероятно, захотят сами использовать MD5 для вашего пароля, поэтому вам придется переопределить или создать их самостоятельно.

0 голосов
/ 09 апреля 2009

Для нашей конкретной ситуации, поскольку и клиент, и веб-служба работают в интрасети нашей компании, решение, которое может работать для нас, - это выполнить аутентификацию на стороне клиента с помощью встроенной аутентификации Windows NTLM, а затем просто клиент должен предоставить учетные данные для веб-службы. Вот код клиента: 

public void AddRole(string roleName)
{
    webSvc.Credentials = CredentialCache.DefaultCredentials;
    // Invoke the WebMethod
    webSvc.AddRole(roleName);
}

Веб-метод теперь будет выглядеть так: 

[WebMethod]
public ResultObj AddRole(string roleToAdd)
{
    IIdentity identity = Thread.CurrentPrincipal.Identity;
    if (!identity.IsAuthenticated)
    {
        throw new UnauthorizedAccessException(
                ConfigurationManager.AppSettings["NotAuthorizedErrorMsg"]);
    }
    // Remaining code to add role....
}

Опять же, должен подчеркнуть, что это решение, вероятно, будет работать только в том случае, если сервер доверяет клиенту и оба взаимодействуют с одним и тем же сервером Active Directory. Для общедоступных веб-сервисов один из приведенных ответов будет лучшим решением.

Для получения дополнительной информации см .:

0 голосов
/ 09 апреля 2009

Я думаю, что SSL, или, возможно, IPSec, вероятно, ваши лучшие решения.

0 голосов
/ 08 апреля 2009

Мы разместили нашу службу AD на своем веб-сайте и получили сертификат SSL. Проблема решена.

...