Уточнение аутентификации OWIN в веб-приложении MVC

Question

Я работаю над решением с другими, где мы построили веб-проект Visual Studio с использованием MVC (5, я думаю) и WebApi2.0.

Характер решения состоит в том, что он имеет 2 DAL, один из DAL использует SQL для доступа к другой базе данных приложений, другой DAL использует код сущности для управления нашей базой данных приложений. Существует также услуга, связанная с проектом, поэтому мы приложили все усилия, чтобы адаптировать все решение к трехуровневой схеме. Это означает, что есть проект, который содержит наш BusinessLogic, и наш сервис, и наши Контроллеры используют его для доступа к DAL.

Так что все это в стороне ... Мы теперь добавляем аутентификацию на веб-странице. Мы застряли в течение нескольких дней, пока мы просто не приняли стандартную структуру Microsoft по умолчанию с аутентификацией OWIN. Недостатком является то, что теперь у нас есть отдельная пользовательская база данных, которая в основном связана с уровнем Presentation/Web решения.

Есть ли способ сохранить все удобства аутентификации OWIN по умолчанию в проекте MVC И абстрагировать его в LogicLayer? Я не могу опубликовать то, над чем мы работали, но, разумеется, каждый раз он терпел неудачу, потому что мы действительно пытаемся определить, что делается для нас за кулисами (например, [сборка: OwinStartupAttribute (typeof (AlarmAggregator. Startup))]). Только эта аннотация позволяет мне думать, что мы НЕ сможем ее абстрагировать. Я знаю, что я прошу иметь торт и съесть его, но я надеялся, что у кого-то есть понимание, если это возможно.

По крайней мере, мы надеялись, что мы могли бы объединить нашу внутреннюю базу данных и нашу базу данных пользователей? Я думаю, что это должно было произойти на уровне контекста? Было бы так же просто, как указывать наш web.config на наш внутренний контекст?

Answer 1

Поскольку вы не упомянули, что такое две базы данных, я предполагаю, что они не являются пользовательскими базами данных и не имеют контекста. Сосредоточив внимание на хранилище идентификаторов пользователей, да, это будет отдельный объект, если вы не используете ADFS, LDAP или что-то еще. Я бы отговорил вас от создания собственного решения для идентификации, вместо того, чтобы искать что-то более широко используемое и принятое, потому что это тема безопасности.

Посмотрите на Thinktecture Identity Server. Это открытое исходное решение OpenId Connect, встроенное в .NET. Он поставляется с собственной базой данных, поддерживает однопользовательский SSO, аутентификацию на основе файлов cookie и поддерживает открытый идентификатор. Он также поддерживает федеративную аутентификацию, если вы хотите подключить ADFS. Также возможно сделать социальный знак в интеграции с ним.

У меня есть интегрированные решения .NET, Java и PHP в одном экземпляре, и все просто фантастично и без проблем.

Вы можете разместить его как отдельную услугу. Вы можете зарегистрировать известных клиентов (ваши приложения и службы), их входящие и перенаправляющие URL-адреса, в том числе URL-адреса отправления, так что ваше приложение может беспрепятственно обращаться и возвращаться с сервера идентификации. Сервер Identity поставляется со всем промежуточным программным обеспечением, которое необходимо защитить ваши API и веб-приложения. Он также предоставляет конечные точки REST для получения и проверки токенов доступа среди других.

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

Значительная часть того, о чем я говорю, имеет непосредственное отношение к спецификациям oAuth 2.0, поэтому, вероятно, вы можете немного прочитать об этом here, если вы не знаете об этом.

Использование типичного потока oAuth (например,g неявный поток потока или потока авторизации), подключая правильное промежуточное ПО в конвейере Owin и украшая ваши ресурсы API атрибутом [Authorize], ваше приложение будет перенаправляться на страницу сервера идентификации, где пользователь может войти в систему. Ваши API-интерфейсы (защищенный ресурс) могут указывать, ожидаются ли они для конкретной области, когда присутствует токен, и позволяют принять/отклонить ваш запрос на основе этого.

Регистрация клиента гарантирует, что только серверы идентификации будут приниматься только известными клиентами (поскольку приложения, как правило, обращены к Интернету), и вы можете либо использовать компонент MembershipReboot, также и Thinktecture (также openource) в качестве своего хранилища удостоверений или написать собственную реализацию «службы пользователя». Существует слишком много точек расширения, доступных для игры, и вы можете практически настроить все, включая внешний вид страниц сервера идентификации, в соответствии с схемой пользовательского интерфейса ваших клиентских приложений. Существует IUserService (чтобы подключить собственное хранилище пользователей, ViewLoader, чтобы настроить пользовательский интерфейс, службу политики CORS, чтобы указать разрешенные источники для каждого клиента, основанный на сертификатах TokenSigningService для подписывания токенов (токены доступа/обновления), ScopeStore, ClientStore, TokenHandleStore (для хранения областей, клиентов конфигурации, токены), ClaimsFilters для фильтрации того, какие претензии включены, когда выдается токен, что полезно при использовании внешних поставщиков, которые могут вернуть дополнительную информацию, которую вам нужно сохранить или предоставить)

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

Вы можете запустить его за 30 минут на локальной машине с настройками баз данных Identity Server и MembershipReboot. Поддержка очень хороша для авторов, и это очень широко распространенное решение для аутентификации пользователей и авторизации.

Например, обеспечение WebAPI супер просто: 1. украсить API, с [Authorize] и или [ScopeAuthorize] зависимости от ваших потребностей 2. Это говорит о API, чтобы пойти и проверить, если у вас есть что-то настройки для авторизации в Owin трубопровод. 3. При запуске Owin просто использовать:

app.UseIdentityServerBearerTokenAuthentication(new IdentityServerBearerTokenAuthenticationOptions() 
      { 
       Authority = "http://your-idserver-url" 
      }); 

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

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