2013-03-15 2 views
8

Я ищу, чтобы создать взаимную аутентификацию ssl с Heroku, где третья сторона называет конечную точку Heroku, а ответ от Heroku зависит от того, какая третья сторона вызывает Heroku. Мне нужно использовать взаимный ssl, поскольку третьи стороны очень осведомлены о безопасности.Получение взаимной информации об аутентификации SSL с Heroku

У меня есть сторонняя организация, вызывающая Heroku (через SSL-дополнение) с сертификатом и могу получить ответ. Таким образом, взаимное подтверждение SSL, похоже, сработало.

Однако мое приложение не может определить, какая третья сторона назвала Heroku, поскольку нет никакой информации сертификата для проверки. Я просмотрел заголовки Heroku, чтобы узнать, есть ли дополнительная информация, предоставленная SSL-добавлением, но ничего не могла найти.

Есть ли способ получить информацию сертификата из взаимного слияния с помощью любого другого метода для Heroku?

+0

Я связался с Heroku. Они сообщили мне, что это просто невозможно. Может быть, кто-то еще придумал какое-то решение, но я думаю, что это маловероятно. –

+0

Heroku сообщила мне, что если есть рабочее решение с ELB, они, вероятно, могут заставить его работать тоже. –

ответ

4

Heroku SSL реализован с использованием Amazon Elastic Load Balancers (ELB), которые обеспечивают SSL-окончание сертификатом SSL перед сеткой маршрутизации Heroku.

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

Однако, если ваша цель состоит в использовании аутентификации на основе сертификата для аутентификации HTTP-клиента, вы можете создать его на уровне приложения.

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

Сертификат клиента можно использовать для подписания токена, который вы можете проверить. Обычно токен аутентификации будет содержать некоторые user_id, timestamp и большой nonce. Вы можете передать это через HTTP-заголовок или параметр HTTP-запроса с запросом, обеспечивая аутентификацию на уровне приложения, а не уровень SSL.

Для примера:

# Half-ass ruby-ish pseudocode 
def generate_auth_token(user_id, cert_private_key) 
    auth_payload = "#{user_id}::#{timestamp}::#{nonce}" 
    token = sign(cert_private_key, auth_payload) 
end 

def authenticate(cert_public_key, token) 
    user_id = extract_user_id(token) 
    valid_token = validate_signature(token, cert_public_key) 

    valid_token ? user_id : nil 
end 

def validate_signature(cert_public_key, token) 
    # False if signature isn't valid cryptographically based on key 
    # False if timestamp isn't recent 
    # False if format isn't legit 
    # Otherwise true 
end 
+0

Спасибо за ответ. Это в основном то, что говорит Героку. В то время как ваш подход хорошо работает с сервисом для обслуживания связи, он не будет работать хорошо для браузеров. В настоящее время мы используем двухфакторное управление через ROTP и изучаем интеграцию yubikey. –

+0

Я провел еще несколько исследований, и один из вариантов с ELB должен был проксировать ваш трафик SSL в пул балансировщиков нагрузки SSL, которым вы управляете, что могло бы реализовать завершение SSL и проверку подлинности на стороне клиента. Это устраняет большую часть значения ELB, imho - но позволит публичный балансировщик нагрузки перед уровнем SSL перед слоем приложения. – Winfield

Смежные вопросы