Спрощення аутентифікації за допомогою wse 3
Як і багато інших технології Microsoft, перша реалізація Web-сервісів - так звані ASMX Web-сервіси - показували шлях до дуже плідним рішенням, але не містили ключових аспектів функціональності, необхідних для створення дійсно надійних і безпечних рішень. Web Services Extensions 3.0 - це нова версія, що дозволяє впоратися з багатьма недоліками ASMX Web-сервісів. Одна з ключових нових можливостей - можливість створювати готові рішення, що підтримують аутентифікацію в Web-сервісах. Я розповім, як це робиться.
Повчально порівняти те, що Microsoft робить доступним тепер, з тим, що існувало в момент початкового випуску VS.NET. Безсумнівно, за допомогою Visual Studio.NET з самого початку було просто створювати Web-сервіси. Розглянемо, наприклад, процес створення ASMX Web-сервісу. Спочатку ви створюєте проект, який буде містити Web-сервіс. Далі використовуються атрибути WebService і WebMethod, щоб показати класи і методи, які хочете викликати віддалено.
Спосіб роботи Web-сервісів досить простий. Вони посилають SOAP-повідомлення, інкапсульоване в тілі http-пакета. Відповідь, що повертається сервером, - HTTP-пакет з SOAP-повідомленням.
Створення Web-сервісу - просте завдання, а забезпечення безпеки - немає. І, швидше за все, вам буде потрібно убезпечити доступ до будь-якого Web-сервісу і реалізувати різні рівні аутентифікації. Тут ASMX Web-сервіси безсилі.
Microsoft вніс зміни, що спрощують процес налагодження, наприклад, використання методів GET і POST, визначених протоколом HTTP, для доступу до Web-сервісів. Це чудово працює, але сьогодні перед розробниками стоять якісь критичні проблеми, які потребують вирішення.
По-перше, Web-сервіс повинен бути незалежним від транспортного протоколу. Ви повинні просто передавати SOAP-повідомлення, незалежно від протоколу, і дозволити транспортному шару розбиратися з деталями протоколів, будь то HTTP, TCP, UDP, MSMQ або навіть SMTP.
Старі підходи проти нових
Можливо, корисно подивитися, як розробники раніше працювали з безпекою в Web-сервісах, перш ніж звернути увагу на те, як це робиться зараз. Щоб убезпечити ASMX Web-сервіс, ви можете реалізувати власне рішення щодо шифрування даних, використовувати будь-якої сервіс стану для зберігання інформації про користувачів між запитами, або скористатися безпекою рівня транспорту, наприклад, HTTPS.
Одна частина цього рішення може зажадати шифрування вмісту переданих параметрів або отримання SSL-сертифіката сервера. Ви можете реалізувати власну схему аутентифікації, передаючи хеш-ключ в якості першого параметра при кожному виклику методу. Ви генеруєте хеш-ключ в методі Login і зберігаєте його в БД. Якщо ключ є в БД, і користувач має право звертатися до методу, запит виконується вдало. Саме так я поступив в першому проекті Web-сервісу, виконувати нашою командою. Нам тоді хтось сказав, що не потрібно змішувати стан сесії IIS з Web-сервісами, і ми йому повірили. Це виявилося неправдою, але ми все одно зберегли власне рішення. Як я пам'ятаю, ми витратили близько тижня на реалізацію і налагодження цього рішення, так як хотіли, щоб воно працювало в Web Farm. Досить сказати, що створення власного рішення означає також витрату істотної кількості часу на аудит коду, тестування і перевірку безпеки цього рішення.
Microsoft активно намагається вирішити ці питання, починаючи з першої версії ASMX Web-сервісів. Наприклад, рішення по аутентифікації Web-сервісів увійшли в Web Service Enhancements (WSE) 1.0. WSE - це add-on до Visual Studio .NET; на Web-сайті Microsoft можна знайти останню версію, WSE 3.0. Одна з найцікавіших можливостей WSE 3.0 - простий у використанні, розширюваний фреймворк, що забезпечує безпеку і аутентифікацію.
Для створення цього фреймворка Microsoft зібрав інформацію по найбільш часто використовується способам забезпечення безпеки Web-сервісів. Використовувалися також повідомлення користувачів на різних форумах і в новинних групах, що описують часто використовувані сценарії. Ці сценарії відображають найбільш часто використовувані, основні способи реалізації забезпечення безпеки і аутентифікації Web-сервісів на поточний момент. Саме тому вони отримали назву Turnkey Security Scenarios - сценарії безпеки «під ключ».
Документація WSE 3.0 називає ці сценарії «Turnkey Security Assertions», але термін «сценарій» набагато ширше поширений в співтоваристві розробників Web-сервісів, так що я буду використовувати саме його. У готових сценаріях добре те, що їх можна застосовувати декларативно, дозволяючи адміністратору системи змінювати їх під час роботи сервісу. Декларативна модель дозволяє також програмно розширювати існуючі сценарії або навіть створювати власні сценарії. Ще одна перевага: топологія мережі може змінитися - сервер може переїхати до іншого провайдера - але вам не потрібно заново розгортати сервіс.
Використовувані в проекті готові сценарії перераховуються в спеціальному файлі політики. У файлі політики можна створити іменовану політику і декларативно вказати вимоги безпеки. При використанні готового або автоматизоване політики файл політики повинен вказувати клас розширення політики. WSE створює екземпляр цього класу, грунтуючись на установках, зазначених у файлі політики. Приклад коду в документації WSE використовує розширення для завантаження класу, щоб файл політики міг бути оброблений належним чином.
Почнемо з майстра (wizard)
Почнемо з використання майстра WSE, щоб включити використання політики Web-сервісом. Після установки WSE 3.0 клацніть правою кнопкою по Properties в проекті Web-сервісу і виберіть "WSE Settings 3.0" з контекстного меню. На першій закладці потрібно позначити "Enable this project for Web Service Enhancements" і "Enable Microsoft Web Services Enhancements Soap Protocol Factory". На закладці Policy позначте "Enable Policy", і буде показано ім'я файлу політики, який потрібно використовувати. Цей файл створюється в тій же папці, що і файл web.config. Клацніть по кнопці Add, щоб додати нову політику для додатка, і вкажіть яке-небудь дружнє ім'я, хоча б MyPolicy. Це призведе до відкриття WSE Security Settings Wizard. Натисніть Next. Це відкриє сторінку Authentication Settings, що містить найбільш цікаві опції (див. Малюнок 1).
Переконайтеся, що ви вибрали "Secure a service application". Зауважте, що ви працюєте над проектом Web-сервісу, а не клієнта, що звертається до Web-сервісу. Щоб створити файл політики для клієнтської сторони, потрібно знову запустити майстер і вибрати "Secure a client application".
Нижня частина майстра надає вибір з чотирьох методів аутентифікації клієнта: анонімний (anonimous), по імені користувача (username), за сертифікатом і аутентифікацію Windows. Натисніть Next і залиште все решта опції незмінними. Кожен метод аутентифікації реалізується з використанням готового сценарію WSE 3.0. Розберемо, що означає кожен з варіантів.
Анонімний метод аутентифікації реалізується класом AnonymousForCertificateAssertion. Цей метод використовується для роботи з анонімними клієнтами. Наприклад, його можна використовувати, якщо неважливо, хто саме звертається до сервера. Клієнти не автентифіковані, так що ви дбаєте тільки про те, що зв'язок безпечна, і не може бути відстежено або підроблена. Безпека зв'язку забезпечується серверним сертифікатом X.509. Це єдиний сертифікат, який ви повинні встановити на сервері для забезпечення безпеки комунікацій за цим сценарієм. Сертифікат дозволяє шифрувати і підписувати SOAP-повідомлення цілком або окремі його частини, наприклад, тільки тіло і заголовок повідомлення. елемент
Знову ж, сервер надає сертифікат X.509, зазначений в
Використання Windows-аутентифікації
Windows-аутентифікація - останній варіант на сторінці майстра. Цей варіант аутентифікації використовує окремий сервер реквізитів Kerberos, до якого клієнт і сервер можуть звертатися для перевірки реквізитів. Сервер реквізитів видає сервісні квитки (service tickets) Kerberos, інкапсуліруемие в SOAP-повідомленнях. Приймаюча сторона може запросити Kerberos-сервер про дійсність отриманого квитка. Можна налаштувати Kerberos-сервери так, щоб вони допускали делегування, що робить їх корисними при реалізації корпоративного рівня безпеки або системи «єдиної підпису» (single sign on, SSO). Майстер WSE не дозволяє налаштувати установки для квитка Kerberos, але це можна зробити вручну, в файлі політики. Елемент Kerberos показаний в лістингу 3.
WSE 3.0 містить ще один готовий сценарій, але його немає в майстра. Він реалізується класом UsernameOverTransportAssertion і дозволяє аутентифицировать клієнтів за допомогою текстових імені користувача та пароля, виконуючи шифрування повідомлень і захист на рівні транспорту. Однак WSE не перевіряє, чи забезпечується безпека на рівні транспорту, так що при використанні цього сценарію необхідно дотримуватися обережності. Ви ж не хочете, щоб ваші паролі було легко перехопити при передачі. Використовувати сценарій UsernameOverTransport просто:
На жаль, цей простий сценарій в основному покладається при захисті повідомлень на транспортний рівень, що не дозволяє захистити частину SOAP-повідомлення - воно повинно шифруватися і розшифровуватися повністю.
Я вже згадував, що я вважаю за краще ставити імена користувачів і паролі програмно. Можна зробити це в файлі політики, але це не рекомендується при використанні сценарію UsernameOverTransport, оскільки пароль ніде не повинен зберігатися в текстовому вигляді.
Після створення політики для сервісу потрібно зробити те ж саме для клієнта. Наявність обох політик дозволяє застосувати їх в класі PolicyAttribute Web-сервісу, а також в проксі-класі Web-сервісу:
Можна також викликати метод proxy.SetPolicy ( "MyPolicyUsername") для проксі-класу Web-сервісу. Завдання імені користувача і пароля для клієнтського проксі описано в документації WSE: