УСПОКОИТЕЛЬНЫЙ сервис аутентификации пользователя

Эй люди, это, кажется, было обсуждением справедливо часто, но я хочу сделать простой, смягченный вопрос вокруг выполнения аутентификации с УСПОКОИТЕЛЬНЫМИ сервисами. Сценарий следующие:

  • Существует система, которая содержит зарегистрированных пользователей для приложения. Система представляет УСПОКОИТЕЛЬНЫЙ API для доступа к этим пользователям.
  • Существует приложение фронтенда, которое имеет форму входа в систему. Приложение может или быть внутренним, или внешним.
  • Приложение фронтенда должно использовать данные в Пользовательской системе для аутентификации пользователя.

Вопрос теперь состоит в том, как аутентифицировать пользователя, учетные данные которого (имя пользователя/пароль) вводятся в клиентское приложение против данных в Пользовательской системе, таким образом, что это безопасно и производительно? Ради этого вопроса предположите, что клиентское приложение является внутренним к своего рода Интранет, но приложения не будут находиться на той же машине и могут только связаться через сервис.

Я понимаю идею наличия приложения, являющегося "гиперсредой, управляемой", но нам необходимо предоставить услуги фильтрации/поиска. Например, рассмотрите ресурсы и API как указано ниже:

  • http://example.com/users
    • ДОБЕРИТЕСЬ - получает всех пользователей (разбитый на страницы, управляемая гиперсреда)
    • POST - создает нового пользователя
    • ПОМЕСТИТЕ/УДАЛИТЕ не поддерживаемый
  • http://example.com/users/ [идентификатор]
    • ДОБЕРИТЕСЬ - возвращает полное представление пользователя с идентификатором = {идентификатор}
    • ПОМЕЩЕННЫЙ - обновляет пользователя, берет в любом предопределенном типе среды
    • УДАЛИТЕ - удаляет пользователя (с соответствующей авторизацией)
    • POST, не поддерживаемый

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

Мысли?

9
задан djunforgetable 7 January 2010 в 05:55
поделиться

3 ответа

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

Вместо этого, просто используйте механизм аутентификации, такой как HTTP Basic или HTTP Digest.

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

.
3
ответ дан 4 December 2019 в 12:18
поделиться

Пасование назад имени пользователя и соли являются ненужными и реальная угроза безопасности.

, Возможно, вы могли рассмотреть этот подход:

Сделали, чтобы клиент передал имя пользователя и пароль к серверу через Стандартная аутентификация

, сервер выбирает зашифрованный пароль для имени пользователя наряду с солью

, сервер шифрует данный пароль с помощью некоторого метода шифрования, с помощью соли для помощи алгоритму (код Ruby следует):

def User.authenticate(login, password)
    ok = false

    user = User.find_by_login(login)

    if user
        #
        #   user contains the salt, it isn't passed from the client
        #  
        expected_password = hash_password(password, user.salt)

        ok = (user.password == expected_password)
    end

    return ok
end

существует несколько мест для использования этого вида подхода, но мне нравится делать это в Стойке.

Последняя точка, сделайте все это на Подключении HTTPS

4
ответ дан 4 December 2019 в 12:18
поделиться

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

Я предлагаю взглянуть на ОАУТ , который был построен для именно этого задача домена.

6
ответ дан 4 December 2019 в 12:18
поделиться
Другие вопросы по тегам:

Похожие вопросы: