LINUX.ORG.RU

Межсерверный кроссплатформенный доверенный обмен

 , , ,


0

1

Медленно проявляется тут задачка обеспечить гибкий обмен данными между серверами, вероятнее всего — в JSON. Точнее, даже реализовать API. Чтобы клиент мог, представившись, получить, например, идентификатор сессии и, подписываясь им, запрашивать данные у сервера.

Как я это вижу:
— Клиент делает запрос у сервера на получение идентификатора сессии
— Сервер отдаёт или открытый ключ для шифрования, или соль
— Клиент шифрует свои авторизационные данные (логин/пароль или просто уникальный ключ) или хеширует их с солью и возвращает результат.
— Сервер проверяет, если всё ок, то пересылает ID сессии
— В дальнейшем клиент запрашивает серию данных, представляясь в каждом запросе полученным ID

Наверное, надо как-то ещё сессию защитить. Ну, таймаут, само собой (при чём сервер, отдавая ID клиенту ещё и срок жизни этого ID указать должен), привязка к IP клиента. Можно и, вообще, шифровать ID, но не уверен, что это имеет смысл.

Реализовать не сложно, но, вдруг, есть уже готовое и станартное решение, чтобы не велосипедить?

★★★★★

Похоже на OAuth2. Авторизация и предоставление API для каких-то операций с данными сервера.

x_hash ()

Реализовать не сложно, но, вдруг, есть уже готовое и станартное решение, чтобы не велосипедить?

https?

r_asian ★☆☆ ()
Ответ на: комментарий от KRoN73

И в каком месте там авторизация и сессии?

Ну, вообще-то сертификаты бывают не только серверные, но и клиентские. Т.е. аутентифицировать может не только клиент сервера, но и сервер клиента, т.е. в обе стороны (сервер отдает данные, только если клиент предьявил правильный сертификат, ну а когда данные придут, клиент проверяет сертификат сервера...).

x_hash ()
Ответ на: комментарий от KRoN73

И в каком месте там авторизация и сессии?

В случае использования https для авторизации по большому счету достаточно простого ключа без какой-либо криптографии, т.к. соединение итак идет по защищенному каналу.

Dobriy_i_Prostoy ()
Ответ на: комментарий от Dobriy_i_Prostoy

В случае использования https для авторизации по большому счету достаточно простого ключа без какой-либо криптографии

А если кто-то ключ перехватит? Задача-то, как я писал, не в организации защищённого канала. А в организации авторизации.

KRoN73 ★★★★★ ()
Ответ на: комментарий от Dobriy_i_Prostoy

проще передавать ключ при каждом запросе.

Чтобы ключ не подобрали тупым перебором, желательно его генерацию сделать не очень быстрой.

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

Задача-то, как я писал, не в организации защищённого канала. А в организации авторизации.

Тогда делай авторизацию по https. На сервере проверяешь сертификат клиента, на клиенте сертификат сервера (если в твоей схеме такое организовать будет достаточно просто). А данные гоняешь как привычно. Сессию организуешь вручную, по session_id.

x_hash ()
Ответ на: комментарий от KRoN73

И в каком месте там авторизация

Разин все правильно сказал. Авторизация в обе стороны.

и сессии

per-request. Можешь куку с привязкой к client software отдать и запретить более 1 сессии на пользователя, если хочется.

GateKeeper ★★ ()
Ответ на: комментарий от KRoN73

Чтобы ключ не подобрали тупым перебором

Таймаут 100мс при неверной авторизации. И ограничение числа одновременных подключений.

x_hash ()
Ответ на: комментарий от KRoN73

А если кто-то ключ перехватит? Задача-то, как я писал, не в организации защищённого канала. А в организации авторизации.

HTTPS обеспечивает защиту от прослушивания и атак Man-in-middle. Таким образом перехватить ключ можно только получив контроль над одной из систем, а в таком случае уже ничего не поможет.

Я конечно не берусь утверждать 100% надежность протокола HTTPS (где-то тут недавно дискуссия по этому поводу была), но вряд ли ты на коленке напишешь что-то лучше.

Dobriy_i_Prostoy ()
Ответ на: комментарий от Dobriy_i_Prostoy

Задача-то, как я писал, не в организации защищённого канала. А в организации авторизации.

Наличие защищенного канала может помочь организовать авторизацию без изобретения ненужных велосипедов.

Dobriy_i_Prostoy ()

может просто посмотреть Kerberos ? http://ru.wikipedia.org/wiki/Kerberos

а дальше мучить голову как построить SSO (single sign on) на нём конкретно для вашего случая.

Для LDAP-AD доменов - всё вмеру разжёванно в сети. А вот кто ваши пользователи, как они представляются, где и как хранится/проверяется/генерятся ключи - придётся возможно выдумывать

MKuznetsov ★★★★★ ()

Готовый и стандартный велосипед OAuth2

C1nde ()

согласен с народом про серты с двух сторон.

лучше не мешать логику приложения с аутентификацией - пусть она остается в своем слое, пусть это будет https.

а сессии вроде как на сервисах не особо нужны - если это «типа сервис» (rest, soap, json,...) - большинство подразумевает stateless схемы обмена.

конечно подымать инфраструктуру PKI на пустом месте для «двух скриптов» напрягает, но можно по-минимуму обойтись CA.pl/CA.sh из комплекта openssl-я.

dab18 ()

Https + sessionId в куках/хэдерах. Либо авторизация по клиентскому ключу. Не стоит изобретать велосипед там, где это не особо надо.

Nagwal ★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.