Сеансы WCF в Windows Azure

Question

Архитектура нашего приложения выглядит следующим образом: 1) Служба WCF действует как фасадный уровень и располагается поверх уровня Service, Business Logic и Data Access 2) Каждый клиент, будь то MVC / ASP.NET или любой другой типприложения имеет ClientTag, который сначала должен быть аутентифицирован и выдан «токен доступа».Этот токен затем передается клиентом с каждым сообщением на уровень фасада. 3) Система будет размещена на Windows Azure

. Это было бы легко реализовать с помощью сеансов WCF, например: 1) Клиент инициирует вызовв WCF для получения токена (устанавливается сеанс Client to WCF, таким образом, каждый последующий обмен данными является частью одного и того же «разговора») 2) WCF аутентифицирует ClientTag, выдает токен и сохраняет его как локальную переменную 3) Клиент сохраняеттокен в своем собственном сеансе и передавать его в WCF с каждым запросом

. Там, где он ломается, это тот факт, что Azure (из-за своей высокой доступности / распределения нагрузки) не поддерживает сеансы WCF.Итак, вопрос в том, как мы это реализуем.

Одним из решений является использование кэширования AppFabric для имитации состояния сеанса на уровне WCF.Мы храним токен доступа там, а затем проверяем его на соответствие тому, что передает клиент. Проблема в том, что между клиентом и WCF нет параллелизма.Таким образом, нам пришлось бы увеличивать время ожидания сеанса WCF при каждом запросе от одного и того же клиента, но мы бы хотели избежать обновления кэша при каждом запросе (это может быть сотни в секунду).

Есть предложения?Кто-нибудь реализовал что-то подобное в Azure.Любая обратная связь будет принята с благодарностью.

PS На сервере будет происходить не только аутентификация, но и индивидуальная авторизация для каждого клиента.(Некоторые клиенты могут иметь доступ к некоторым функциям, а другие нет).

Спасибо!

Answer 1

Я нахожусь в процессе реализации чего-то прямо подобного этому, но использую OAuth 2.0 в качестве архитектуры аутентификации через ACS.

Модель, которой я следую, бесстыдно украдена скопированаиз примера MSDN здесь: https://connect.microsoft.com/site1168/Downloads/DownloadDetails.aspx?DownloadID=35417. Это предполагает, что у клиента есть пользовательский интерфейс, поэтому пользователь может представить какое-то имя пользователя и пароль либо напрямую, либо через какого-либо стороннего поставщика удостоверений.

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

Обратите внимание, что в примере используются старые-school ASP.NET, и имеет зависимость от непрозрачной (и, возможно, довольно глючной) сборки Microsoft.IdentityModel.Protocols.Oauth.И, если я что-то упустил, я не видел, чтобы это было выпущено где-либо еще (например, как часть Windows Identity Foundation), поэтому я подозреваю, что это довольно новое.

Альтернативным подходом снова может быть использование ACS, на этот раз для аутентификации токена SAML, снова следуя протоколам OAuth 2.0.Подробности и пример кода здесь: http://msdn.microsoft.com/en-us/library/windowsazure/hh127795.aspx. Это может быть лучше подходит для системы без пользовательского интерфейса.