Метод авторизации для REST API с использованием Active Directory

Ответ 1

В системе есть две "роли", у пользователей будет одна из ролей. Одна роль должна обеспечивать доступ к некоторым API (назовите ее "VIEW" ), другая роль обеспечивает доступ к другим API

• Для проверки подлинности на основе ролей вы можете использовать [Авторизовать ( "Роль" = "Менеджер" )]. Маркер будет предоставлен сервером идентификации и будет содержать заявку как Роль.

Все пользователи находятся в Active Directory, поэтому, если у меня есть имя пользователя, я могу проверить, какую роль они играют. Некоторые клиенты находятся в окнах Windows, другие находятся на Linux

• Если у вас есть ADFS, у вас может быть сервер Identity, который доверяет ADFS. ADFS предоставит токен, который будет претендовать на роль, и ваш Identity Server выполнит преобразование претензий и вернет ту же заявку на роль обратно в приложение angular.

Я бы хотел продолжить сессию, поэтому мне не нужно искать AD для каждый вызов API

• Для этого при запросе маркера вы можете запросить автономную область, чтобы сервер Identity предоставил Refresh Token с помощью Access Token, поэтому вам не нужно запрашивать AD снова и снова.

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

• Для этого вы можете доверять своему удостоверению Identity WSFederation для проверки подлинности Windows.

Итак, в основном вам нужно настроить Identity-сервер, который предоставит вам токен, и REST API будет использовать этот токен, чтобы проверить, что претензии возвращают правильную информацию обратно пользователю.

Ответ 2

Я не уверен, чего вы ожидаете. Во всяком случае, сначала я переформулирую ваш вопрос с требованиями:

• ваши учетные записи и роль находятся в активной директории
• вы хотите управлять ролями на основе активной группы каталогов
• вы хотите, чтобы кто-либо, независимо от системы (windows, linux, mac, mobile...), подключался к вашему приложению с использованием той же аутентификации
• вы хотите, чтобы ваш AD не ударялся постоянно (не при вызове, например)
• Если пользователь подключен к приложению, использующему систему аутентификации, ему не нужно делать это снова в другом приложении, использующем ту же систему аутентификации

Если эти требования являются вашими. Я считаю, что единственным стандартным (и чистым) решением является использование OAuth. Я не собираюсь подробно описывать OAuth, но этот протокол аутентификации является самым стандартным в сети (facebook, google, twitter...). Конечно, поскольку вы не хотите использовать учетные записи facebook, google или twitter в своих бизнес-приложениях, но в ваших активных учетных записях каталогов вам нужно будет установить/настроить/развить свой провайдер идентификации OAuth, используя учетные записи вашего активного активного сервера каталогов. Ваш выбор будет зависеть от того, насколько хорошо вы знаете протокол ADFS и его разные потоки (код, неявный, assersion). У вас есть два решения для этого:

• Использовать ADFS: установить ADFS; он предоставляет портал OAuth, который будет работать из коробки с asp.net mvc. Это использует поток кода OAuth, который является единственным потоком OAuth, поддерживаемым ADFS. Для ролей и связанных с ним групп AD вам придется сопоставлять заявки на роль с группами AD. (он в настройке adfs, вы найдете много туто в сети). Вы также найдете множество тутонов о том, как использовать ADFS с asp.net mvc/asp.net webapi. Я упоминаю здесь .net, но каждая технология имеет реализацию для аутентификации OAuth (nodeJs/express, php, java...).
• Использовать сервер идентификации thinktecture (технология .net). Это обеспечит все основы для создания пользовательского сервера идентификации с минимальными усилиями: http://www.thinktecture.com/identityserver/https://github.com/IdentityServer/IdentityServer3. Он содержит addin для подключения учетных записей к активному каталогу. При этом вы можете использовать неявные и потоки утверждения.
• Используйте oauth2orize (для nodeJs): https://www.npmjs.com/package/oauth2orize. Это позволит вам сделать то же самое, что и сервер идентификации thinktecture, но в nodeJs. Очевидно, вам нужно будет сделать все wirering с объявлением вручную. При этом вы можете использовать неявные потоки (не уверены в потоках утверждения).

На стороне приложения большинство фреймворков могут легко аутентифицироваться с использованием OAuth с большим количеством существующих фреймворков. Например, даже если вы создаете одностраничное приложение, вы можете использовать adal.js или adal.js для angular, если вы используете angular. Как я уже упоминал выше, все это происходит в результате изменения asp.net mvc/webapi из коробки, но я знаю, что это относится к другим серверным технологиям. Если у вас больше вопросов, не стесняйтесь, поскольку я не уверен, чего вы ожидаете.