Работа над проверкой концепции, включающей веб-приложение ASP. NET Core 2.1, использующее MSAL для аутентификации в AD FS 2019 (v5.x) через тип предоставления OAuth 2.0 Client Credentials чтобы получить токен доступа, который впоследствии будет использоваться веб-приложением ASP. NET Core для вызова внутреннего веб-API.
Аутентификация работает отлично, но мы хотим, чтобы AD FS прошел утверждение, которое он получает в клиентском утверждении JWT обратно в полученном маркере доступа (также JWT), который AD FS генерирует и отправляет обратно клиенту.
Пример подписанного клиентского утверждения, которое мы создаем и отправка в AD FS (с использованием MSAL v4.6.0, с использованием метода WithClientAssertion() для ConfidentialClientApplicationBuilder) выглядит следующим образом (при декодировании - некоторые детали были изменены по соображениям конфиденциальности):
Заголовок:
{
"alg": "RS256",
"kid": "D15B382A913303060B26CDF497F3083522A3ADE3",
"typ": "JWT",
"x5t": "0Vs4KpEzAwYLJs30l_MINSKjreM"
}
Полезная нагрузка:
{
"aud": "https://our.internal.adfs.host/adfs/oauth2/token",
"iss": "2324fca8-c413-460f-9658-113d124ca2d1",
"jti": "456f9e07-bae4-442d-83f5-a10f0d0bc7d6",
"sub": "2324fca8-c413-460f-9658-113d124ca2d1",
"custom_claim": "Custom value.",
"exp": 1578875907,
"iat": 1578872307,
"nbf": 1578872307
}
Обратите внимание на утверждение "custom_claim", которое мы добавили в утверждение клиента JWT. На стороне ADFS мы настроили описание заявки для этой настраиваемой заявки и установили настраиваемое правило прохождения заявки, которое приводит к следующему коду языка утверждений:
c:[Type == "http://some.com/custom_claim"]
=> issue(claim = c);
Просто чтобы быть Конечно, у нас также есть другое правило, которое, как я понимаю, должно проходить через все утверждения, независимо от типа:
x:[]
=> issue(claim = x);
И у нас есть другое правило, которое вместо того, чтобы пытаться пройти через входящее утверждение, просто заставляет AD FS сгенерируйте жестко запрошенную заявку на «роль» с нуля:
=> issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/role", Value = "WebApiRole");
Обратите внимание, что мы используем «Группы приложений» в AD FS.
Аутентификация работает и маркер доступа, полученный обратно из AD FS, выглядит вот так (при декодировании - некоторые детали изменены по соображениям конфиденциальности):
Заголовок:
{
"typ": "JWT",
"alg": "RS256",
"x5t": "AZxyHfwAdI_vOhixPV7ocphCprk",
"kid": "AZxyHfwAdI_vOhixPV7ocphCprk"
}
Полезная нагрузка:
{
"aud": "https://our.internal.webservice.host",
"iss": "http://our.internal.adfs.host/adfs/services/trust",
"iat": 1578873409,
"nbf": 1578873409,
"exp": 1578877009,
"role": "WebApiRole",
"auth_time": "2020-01-12T23:56:49.006Z",
"authmethod": [
"http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/x509",
"http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/tlsclient"
],
"sub": "2324fca8-c413-460f-9658-113d124ca2d1",
"anchor": "sub",
"appid": "2324fca8-c413-460f-9658-113d124ca2d1",
"apptype": "Confidential",
"endpointpath": "/adfs/oauth2/token/",
"insidecorpnetwork": "true",
"clientreqid": "605dae38-c19a-4958-813c-dbc961ae9fc0",
"clientip": "x.x.x.x",
"userip": "x.x.x.x",
"ver": "1.0",
"scp": ".default"
}
Обратите внимание, что мы используем сертификат на основе аутентификация, отсюда и значение "http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/x509" в коллекции "authmethod", но я думаю, что это не имеет никакого отношения к нашей проблеме. Также обратите внимание, что утверждение «роль» было добавлено, как и ожидалось.
В настоящее время проблема заключается в том, что независимо от того, что мы делаем, мы не можем заставить AD FS пройти через любые утверждения от входящих подтверждение клиента на полученном токене доступа. Мы можем заставить AD FS сгенерировать новую заявку и добавить ее в маркер исходящего доступа (как в приведенной выше заявке о «роли»), но, похоже, сквозная передача не работает для нас.
Может кто-нибудь предложить что-то мы можем отсутствовать здесь?