Введення в Claims-based identity

При розробці додатків на стеку Microsoft для отримання інформації про поточного користувача досить часто (точніше майже завжди) можна зустріти такі ділянки коду або обгортки над ними:

[Authorize("Administrators")] public ActionResult DoSomeHardcoreAdminStuff() . >

а через рік бізнес вирішив, що непогано було б мати кілька різних груп користувачів з різним рівнем доступу і до всього іншого (ну щоб зрозуміти весь драматизм даної ситуації) розмежувати права для адміністраторів на SystemAdministrator і SecurityAdministrator. І це не межа, оскільки ці вимоги обмежуються лише фантазією бізнесу.

У відповідь на це в 2008 році з надр Microsoft побачив світ перший реліз Windows Identity Foundation (WIF) і було представлено концепцію Claims-based identity. Метою цього фреймворку є надання абстрактного механізму вираження своїх вимог до користувача, не заглиблюючись у деталі того, як це працює.

Коротко ідею WIF можна описати досить простим життєвим прикладом: Вам виповнилося 18 і ви вирішили сходити в кіно. Дорослий кіно. Але, на жаль, не встигли отримати паспорт чи будь-яке інше посвідчення особи досі (ну чи просто було ліньки). Ви збираєтеся і йдете в паспортний стіл, через якийсь час отримуєте паспорт і пред'являючи ваш паспорт сміливо купуєте собі заповітний квиток і йдете на сеанс. А ось так це виглядає з погляду WIF:

identity

Subject, тобто ви, йдете до Identity provider(паспортний стіл) і на основі Свідоцтво_о_народженніToken отримуєте ПасспортToken. Потім, разом з цим ПасспортToken ви йдете до Relying party (кінотеатр) і після підтвердження вашого віку отримуєте доступ до послуги.

Основні ідеї, які можна витягти з цього прикладу:

2. Паспортний стіл не знає де ви пред'являтимете паспорт. (З точки зору WIF все-таки трохи знати повинен, але це не обов'язково).

3. З паспортом ви можете купити собі гарного віскі після походу в кіно, взяти іпотеку або щось у будь-якій установі, яка довіряє документам, виданим держ. установою.

Хтось уже працював з такими протоколами як OAuth, WS-Trust та WS-Fed, SAML-P і ця схема взаємодії буде їм знайома. Коротко — інформацію про користувача ви отримуєте від довіреної сторони (Identity provider) у вигляді токена певного формату і використовуєте її для прийняття будь-яких рішень у вашому додатку. У виродженому випадку, наприклад Forms authentication, ви самі є цією посвідчувальною стороною і самі використовуєте цю інформацію. WIF припускає такі сценарії. WIF досить гнучкий для підтримки різного роду сценаріїв.

[PrincipalPermission(SecurityAction.Demand, Role = "Administrators")] static void CheckAdministrator() Console.WriteLine("User is an administrator"); >

Для цього достатньо, щоб у користувача було затвердження типу роль (можна налаштовувати тип тверджень, які будуть використовуватися як ролі) зі значенням “Administrators”.

Додаток на ASP.NET MVC може виглядати так:

[ClaimsAuthorize(ClaimTypes.Role, "Administrators")] public ActionResult DoSomeHardcoreAdminStuff() . >

[ClaimsAuthorize(ClaimTypes.Permission, "DoSomeHardcoreAdminStuff")] public ActionResult DoSomeHardcoreAdminStuff() . >

На даний момент на платформах від Microsoft є два основні рішення для такого підходу: Active Directory Federation Services (ADFS) і Azure ACS. Якщо вам не підходить ні те, ні інше, то вивільні самостійно написати свій сервіс, благо з коробки студію ставиться шаблон з прикладом. Також є опенсорсний сервер IdentityServer, на основі якого можна розвивати свій власний продукт.

З коробки WIF підтримує такі протоколи: 1. WS-Federation 2. WS-Trust 3. WS-Security 4. WS-SecurityPolicy 5. WS-Addressing

Підтримка протоколу SAML-P перебуває у стані CTP. Інформації про RTM версію поки що немає. Також є OAuth2 extensions.

Стандартно підтримуються посвідчення SAML1.1 та SAML2. Але вже є досить розвинені бібліотеки, які додають підтримку SWT і навіть JWT (Json Web Token).

PS. Дякую XaocCPS за рецензію.

А у нас тут можна отримати грант на тестовий період Яндекс.Хмари. Варто лише у полі «секретний пароль» запровадити «Хабр»