Группы AAD утверждают, что у некоторых пользователей отсутствует токен JWT

У меня странное поведение на нашем AAD. После того, как пользователь вошел в систему успешно, мы получаем неавторизованный доступ для некоторых пользователей к нашим вызовам API. Оказывается, претензия в JWT отсутствует. Некоторые пользователи получают утверждение "группы" (массив всех идентификаторов групп, к которым он принадлежит), а некоторые получают утверждение "hasgroups" (логическое значение, если у пользователя есть группы, без идентификаторов). Поскольку наше приложение API проверяет это утверждение "группы" для авторизации, пользователи, у которых нет этого утверждения "группы", получают сообщение 403.

Тем не менее, в манифесте регистрации приложения я установил для groupMembershipClaims значение «null» на «All» или «SecurityGroup», что должно помочь в обоих случаях. Также установите для параметра oauth2AllowImplicitFlow значение true, поскольку мы работаем с приложением Angular, которое использует OAuth2. Кроме того, я сравнил почти все настройки пользователей, и, за исключением некоторых дополнительных групп, пользователи идентичны.У затронутых пользователей не так много групп, у некоторых даже около 5 групп максимум.

Я что-то упускаю из виду или что вызывает такую ​​разницу в претензиях? Как я могу решить эту проблему, чтобы все пользователи получали заявку на «группы»?


jwt oauth-2.0 azure-active-directory azure-ad-b2b
person ReBorn    schedule 18.08.2017    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Получил этот отзыв от внутреннего устройства MSFT:

В неявном потоке oauth вернет Jwt непосредственно из вызова intial / authorize через параметр строки запроса. Спецификация http ограничивает длину строки запроса / URL-адреса, поэтому, если AAD обнаруживает, что результирующий URI превышает эту длину, они заменяют группы утверждением hasGroups.

И это

Это сделано специально при использовании неявного потока предоставления, независимо от параметра groupMembershipClaims в манифесте. Это необходимо, чтобы избежать превышения ограничения длины URL-адреса браузера, поскольку токен возвращается как фрагмент URI. Таким образом, более или менее после членства в группах 4 пользователей вы получите в токене «hasgroups: true». Что вы можете сделать, так это сделать отдельный вызов Graph API для запроса членства пользователя в группе.

Поэтому нужно будет сделать дополнительный обход Graph API, чтобы получить группы пользователей. Надеюсь, это поможет и другим.

person ReBorn    schedule 27.08.2017
comment
Спасибо за этот ответ. Это действительно помогло мне после многих часов работы и множества попыток. - person Thiago Custodio; 04.04.2018

arrow_upward
0
arrow_downward

Теперь это задокументировано в справочнике по токенам Azure AD по адресу https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-token-and-claims.

Для неявного потока предоставления OAuth2 он использует токен hasGroups, и в документации для этого токена указано:

Используется вместо утверждения groups для JWT в неявных потоках предоставления, если утверждение о полных группах расширяет фрагмент URI за пределы ограничений длины URL (в настоящее время 6 или более групп).

Для других потоков:

если количество групп, в которых находится пользователь, превышает предел (150 для SAML, 200 для JWT), тогда к источникам заявок, указывающим на конечную точку Graph, содержащую список групп для пользователя, будет добавлено избыточное утверждение.

Вы можете использовать Graph API для получения групп пользователей с помощью https://graph.windows.net/{tenantID}/users/{userID}/getMemberObjects.

В качестве альтернативы есть конечная точка в https://graph.windows.net/myorganization/isMemberOf?api-version, как описано в https://msdn.microsoft.com/library/azure/ad/graph/api/functions-and-actions#isMemberOf

person Ben T    schedule 27.07.2018