Как интегрировать OpenID в веб-API MVC4

Я пишу веб-API с использованием MVC4, который должен потребляться несколькими типами клиентов. Я хочу использовать OpenID для аутентификации.

Я уже загрузил пакет DotNetOpenAuth NuGet, но пока все примеры предназначены для клиентского приложения, а не для API.

Моя проблема проста. Я хочу, чтобы клиенты отправляли запрос на аутентификацию в мой API. API аутентифицируется с помощью поставщика OpenID. Затем API устанавливает все, что ему нужно, чтобы использовать теги [Authorize] во всех веб-приложениях api.

Я понимаю, что в .NET-приложениях можно было вызвать форму FormsAuthentication.SetCookie, но это также простое в использовании решение для других языков?

Вопрос в двух словах. Как интегрировать OpenID в MVC4 web api, который позволяет использовать тег Authorize, который можно вызывать и использовать на нескольких языках?

Ответы

Ответ 1

Вы можете вводить в заблуждение роли аутентификации и авторизации. Похоже, ваш веб-API нуждается в обоих.

Начнем с авторизации. Каждый API (т.е. Веб-URL, доступ к которому клиентским приложением, отличным от браузера) либо разрешает анонимный доступ, либо должен быть авторизирован (то есть авторизация). Авторизация - это домен OAuth. OAuth (v2, предположительно) описывает, как клиент разрешает вызов вашего WebAPI.

Предположительно, как часть процесса авторизации, пользователь входит в вашу службу. Этот шаг входа в систему пользователя является аутентификацией. И он ортогонален авторизации. Независимо от того, аутентифицируете ли вы пользователя через OpenID, имя пользователя/пароль, сертификат X.509 и т.д., Вы не должны относиться к тому, как разрешены ваши вызовы WebAPI. Другими словами, ваши методы WebAPI не должны заботиться о том, как пользователь аутентифицировался (читай: никаких ссылок OpenID не имеет). У них будет фильтр авторизации, применяемый к ним, который проверяет авторизацию по входящему запросу и переводит его на несколько частей информации, включая имя пользователя учетной записи, разрешающей доступ, уровень доступа, идентификатор уполномоченного клиент и т.д.

Итак, шаг за шагом, весь сценарий может выглядеть примерно так:

  • Пользователь, управляющий сторонним клиентским приложением (допустим для простоты, что это клиентское приложение является сторонним веб-приложением), хочет использовать функциональные возможности, требующие от клиента доступа к вашему WebAPI в имени пользователя.
  • Клиент должен получить авторизацию для ограниченного олицетворения пользователя, поскольку клиент совершает вызовы в ваш WebAPI. Они начинаются с перенаправления OAuth 2 на конечную точку авторизации. Если это реализовано с использованием DotNetOpenAuth, это может использовать класс WebServerClient.
  • Конечная точка авторизации заполняет роль сервера авторизации OAuth 2 и, как таковая, использует класс DotNetOpenAuth AuthorizationServer. Первое, что он делает, это проверить, есть ли в запросе cookie проверки подлинности форм ASP.NET. Этот файл cookie является естественным признаком того, что пользователь уже зашел в вашу службу в своем браузере, и если да, то кто этот пользователь. Проверка этого файла cookie - это простой вызов Controller.User. Обратите внимание, что конечная точка авторизации - это MVC, а не WebAPI, потому что ее ответ принадлежит браузеру/пользователю, а не клиентскому приложению. Предположим, что такого файла cookie нет, а Controller.User - null (или User.Identity.IsAuthenticated is false). Обратитесь к образцу OAuthAuthorizationServer о том, как реализовать эту конечную точку.
  • Конечная точка авторизации отвечает перенаправлением на страницу входа пользователя, включая параметр redirectUrl в строке запроса, в которой сохраняется полный URL-адрес запроса авторизации OAuth 2.
  • Ваша страница входа в систему - это конечная точка MVC, которая действует как Сторона поддержки OpenID. Эта конечная точка использует класс DotNetOpenAuth OpenIdRelyingParty. Обратите внимание, что эта конечная точка ничего не знает о OAuth 2 или материалах авторизации. Он просто аутентифицирует пользователя. После аутентификации пользователя он перенаправляет обратно URL-адрес в аргументе redirectUrl. Обратитесь к образцу OpenIdRelyingPartyMvc для того, как это сделать.
  • Конечная точка авторизации повторяет свой предыдущий шаг, за исключением того, что на этот раз существует файл cookie FormsAuthentication, поэтому он переходит к отображению страницы пользователю, спрашивая, хотят ли они разрешить клиенту получать доступ к пользовательским данным. Пользователь нажимает "Да". (будьте осторожны: реализуйте XSRF и смягчение кликов на этой странице авторизации пользователя).
  • Конечная точка авторизации обрабатывает положительный ответ пользователя и вызывает AuthorizationServer, чтобы создать запись авторизации и вернуть ответ клиенту. Одним из результатов этого вызова является формулировка ответа перенаправления клиенту, который дает ему код авторизации.
  • Браузер теперь тянет URL-адрес клиентского приложения, которое передает ему код авторизации. Затем клиент использует класс WebServerClient для обмена кодом авторизации для токена доступа (и обычно токена обновления).
  • Клиентское приложение теперь вызывает вызовы на ваши URL-адреса WebAPI напрямую, включая маркер доступа, полученный через OAuth 2 в заголовке HTTP-авторизации.
  • Ваш WebAPI заполняет роль сервера ресурсов OAuth2 и атрибут фильтра авторизации, применяемый к вашим методам WebAPI для проверки входящего токена доступа OAuth 2, использует DotNetOpenAuth ResourceServerкласс для выполнения своей работы. Вы можете обратиться к образцу OAuthResourceServer или, что еще лучше, пример Дэвид Кристиансен WebAPI, как это сделать.

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

Кстати, образцы DotNetOpenAuth, к которым я обращаюсь, не распространяются через NuGet. Вы получите образцы из SourceForge.