Авторизуйте доступ к Azure, используя принципала

Question

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

Как настроить Azure:

• Создание и настройка принципала службы: В Active Directory я создал приложение, создал ключ (пароль),и установите необходимые разрешения для доступа к хранилищу Azure;

• Настройка IAM хранилища Azure: в разделе «Учетные записи хранилища» я выбрал свою учетную запись хранения, а в разделе «IAM» назначил свою учетную запись (мою учетную запись для входа в систему как XYZ @ hotmail.com) в Хранитель BLOB Data Contributor роль.

Как использовать конфигурацию в моем клиентском приложении:

1. С вышеупомянутымконфигурации;мое приложение берет идентификатор арендатора, идентификатор клиента, секрет клиента и т. д. и отправляет запрос авторизации на конечную точку /authorize.
2. Затем появляется окно и запрашивает вход в систему (например, XYZ @ hotmail.com), а затем появляется окно согласия и запрашивает мое разрешение, чтобы разрешить субъекту службы читать мое хранилище Azure.
3. После подтверждения мое клиентское приложение получает OAuth2.0 code.
4. Затем я обмениваю это code на access_key через конечную точку /token.

В1: даёт ли это access_key моему клиентскому приложению те же привилегии, что и XYZ@hotmail.com или субъекту обслуживания?

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

Q2: если XYZ@hotmail.com не имеет доступа на чтение / запись (т. Е. Ему не назначена роль Storage BLOB Data Contributor ), мое клиентское приложение не сможет читать/ написать для блоба, независимо от роли руководителя службы .Вот где я запутался, у меня сложилось впечатление, что мое клиентское приложение принимает принципала обслуживания, поэтому оно будет иметь те же привилегии, что и принципал обслуживания, а не XYZ@hotmail.com.Например, XYZ@hotmail.com может иметь роль Contributor (т. Е. Чтение / запись), а принцип обслуживания будет назначаться с ролью Reader .В этом случае у меня будет полный доступ к хранилищу BLOB, а мое клиентское приложение будет иметь доступ только для чтения к хранилищу BLOB.Однако, похоже, клиентское приложение получает те же разрешения, что и XYZ@hotmail.com.Что мне здесь не хватает?

Answer 1

Q1: предоставляет ли этот access_key моему клиентскому приложению те же привилегии, что и XYZ@hotmail.com или субъекту обслуживания?

Полученный access_token имеет делегированные разрешения , которыеот XYZ@hotmail.com.Это потому, что вы использовали Поток предоставления кода авторизации .

Чего мне здесь не хватает?

Для вашего сценарияЯ предлагаю вам использовать client_credentials flow для вашего приложения.

С потоком client_credentials вы получите токен доступа только с разрешениями приложения, настроенными в AAD. Кроме того, этот токен доступа фактически является частью вашего AAD-приложения.Если вы назначите роль субъекту службы, вы получите токен доступа с разрешением этой роли.

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