Глобальная авторизация в веб-системах — различия между версиями
м (Новая страница: «…или как реализовать простой Single Sign-on в веб-системах. Ниж...») |
м |
||
Строка 17: | Строка 17: | ||
|valign=top| (П) → | |valign=top| (П) → | ||
|valign=top| (переходит по ссылке) → | |valign=top| (переходит по ссылке) → | ||
− | |valign=top| <tt style="background-color: #e0ffe0">C1</tt><br /> | + | |valign=top| <tt style="background-color: #e0ffe0">C1</tt> с любыми параметрами.<br /> |
⇒ <tt style="background-color: #e0ffe0">C1</tt> хочет перенять авторизацию у <tt style="background-color: #e0e0ff">С2</tt>. <br /> | ⇒ <tt style="background-color: #e0ffe0">C1</tt> хочет перенять авторизацию у <tt style="background-color: #e0e0ff">С2</tt>. <br /> | ||
<tt style="background-color: #e0ffe0">C1</tt> генерирует случайный ID (ID) и ключ (KEY). Никаких ограничений на эти значения не накладывается, кроме того, что они должны быть достаточно стойки к подбору и, желательно, состоять из печатных символов. Например, за каждый из них можно взять 16 случайных байт, взятых из <tt>/dev/urandom</tt> в UNIX-системах и <tt>GetRandom()</tt> в Windows. | <tt style="background-color: #e0ffe0">C1</tt> генерирует случайный ID (ID) и ключ (KEY). Никаких ограничений на эти значения не накладывается, кроме того, что они должны быть достаточно стойки к подбору и, желательно, состоять из печатных символов. Например, за каждый из них можно взять 16 случайных байт, взятых из <tt>/dev/urandom</tt> в UNIX-системах и <tt>GetRandom()</tt> в Windows. |
Версия 17:45, 13 июля 2010
…или как реализовать простой Single Sign-on в веб-системах.
Ниже описан простейший протокол, который даёт возможность нам сказать внешней системе, кто к нам вошёл, так, что внешняя система знает, что это говорим ей именно мы, а мы знаем, что мы говорим это именно ей.
- (П) Пользователь.
- (С1) Система 1 — клиент глобальной авторизации. В неё пришёл пользователь без авторизации.
- (С2) Система 2 — сервер глобальной авторизации. В ней пользователь уже авторизован, скорее всего, через cookie.
шаг | кто | что делает | кому |
---|---|---|---|
(П) → | (переходит по ссылке) → | C1 с любыми параметрами. ⇒ C1 хочет перенять авторизацию у С2. | |
1 | C1 → | (делает GET-запрос напрямую) → | С2 с параметрами ga_id=ID&ga_key=KEY ⇒ С2 запоминает соответствие ID и KEY. |
2 | С1 → | (перенаправление браузера пользователя) → | С2 с параметрами ga_id=ID&ga_url=URL&ga_check=CHECK
⇒ С2 даётся возможность прочитать cookie пользователя и получить данные о нём. |
3 | С2 → | (делает POST-запрос напрямую) → | С1 с параметрами ga_client=1&ga_id=ID&ga_key=KEY&ga_data=DATA&ga_nologin=NOLOGIN
⇒ С1 запоминает соответствие ID и переданных данных. |
4 | С2 → | (перенаправление браузера пользователя) → | С1 с параметрами ga_client=1&ga_id=ID&ga_res=CODE
⇒ С1 может взять сохранённые в предыдущем пункте данные и на их основе авторизовать пользователя. |
И ID и ключ являются секретными, но ID знают и сервера, и пользователь (ID передаётся в браузер), а ключ — только сами сервера. За счёт этого достигается безопасность: пользователь не может сам передать произвольные данные авторизации на сервер, не зная ключа.
Для дополнительной защиты всё это можно просто пустить через HTTPS (SSL).