3.2.3.2. Авторизація клієнтської сторони

Авторизація клієнтської сторони дозволяє клієнтові з'ясовувати, коли можна буде викликати службу. Може здатися, що це не коректний вид авторизації, оскільки авторизація, загалом, є видимою з сервера. Режими авторизації клієнтської сторони:

None: Авторизація не виконуватиметься.

Self: Клієнт авторизує виклик, якщо особа служби співпадає з особою клієнта.

Identity authorization: Як викладено вище, клієнт тільки допустить відправку запитів до служб вказаній ідентичності.

Host: Клієнт авторизує виклик, якщо служба має посвідчення особи хоста. До того ж, клієнт повинен бути здатний вирішити адресу вузла до імені хоста, вказаного в посвідченні особи вузла.

Важливо відзначити, що така авторизація відрізняється від серверної авторизації вузла, в якій перевіряється, як ім'я хоста в посвідченні особи відповідає певному вузлу.

3.2.3.3. “Custom” авторизація

GSI забезпечує інфраструктуру, в яку можна легко включити власні механізми авторизації. Наприклад, деяка організація, можливо, використовувала б службу успадкованої авторизації, яка не може працювати з методами авторизації, наданими стандартним інструментарієм. В даному випадку, є можливість створити новий метод авторизації, який дозволить GSI зробити вирішення авторизації заснованими на успадкованій службі організації.

3.2.4. Делегація і єдиний вхід (проксі-сертифікати)

Для вирішення єдиного входу пропонується використовувати механізм генерації проксі-сертифікатів. Від процедури видачі сертифікату центром сертифікації, даний алгоритм відрізняється тим, що роль CA тут грає користувач (точніше його клієнтська програма), а сам сертифікат видається на вельми короткий проміжок часу (звичайно не більше 12-ти годин). Крім єдиного входу в систему механізм проксі-сертифікатів також дозволяє делегувати свої права, тобто дозволяє ресурсам системи (наприклад, веб-сервисам) виконувати різні завдання від імені клієнта і з його правами доступу. Розглянемо приклад показаний на рис. №11:

Рисунок 11. Сценарій, де необхідна делегація

AliceOrg просить BobOrg виконати завдання. Оскільки BobOrg довіряє AliceOrg вона погоджується виконати завдання. Припустимо, що завдання Z дуже складне, і що одну з його підзадач (Y) повинна виконати третя організація: CharlieOrg. В даному випадку, BobOrg запитає CharlieOrg виконати subtask Y, але запит не буде виконаний, оскільки CharlieOrg довіряє тільки AliceOrg. CharlieOrg може виконати дві дії:

• Відкинути запит BobOrg. CharlieOrg не довіряє BobOrg, от і все.

• Прийняти запит BobOrg. Справжня запрошуюча сторона AliceOrg, хоча CharlieOrg відповідає на запит від BobOrg, вона фактично здійснюватиме завдання для AliceOrg.

У цій ситуації логічно буде, якщо CharlieOrg прийме запит BobOrg. Проте CharlieOrg повинна знати, що запит BobOrg виконується від імені AliceOrg, як показано на рис.№12.

Рисунок 12. Делегація

Звичайно, це не найбезпечніше рішення, оскільки хто-небудь міг запитати діяти на користь AliceOrg. Можливим рішенням може бути для CharlieOrg контактувати з AliceOrg кожного разу, коли вона отримує запит від імені AliceOrg. Проте в цьому випадку можуть виникнути деякі проблеми. Уявимо, що завдання Z складене з 20 різних підзадач, і що кожна підзадача відіслана до іншої організації BobOrg. AliceOrg буде переповнена повідомленнями, що повідомляють, що “BobOrg тільки що запитав виконати завдання від вашого імені... можете ви підтвердити, що це так?” У відповідь, AliceOrg довелося б засвідчити себе зі всіма тими організаціями і надати підтвердження.

Успішніше рішення могло так чи інакше змусити CharlieOrg вважати, що BobOrg – AliceOrg. Іншими словами, потрібно буде знайти законний шлях для BobOrg продемонструвати, що вона фактично, діє на користь AliceOrg. Одним із способів виконання цього може бути надання AliceOrg пари з відкритого і приватного ключів для BobOrg. Проте, це за межами даного питання. Важливо пам'ятати, що приватний ключ повинен зберігатися в таємниці, і відправляючи його іншій організації (не має значення наскільки їй довіряють) – це велике порушення в захисті. Для вирішення цієї проблеми буде потрібний спеціальний вид сертифікату, показаний на рис.№13.

Рисунок 13. Проксі-сертифікат