Проверка подлинности OpenID на поддоменах AppEngine и не-AppEngine

Question

У меня есть главный веб-сайт, работающий на AppEngine.Он находится на поддомене, например main.example.com .Это основное приложение является информационным порталом для наших клиентов.Он предлагает Ajax-приложение, основанное на YUI.Клиенты могут загружать данные на него.Пользователи проходят аутентификацию с использованием федеративного входа в систему.

Приложение Ajax позволяет пользователям обрабатывать ранее загруженные данные.Для этого он должен использовать веб-сервис, работающий на другом поддомене, например service.example.com .Веб-сервис не работает на AppEngine, но на наших сервисах - он загружен ЦП и построен на другом наборе технологий.Потребовалось бы загрузить данные в основное приложение, но служба загрузки - как и все в основном приложении - находится за стеной аутентификации.

Я мог бы программно всегда разрешать загрузку службы, где бы она ни пожелала, но я думаю,это может превратиться в серьезную проблему безопасности.

Как я могу повторно использовать «токен» аутентификации OpenID, чтобы позволить ему (службе) отображаться в основном приложении как аутентифицированный пользователь, чтобы он мог загружать данные?Или, если я смогу сделать это, что будет лучшим способом достичь того, что я намерен сделать?

Answer 1

Нельзя повторно использовать токен аутентификации. Вам следует использовать что-то похожее на OAuth, хотя, поскольку вы контролируете оба конца, вы можете упростить его:

1. Создание общего секретного ключа, доступного как main.example.com, так и service.example.com
2. Когда пользователь впервые обращается к service.example.com (без файла cookie для аутентификации), перенаправьте его на main.example.com/auth?continue=original_url (где original_url - это URL-адрес, к которому он пытался обратиться)
3. Когда вы получаете запрос на main.example.com/auth, сначала зарегистрируйте пользователя обычным способом (если он еще не зарегистрирован). Затем возьмите их идентификатор пользователя или другие соответствующие учетные данные и сгенерируйте из них HMAC , используя общий секрет, который вы установили в шаге 1. Перенаправьте пользователя на service.example.com/finish_auth, передав вычисленный HMAC детали аутентификации, такие как ID пользователя, и любые параметры, которые вы передали, такие как URL продолжения.
4. Когда вы получите запрос к service.example.com/finish_auth, вычислите HMAC, как указано выше, и убедитесь, что он совпадает с переданным в единицу. Если это так, вы знаете, что запрос является законным. Установите файл cookie для аутентификации на service.example.com, содержащий все необходимые сведения, и перенаправьте пользователя обратно на его исходный URL.

Это звучит сложно, но довольно просто в реализации. Это стандартный способ «передачи» учетных данных между взаимно доверяющими системами, и он мало чем отличается от того, что используют многие системы единого входа.