Интегрировать приложение laravel с MS Active Directory, но ограничить пользователей, которые могут получить доступ

Question

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

Я ищу способ интеграции MS Active Directory в качестве опции входа в систему, но хочу иметь возможность ограничить, какие пользователи из бизнеса могут фактически использовать этот метод.

У меня есть поиск по всем документам MS, и у меня есть вся документация по различным подходам oauth, но я не уверен, какой из них подойдет для моих нужд.

Я думаю, что, возможно, мне нужно дать администратору способ просмотреть AD и выбрать пользователей, которые могут войти, который затем создает неактивные учетные записи пользователей в базе данных mysql с каким-то идентификатором пользователя MS. Затем предоставьте кнопку «Войти с MS», которая выполняет обычный процесс перенаправления авторизации на MS и обратно на сайт. В этот момент я могу проверить идентификатор и, если он совпадает с разрешенной учетной записью пользователя, и если да, синхронизировать остальные данные, например, имя, адрес электронной почты, телефон и т. д.

Ссылки, которые я уже нашел:

https://docs.microsoft.com/en-gb/azure/active-directory/develop/authentication-scenarios

https://docs.microsoft.com/en-gb/graph/tutorials/php

https://github.com/microsoftgraph/msgraph-training-phpapp/tree/master/Demos/03-add-msgraph

Answer 1

Ваш первый заказ - дать пользователю возможность войти в приложение на основе Laravel. Для этого я настоятельно рекомендую , а не , пытаясь заново изобрести колесо (по крайней мере, не полностью) и использовать существующий пакет Laravel. Laravel Socialite , пожалуй, лучшее место для начала, поскольку у него есть длинный список существующих предоставляемых сообществом поставщиков Socialite , включая трех, которые уже работают с Azure AD: Microsoft , Microsoft-Graph и Microsoft-Azure . (Примечание: хотя я сам не проверял ни одного из них, первые два кажутся наиболее перспективными, поскольку они используют более новую конечную точку v2.)

Когда дело доходит до авторизации (контроля доступа), у вас есть два варианта:

1. Управление в Azure AD

   После того, как приложение интегрировано с Azure AD, вы можете настроить приложение в Azure AD так, чтобы оно требовало назначения пользователей, а затем управлять доступом к приложению, назначая (или не назначая) пользователей приложению. Пользователи, которые не назначены, даже не пройдут страницу входа.

   Вы можете использовать существующие возможности Azure AD для управления назначением пользователей и ролей для приложения , или вы можете сделать все возможное и встроить этот опыт непосредственно в само приложение на основе Laravel, используя API-интерфейс Azure AD Graph для создания [назначений ролей приложений] (https://docs.microsoft.com/en-us/previous-versions/azure/ad/graph/api/entity-and-complex-type-reference#approleassignment-entity и выбора пользователя.

   Подсказка. В любом случае помните, что вы можете сделать приложение «суперпользователем» «владельцем» приложения в Azure AD (Azure AD> Корпоративные приложения> (приложение)> Владельцы), что позволит им назначать пользователей. без необходимости предоставления им каких-либо дополнительных привилегий в Azure AD.

2. Управление в приложении

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

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

Answer 2

Если вы сделаете это таким образом, необходимо, чтобы супер-администратор всегда имел эти разрешения в AAD. С моей точки зрения это менее практично.

Я бы предпочел такие приложения-приложения с помощью Service Principal. Вы назначаете роль (ищите роли приложения) пользователю, и затем ваша бизнес-логика должна решить, какие разрешения имеет пользователь. Если вы хотите использовать функцию ролей приложения, вы можете ограничить доступ к роли с помощью этой справки. Все пользователи могут войти в систему, но только пользователи с определенной ролью смогут видеть содержимое приложения.

Я надеюсь, что эти подсказки помогут найти правильное направление, но решения для серебряной пули не существует ...: /