Есть ли стандартный способ обработки кросс-каркасной аутентификации?

Question

У меня есть несколько веб-приложений на Ruby, которые используют OpenID для аутентификации и сохраняют сеанс в файле cookie.Есть несколько вещей, связанных с API и AJAX, для которых мои Ruby-фреймворки не очень подходят, поэтому у меня есть несколько сервисов node.js.Проблема в том, что если бы кто-то знал URL-адреса моих AJAX-сервисов, они были бы в основном открыты для публики при существующих условиях.На данный момент эти службы выполняют простую проверку заголовка Origin, но, очевидно, это очень легко подделать.

Поэтому я хочу иметь возможность ограничить доступ к службам, работающим на Node (или Python, или вне основанный на Rack сервис Ruby или что-либо еще) для пользователей, которые вошли в «основную» службу, которая запускается через веб-приложение на основе Rack.Существуют ли соглашения о том, как это делается?Я видел кучу веб-сайтов, которые будут обслуживать контент и страницы через example.com, а затем вызовы AJAX совершаются через api.example.com, поэтому я удивлен, что это то, о чем я не читал.

У меня есть идея, как это сделать, и я хотел бы получить некоторые отзывы о том, упускаю ли я что-то ослепительно очевидное, что делает это небезопасным:

Мое веб-приложение на Ruby использует OpenID для аутентификации и хранениясеанс в файле cookie сеанса, используя Rack::Session.При взгляде на источник Rack::Session мой фреймворк, похоже, проходит через этот процесс:

• создает дамп Marshal моего объекта User
• создает хэш SHA1 для Marshal на основесекретный ключ
• хранит шестнадцатеричный дайджест хеша SHA1 в файле cookie

Так что теоретически я мог бы иметь заранее подготовленный ключ или систему для генерации ключа, или некоторую передачу сообщениймежду фреймворками через безопасный канал для обмена ключами.Тогда я мог бы изменить процесс шифрования в любой другой среде, которая хотела бы иметь возможность проверять данные сеанса.Я должен был бы избавиться от первого шага и хранить только данные JSON или что-то вместо объекта Ruby для разносторонней совместимости, конечно.

Считается ли это безопасным способом сделать что-либо, предполагая, чтопротоколы для обмена ключами надежно защищены?

Answer 1

То, что вы описываете, это код аутентификации сообщения (MAC); в данном случае это MAC или HMAC на основе хэша. По сути, возьмите представление данных, которые вы хотите аутентифицировать (убедитесь, что они поступают из определенного источника), добавьте секретный ключ к нему и хешируйте все это. Затем прикрепите этот вычисленный хэш к сообщению (то, что вы только что хэшировали, за исключением секретного ключа). Когда получающая сторона получает сообщение, она берет данные, добавляет к ним тот же общий секрет и хеширует их. Если это вычисленное значение совпадает с полученным как часть сообщения, оно является подлинным и должно быть обработано; если хэши не совпадают, это не от той стороны, с которой они должны быть, и должны быть отброшены.

Возможно, вы захотите взглянуть на RFC, определяющий конструкцию HMAC (просто не используйте пример кода, поскольку он все еще использует MD5; используйте что-то вроде SHA-256 или SHA-512 для реализации вашего HMAC): http://www.ietf.org/rfc/rfc2104.txt