не получает идентификатор пользователя в JWT используется в маркер доступа oauth2 из ADFS 3,0

Question

Я использую поток авторизации, поддерживаемый в ADFS 3.0 следующим образом,

1. браузер подключается к MyService
2. MyService перенаправляет браузер ADFS для OAuth
3. браузер подключается к ADFS для OAuth кода авторизации
4. ADFS аутентификацию пользователей через браузер
5. ADFS перенаправляет браузер обратно MyService вместе с а.е. thorization код
6. браузер подключается к MyService и передает разрешение маркеров
7. MyService подключается к ADFS и получает маркер доступа от авторизации маркеров

Однако маркер доступа отсутствует идентификатор пользователя и MyService неспособна для идентификации пользователя.

Токен доступа имеет следующую информацию JWT.

{ "ауд": "урна: полагаясь: партия: доверие: идентификатор",
"ИСС": "http://ms.cloud.com/adfs/services/trust",
"IAT": 1452875046,
"ехр": 1452878646,
"auth_time": "2016-01-15T15: 35: 20.248Z",
"authmethod": "урна: оазис: имена: дц: SAML: 2,0: переменный ток: классы: PasswordProtectedTransport",
«веры ":" 1.0 ",
" appid ":" my-app " }

Может ли кто-нибудь сообщить мне, как может MyService идентифицировать пользователя, как только он получит токен доступа из ADFS?

Answer 1

Правилам требований в отношении доверия доверенных лиц необходимо определить претензии, которые должны быть отправлены как часть токена JWT. Как только мы добавили правила претензии для электронной почты, имя и т. Д., Информация была добавлена ​​в токен доступа JWT.

Answer 2

1. Редактировать Provider Trust Требования к Active Directory в ADFS пройти хотя электронной почты, имя и т.д.

   • Open ADFS. Нажмите «Trusts Provider Claims». Нажмите «Active Directory».
   • Затем нажмите «Изменить правила подачи» справа. Теперь вы должны увидеть диалоговое окно «Редактировать претензии». Инструкции по добавлению претензий см. В этом видео. Пропустить во временной индекс 2:40. Edit Claims Provider Rules

2. Редактировать полагающейся претензии Party треста. Для электронной почты, имени и т. Д. Добавьте соответствующее правило преобразования эмиссии с использованием LDAP в качестве типа правила и выберите Active Directory в качестве источника хранилища атрибутов. Сделайте это, повторив вышеуказанные шаги для доверия доверяющей стороны, связанного с вашим клиентом JWT. Чтобы добавить полагающуюся сторону претензии, обратитесь к этому видео и перейдите к индексу времени 14:35 Edit Relying Party Claim Rules

Я рекомендую прохождение SAM-Account-Name через, как http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name. Я смутно помню WIF с проблемами/w ClaimsPrincipal, если вы этого не сделаете.

Кроме того, вы должны включить поддержку утверждений в Active Directory, если вы еще этого не сделали.