У меня есть приложение, которое использует Silverlight и ASP.NET в качестве интерфейсного. Он извлекает данные с сервера, вызывая некоторые службы RESTful WCF, размещенные там. Я бы хотел, чтобы любопытный пользователь открыл новое окно браузера и сам вызывал веб-сервис. Есть ли способ ограничить доступ к веб-сервисам к конкретному приложению?Как обеспечены службы RESTful WCF, чтобы только вызывающее приложение могло их называть?
Спасибо!
Нет, нет.
Короткие и сладкие. Благодаря! –
Он был бы закорочен, но есть минимум 15 символов * Улыбка * – blowdart
Я не согласен. Существует механизм для этой аутентификации. Как вы ограничиваете доступ к веб-приложению только некоторой части населения Земли? Войти в систему Reguire. То же самое касается услуг. Услуги WCF RESTful немного сложны, но есть способ. – Slavo
Если вы действительно заинтересованы в обеспечении безопасности своих веб-сервисов, вам следует подумать о переносе из служб RESTful на веб-службы на основе SOAP и внедрении стандарта WS-Security для шифрования на основе сообщений.
Затем вы можете защитить свои услуги, чтобы только ваши клиенты, имеющие правильную информацию о безопасности (быть в имени пользователя/пароле
или X.509 certs
), могут позвонить в ваши веб-службы.
Update
Как вы можете видеть ... Я удалил X.509 в качестве опции. Я на мгновение замолчал и забыл ограничения WS-Security в Silverlight. Хорошая новость заключается в том, что вы можете реализовать имя пользователя маркеры на основе стандарта WS-Security в Silverlight:
Implementing Username Password & WS-Security with Silverlight
Silverlight не поддерживает WS * – blowdart
Пила ASP.NET ... пропустил Silverlight. Существуют способы реализовать базовую защиту маркеров имени пользователя и пароля на основе стандартов WS- * в Silverlight: http://geekswithblogs.net/SunnyCoder/archive/2009/03/15/username-password-amp-ws-security-with -silverlight.aspx –
Вы можете использовать HTTPS для обеспечения конечной точки и требуют проверки подлинности. Вы можете поместить в код незащищенный длинный секретный ключ. К сожалению, System.Security.Cryptography не входит в установку SL, поэтому не шифруется на сервере/расшифровывается по возможностям клиента. И нет причин, по которым пользователь не мог бы просто использовать что-то вроде рефлектора, чтобы читать код в любом случае.
SL можно сделать «главным образом защищенным», но определенно не безопасным.
HTTPS ничего не сделает - пользователь все еще может просматривать. Имена пользователей и пароли в Silverlight обычно выполняются с помощью Forms auth с помощью файла cookie аутентификации, который будет существовать при открытии другой вкладки. И, как вы говорите, ключ бесполезен, потому что рефлектор откроет его. – blowdart
Да, в лучшем случае это только безопасность через обфускацию. HTTPS служит только для того, чтобы люди, которые абсолютно не принадлежат далеко от конечной точки. –
Я ценю идеи людей! –
Вот руководство по шаблонам & Практическая команда по безопасности WCF. Там много чего можно найти.
возможно с .NET 4 и NetTcpBinding для Silverlight, вы будете иметь больше возможностей. –
@marc_s - netTcpBinding может помочь, но он мог бы по крайней мере реализовать базовую защиту токена UserName через WS-Standards (он не является родным в Silverlight ... но существует возможная реализация). –