Протокол, парадигма или программное обеспечение для аутентификации веб-запросов в собственных доменах

Question

tl; dr

Я рассматриваю веб-сервис модель проектирования , которая состоит из нескольких сервисов / поддоменов, каждый из которых может быть реализован на разных платформах и размещен на разных серверах.

Основная проблема аутентификация .Если поступил запрос на ресурсы jane, может ли сплит-система аутентифицировать этот запрос как свой?

Разумеется, все службы обращаются к одному и тому же уровню БД.Таким образом, я имею в виду единственную точку истины , которую каждая служба может использовать для аутентификации каждого запроса.

---

Например, jane доступ www.site.com, который отображает содержимое в нейбраузер.Браузер может отправлять запрос на стороне клиента в различные домены site.com с такими запросами, как:

from internalapi.site.com fetch /user/users_secret_messages.json
from imagestore.site.com fetch /images/list_of_images

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

---

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

В этом псевдокоде AuthService.verify_authentication() относится к центральному ресурсу

//server side code:
def get_user_profile():
    auth_token=request.cookie['auth_token']
    user=AuthService.verify_authentication(auth_token)
    if user=Null:
        response.write("you are unauthorized/ not logged in")
    else:
        response.write(json.dumps(fetch_profile(user))) 

---

Вопрос: Что существующие протоколы, программное обеспечение или даже хорошие методы проектирования существует для обеспечения безупречной аутентификации в нескольких поддоменах?

---

Я видел, как OAuth устраняет головную боль при управлении сторонним доступом, и удивляюсь, существует ли что-либо для такой аутентификации.Я также получил идею от Kerberos и TACACS .

Эта идея была результатом командного мышления, как способ упростить архитектуру (а не обрабатывать большие нагрузки).

Answer 1

Я создал систему, которая сделала это некоторое время назад. Мы создавали shop.megacorp.com, и нам приходилось делить логин с www.megacorp.com, profile.megacorp.com, customerservice.megacorp.com и т. Д.

То, как это работало, было в двух частях.

Во-первых, все входы в систему обрабатывались через набор страниц на accounts.megacorp.com. Ссылка для регистрации на наших страницах была указана здесь с URL-адресом возврата в качестве параметра (поэтому https://accounts.megacorp.com/login?return=http://shop.megacorp.com/cart). Процесс входа в систему будет перенаправлен обратно на обратный URL после завершения. На странице входа также устанавливается cookie-файл для аутентификации, охватывающий весь домен megacorp.com.

Во-вторых, проверка подлинности осуществлялась на различных сайтах путем извлечения файла cookie из запроса и последующей передачи его через внутренний веб-сервис на account.megacorp.com. Мы могли бы сделать это простым запросом SOAP или REST, используя cookie в качестве параметра, но на самом деле мы отправили HTTP-запрос с cookie, добавленным в заголовки (как если бы пользователь отправил запрос). напрямую). Этот URL-адрес затем возвращался бы как 200, если cookie был действительным, предоставляя некоторую информацию о пользователе, или 401 или что-то, если это не так. Мы могли бы тогда иметь дело с пользователем соответственно.

Само собой разумеется, мы не хотели делать запрос к accounts.megacorp.com для каждого пользовательского запроса, поэтому после успешной аутентификации мы помечаем сеанс пользователя как аутентифицированный. Мы сохраняли бы значение cookie и временную метку, и если последующие запросы имели одинаковое значение cookie и находились в течение некоторого времени ожидания от временной метки, мы рассматривали бы их как аутентифицированные, не передавая их.

Обратите внимание, что поскольку мы передаем cookie-файл как cookie-файл в запросе аутентификации, код для его проверки на account.megacorp.com точно такой же, как и при обработке прямого запроса от пользователя, поэтому его было легко реализовать правильно. Итак, в ответ на ваше желание «существующих протоколов [или] программного обеспечения», я бы сказал, что протокол HTTP, а программное обеспечение - это то, что вы можете использовать для проверки файлов cookie (стандартная часть обработки пользователя любого веб-контейнера). Служба аутентификации так же проста, как веб-страница, на которой печатаются имя и данные пользователя и которая помечена как требующая входа в систему пользователя.

Что касается "хороших методов проектирования", ну, это сработало, и оно довольно эффективно отделило процессы входа и аутентификации от нашего сайта. Он ввел зависимость во время выполнения от службы на accounts.megacorp.com, которая оказалась несколько ненадежной. Этого трудно избежать.

И на самом деле, теперь я вспоминаю, что запрос к accounts.megacorp.com был на самом деле запросом SOAP, и мы получили ответ SOAP с информацией о пользователе, но аутентификация была обработана с помощью cookie, как я описал. Было бы проще и лучше сделать его запросом REST, когда наша система просто выполнила GET по стандартному URL и получила взамен какой-то XML или JSON, описывающий пользователя.

Сказав все это, если вы разделяете базу данных между приложениями, вы можете просто иметь таблицу, в которую вы записываете (username, cookie, timestamp) кортежи и делаете поиск непосредственно в этом, вместо того, чтобы делать запрос к услуга.

Единственный другой подход, который я могу придумать, - это использовать криптографию с открытым ключом. Приложение, обрабатывающее логин, может использовать закрытый ключ для создания подписи и использовать его в качестве файла cookie. Другие приложения могут иметь соответствующий открытый ключ и использовать его для его проверки. Ключи могут быть для каждого пользователя или только один. Это не предполагает взаимодействия между приложениями или общей базой данных после первоначального распределения ключей.