Как реализовать вход в веб-службу RESTful?

Я создаю веб-приложение со слоем услуг. Уровень сервиса будет построен с использованием дизайна RESTful. Мысль заключается в том, что в будущем мы можем создавать другие приложения (iPhone, Android и т.д.), Которые используют тот же уровень обслуживания, что и веб-приложение. Мой вопрос в том, как я могу внедрить логин? Я думаю, что у меня возникли проблемы с переходом от более традиционного глагольного дизайна к ресурсовому дизайну. Если бы я строил это с помощью SOAP, у меня, вероятно, был бы метод под названием "Вход". В REST у меня должен быть ресурс. Мне трудно понять, как я должен создать свой URI для входа. Должно ли быть что-то вроде этого:

http://myservice/ {username}? p = {password}

EDIT: веб-приложение переднего плана использует традиционную структуру ASP.NET для аутентификации. Однако в какой-то момент процесса аутентификации мне необходимо проверить предоставленные учетные данные. В традиционном веб-приложении я бы сделал поиск базы данных. Но в этом случае я вызываю службу вместо того, чтобы выполнять поиск базы данных. Поэтому мне нужно что-то в службе, которая будет проверять предоставленные учетные данные. Кроме того, помимо проверки предоставленных учетных данных, мне, вероятно, также потребуется какая-то информация о пользователе после успешной аутентификации - такие вещи, как их полное имя, их идентификатор и т.д. Надеюсь, это упростит вопрос.

Или я не думаю об этом правильно? Я чувствую, что мне трудно описать свой вопрос правильно.

Кори

ОТВЕТЫ

Ответ 1

Как уже указывал С.Лотт, у нас есть две сложенные вещи: вход и аутентификация

Аутентификация здесь отсутствует, так как это широко обсуждается и существует общее соглашение. Однако что нам на самом деле нужно, чтобы клиент успешно аутентифицировался против веб-службы RESTful? Правильно, какой-то токен, позвольте ему назвать токен.

Клиент) Итак, все, что мне нужно, это токен доступа, но как получить такой RESTfully?
Сервер) Почему бы просто не создать его?
Клиент) Как происходит?
Server) Для меня токен доступа - это не что иное, как ресурс. Таким образом, я создам один для вас в обмен на ваше имя пользователя и пароль.

Таким образом, сервер может предложить URL-адрес ресурса "/accesstokens", для POSTing имя пользователя и пароль, возвращая ссылку на вновь созданный ресурс "/accesstokens/{accesstoken}". Кроме того, вы возвращаете документ, содержащий токен доступа, и href с ссылкой ресурса:

<access-token
  id="{access token id goes here; e.g. GUID}"
  href="/accesstokens/{id}"
/>

Скорее всего, вы фактически не создаете токен доступа как субресурс и, таким образом, не будете включать его href в ответ.
Однако, если вы это сделаете, клиент может создать ссылку от своего имени или нет? Нет!
Помните, что действительно веб-службы RESTful связывают ресурсы вместе таким образом, чтобы клиент мог самостоятельно перемещаться без необходимости создания каких-либо ссылок ресурсов.

Последний вопрос, который вы, вероятно, имеете, - это если вы должны указать имя пользователя и пароль в виде HTML-формы или в качестве документа, например. XML или JSON - это зависит...: -)

Ответ 2

Вы не "входите". Вы "аутентифицируете". Мир разницы.

У вас много альтернатив проверки подлинности.

HTTP Basic, Digest, NTLM и AWS S3 Аутентификация

  • HTTP-аутентификация Basic и Digest. Это использует заголовок HTTP_AUTHORIZATION. Это очень мило, очень просто. Но может привести к большому количеству трафика.

  • Проверка подлинности пользователя/подписи. Иногда называется аутентификацией "ID и KEY". Это может использовать строку запроса.

    ?username=this&signature=some-big-hex-digest

    Это то, что использует Amazon. Имя пользователя - "id". "Ключ" - это дайджест, аналогичный тому, который используется для аутентификации HTTP Digest. Обе стороны должны договориться о том, чтобы дайджест продолжался.

  • Некоторая аутентификация на основе файлов cookie. OpenAM, например, может быть настроен как агент для аутентификации и предоставить файл cookie, который может использовать веб-сервер RESTful. Сначала клиент будет аутентифицироваться, а затем предоставить cookie с каждым запросом RESTful.

