Сесії WCF на Windows Azure

Наша архітектура додатки виглядає наступним чином: 1) Служба WCF працює як фасадний шар і розташовується поверх служби, бізнес-логіки та рівня доступу до даних 2) Кожен клієнт, будь то MVC/ASP.NET, або будь-який інший тип програми, має ClientTag, який спочатку повинен бути ідентифікований та випущений "токеном доступу". Цей токен потім передає клієнт з кожним повідомленням у шару фасаду 3) Система буде розміщена на Windows Azure

Це було б легко здійснити за допомогою сеансів WCF так: 1) Клієнт ініціює виклик WCF для отримання токену (Клієнт встановлює WCF-сеанс, таким чином, кожен наступний зв'язок є частиною тієї ж "розмови") 2) WCF автентифікує ClientTag, видає токен і зберігає його як локальну змінну 3) Клієнт зберігає токен у власній сесії та передає його WCF з кожним запитом

Де він розбивається, це той факт, що Azure (через його високу доступність/балансування навантаження) не підтримує сесій WCF. Отже, питання полягає в тому, як ми це реалізуємо.

Одним з рішень є використання кешування AppFabric для імітування стану сеансу на рівні WCF. Ми будемо зберігати Token Access, а потім перевірити його на те, що клієнт проходить. Проблема з цим полягає в тому, що немає взаємодії між клієнтом і WCF. Отже, нам доведеться перевищувати тайм-аут сеансу WCF на кожному запиті від того самого клієнта, але ми хочемо уникнути оновлення кешу на кожному запиті (це може бути сотні/сек).

Будь-які пропозиції? Хто-небудь реалізував щось подібне до цього на Azure. Будь-який зворотний зв'язок буде дуже вдячний.

П.С. Це не тільки автентифікація, яка відбудеться на сервері, а й індивідуальне авторизація для кожного клієнта. (Деякий клієнт може мати доступ до деяких функцій, а інші не можуть).

Дякую!

3

1 Відповіді

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

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

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

Зверніть увагу, що зразок використовує стару школу ASP.NET, і він залежить від непрозорого (і, можливо, досить важкого) збірки Microsoft.IdentityModel.Protocols.Oauth . І якщо я не пройду щось, я не бачив, що це вийшло ніде в іншому місці (наприклад, в рамках програми Identity Foundation Windows), і я підозрюю, що це досить нове.

Альтернативним підходом може стати знову використовувати ACS, на цей раз для аутентифікації маркера SAML знову під протоколи OAuth 2.0. Подробиці та код зразків можна знайти тут: http://msdn.microsoft.com/ en-us/бібліотека/windowsasure/hh127795.aspx . Це може бути краще підходить для системи без інтерфейсу користувача.

0
додано