Лучший способ хранения междоменных учетных данных для доступа к веб-сервисам? - PullRequest
6 голосов
/ 23 февраля 2011

Я работаю над приложением, которое подключается к различным удаленным серверам с помощью веб-службы для получения некоторой информации о состоянии этих (Windows) компьютеров.

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

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

Я ожидаю, что это приложение будет в основном установлено в одной из операционных систем Windows Server - 2003 или 2008 - если это будет иметь какое-либо значение для того, что доступно.

Ответы [ 2 ]

4 голосов
/ 03 марта 2011

Предлагаю вам взглянуть на " Windows Identity Foundation ". Это может быть излишним для вас, или предварительное условие может не совпадать, но в любом случае его стоит прочитать, поскольку оно очень поучительно с точки зрения архитектуры на основе утверждений с технологией Microsoft.

Два основных документа для разработчиков:

3 голосов
/ 04 марта 2011

Я предполагаю, что речь не идет о Silverlight или Flash-приложении, в них есть некоторые особые вещи ...

Я использовал систему аутентификации Федерацией финансовых служб Финляндии (используется всеми крупными финскими банками).).Это выглядит так:

У вашего клиента и сервера есть секретный ключ (или 2 ключа).

Вы можете сохранить его, например, в произвольном месте в реестре Windows (что очень просто для .NET и вы можете контролировать доступ к реестру).Не кодируйте ключ кода жестко, потому что в противном случае кто-то может использовать отражение для его получения.Кроме того, пользовательский xml-файл в папке может быть опасным, если платформа недостаточно безопасна.

Затем у нас есть запрос, скажем, URL-адрес WebService REST, и есть некоторый идентификатор:

http://myserver/MyItems/15

Теперь нам нужно использовать метку времени и однонаправленный хэш-алгоритм.Есть много доступных, таких как md5, SHA1, SHA512, ... (также встроенных в библиотеку Microsoft .NET).Мы вычисляем хеш-значение по идентификатору и метке времени (и, возможно, некоторым другим параметрам).

Для упрощения эти алгоритмы работают подобно модулю-алгоритму: допустим, мой идентификатор равен 11, секретный ключ равен 3, затем по модулю 11% 3 = 2, теперь хэш будет равен 2, и если вы знаете id (11) и hash (2), вы не сможете получить секретный ключ.

Реальный запрос будетбыть таким:

http://myserver/MyItems/15?timestamp=20110304171900&hash=89A234BA645FD56

Служба проверит хэш.Если у некоторых хакеров будет достаточно времени, они смогут угадать действительные запросы.Но служба также проверит, если отметка времени в порядке, например, между 5 минут назад и 5 минут в будущем.Поэтому вы не можете настроить запрос, потому что он изменил бы хеш.

И, конечно, еще одна вещь - это использование протокола SSL.В противном случае ваши запросы могут быть прочитаны со случайного прокси-сервера.

Я бы также порекомендовал Windows Identity Foundation, но это еще один вариант.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...