Ответ 3

Отличный вопрос, хорошо поставленный. Мне очень нравится ответ Патрика. Я использую что-то вроде

-/пользователей/{имя пользователя}/loginsession

С обработкой POST и GET. Поэтому я отправляю новый сеанс регистрации с учетными данными, и затем я могу просмотреть текущий сеанс как ресурс через GET.

Ресурс - это сеанс входа в систему, который может иметь токен доступа или код аутентификации, срок действия и т.д.

Как ни странно, мой вызывающий MVC сам должен представить токен ключа/носителя через заголовок, чтобы доказать, что он имеет право попробовать и создать новые сеансы входа, поскольку сайт MVC является клиентом API.

Edit

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

Другим решением является поток токена, OAuth или JWT или иначе, что означает, что "вход в систему" ​​уже произошел другим процессом, возможно, обычный пользовательский интерфейс входа в браузер, основанный на форме POST.

Мой ответ для службы, которая находится за этим пользовательским интерфейсом, если вы хотите, чтобы логин и auth и управление пользователями размещались в службе REST, а не в коде MVC сайта. Это служба входа в систему.

Он также позволяет другим службам "входить в систему" ​​и получать истекающий токен вместо использования предварительно открытого ключа, а также тестовых скриптов в CLI или Postman.

Ответ 4

Поскольку с 2011 года изменилось немного...

Если вы открыты для использования стороннего инструмента и слегка отклоняетесь от REST для веб-интерфейса, рассмотрите http://shiro.apache.org.

Shiro в основном дает вам сервлет-фильтр, предназначенный для аутентификации, а также для авторизации. Вы можете использовать все методы входа, перечисленные в @S.Lott, включая простую проверку подлинности на основе форм.

Отфильтруйте остальные URL-адреса, требующие аутентификации, и Сиро сделает все остальное.

В настоящее время я использую это в своем собственном проекте, и до сих пор он работал очень хорошо.

Здесь могут быть заинтересованы другие люди. https://github.com/PE-INTERNATIONAL/shiro-jersey#readme

Ответ 5

Первое, что нужно знать о REST, это то, что его доступ к ресурсам основан на Token. В отличие от традиционных способов доступ предоставляется на основе проверки токена. Простыми словами, если у вас есть правильный токен, вы можете получить доступ к ресурсам. Теперь есть много всего другого материала для создания токенов и манипуляций.

Для вашего первого вопроса вы можете создать API Restfull. Учетные данные (имя пользователя и пароль) будут переданы на ваш сервисный уровень. Затем уровень сервиса проверяет эти учетные данные и предоставляет токен. Критические данные могут быть либо простым именем пользователя/паролем, либо могут быть сертификатами SSL. SSL-сертификаты используют протокол OAUTH и более безопасны.

Вы можете создать свой URI, URI для запроса токена- > http://myservice/some-directory/token? (Вы можете передать Credentilals в этом URI для токена)

Чтобы использовать этот токен для доступа к ресурсам, вы можете добавить этот [Авторизация: Носитель (токен)] в свой http-заголовок.

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

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

Вы также можете следовать этим ссылкам для получения дополнительной информации. http://www.codeproject.com/Articles/687647/Detailed-Tutorial-for-Building-ASP-NET-WebAPI-REST

http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api

Ответ 6

Я столкнулся с такой же проблемой раньше. Вход не очень хорошо переводится на ресурсный дизайн.

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

GET на http://myservice/login?u= {имя пользователя} & p = {пароль}

Ответ - это какая-то сессия или строка auth, которая затем может быть передана другим API для проверки.

Альтернатива выполнению GET в ресурсе входа делает POST, пуристы REST, вероятно, сейчас мне не нравятся:) и передают в себя теги в теле. Ответ будет таким же.