Для простого HTTP-сервиса, который принимает команды через GET (вы должны рассмотреть возможность использования POST ...), я бы использовал прямой ASP MVC, а не настоящий
'веб-сервис'. WCF хочет направить вас по пути SOAP, и ваши клиенты будут проклинать вас вечно. RESTful WCF также является альтернативой, но это все равно кажется излишним imho.
Что касается аутентификации, у вас есть две жизнеспособные схемы аутентификации:
- Встроенная защита Windows, которая будет работать только в том случае, если клиент находится внутри внутренней сети или подключен с помощью решения VPN или DirectAccess
- Дайджест HTTP, который плохо поддерживается режимами аутентификации ASP (поддерживается только аутентификация на базе пользователей леса Active Directory).
При аутентификации Windows вы ничего не делаете с кодом на стороне сервера, просто отметьте web.config <authentication mode="Windows" />
. Проверка подлинности «Windows» понимается большинством пользовательских агентов. Также достаточно просто запрограммировать клиенты вашей службы на использование аутентификации Windows, просто установите Credentials запроса для текущего пользователя DefaultCredentials .
При дайджест-аутентификации сервер будет запрашивать аутентификацию у пользовательского агента, но, к сожалению, проверка ASP, как я уже сказал, работает только для проверки доверенного домена NT. Однако клиенту не обязательно находиться во внутренней сети (нет обмена NTSP SSPI между клиентом и сервером). Программирование клиента очень просто, в .Net просто установите реквизиты реквизитов на правильно инициализированный CredentialsCache :
CredentialCache myCache = new CredentialCache();
myCache.Add(new Uri("http://www.contoso.com/"),"Digest", new NetworkCredential(UserName,SecurelyStoredPassword,Domain));
...
request.PreAuthenticate = true;
request.Credentials = myCache;
Важно повторно использовать кэш между запросами, в противном случае клиент будет совершать два обхода с каждым вызовом.
Теоретически у вас также может быть третий путь аутентификации: полнодуплексный SSL. Но «тривиальная» проблема развертывания клиентских сертификатов делает эту альтернативу тупиком для тех, кому не хватает полностью предустановленной корпоративной PKI.