Блог

Возможно, это не поддерживается, но я думал о таком сценарии, как этот. Допустим, существует внутренняя конечная точка, которая использует проверку подлинности AD. Если бы нужно было направить вызов Azure APIM на этот серверный сервер, есть ли способ получить конечного пользователя, который, возможно, инициировал вызов конечной точки APIM? Или это не тот сценарий, для которого он предназначался? Предназначен ли APIM больше для вызовов типа «приложение-приложение» и не обязательно для того, что может инициировать конечный пользователь?

Заранее спасибо, Джейк.

Для вашего требования я провел много тестов для этого. Пожалуйста, ознакомьтесь с моими шагами ниже:

Поскольку конечная точка использует проверку подлинности AD, пользователю необходимо предоставить токен при запросе APIM (для запроса конечной точки). Таким образом, мы можем узнать имя пользователя, расшифровав токен, который был предоставлен при запросе APIM. Прежде чем делать это, вам нужно знать, что токен может включать идентификатор пользователя только тогда, когда пользователь использует поток предоставления, такой как поток имени пользователя / пароля или поток кода авторизации. Если пользователь использует поток предоставления, например поток учетных данных клиента, для получения токена, токен не будет включать идентификатор пользователя. Итак, в моем решении я предполагаю, что пользователь использует поток имени пользователя / пароля или поток кода аутентификации для получения токена.

Я провел некоторый тест, я хочу получить токен в заголовке запроса APIM. Поэтому я настраиваю «Диагностические параметры» APIM для потоковой передачи журналов в хранилище Azure (или event hub). Затем запрашивайте журналы на вкладке «Журналы» APIM. Но я обнаружил, что мы не можем видеть заголовки запроса в журналах, оба RequestHeaders BackendRequestHeaders поля и пусты (показано на скриншоте ниже).

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

Но здесь я предоставляю обходной путь для вашей справки:

Я создал функцию Azure с кодом по умолчанию и просто добавил одну строку.

Затем я добавил политику в inbound блок APIM.

 <policies>
    <inbound>
        <base />
        <send-request mode="new" response-variable-name="tokenstate" timeout="20" ignore-error="true">
            <set-url>https://huryxxxxtestfun.azurewebsites.net/api/HttpTrigger6</set-url>
            <set-method>POST</set-method>
            <set-header name="Content-Type" exists-action="override">
                <value>application/json</value>
            </set-header>
            <set-body>@{
                string authHeader = context.Request.Headers.GetValueOrDefault("Authorization", "");
                string name = "unknown";
                if (authHeader?.Length > 0)
                {
                    string[] authHeaderParts = authHeader.Split(' ');
                    if (authHeaderParts?.Length == 2 amp;amp; authHeaderParts[0].Equals("Bearer", StringComparison.InvariantCultureIgnoreCase))
                    {
                        Jwt jwt;
                        if (authHeaderParts[1].TryParseJwt(out jwt))
                        {
                            name = (jwt.Claims.GetValueOrDefault("name", "unknown"));
                        }
                    }
                }
                return new JObject(new JProperty("name",name)).ToString();
            }</set-body>
        </send-request>
    </inbound>
    <backend>
        <base />
    </backend>
    <outbound>
        <base />
    </outbound>
    <on-error>
        <base />
    </on-error>
</policies>
  

<send-request> Политика используется для запроса URL-адреса функции Azure. Я декодирую токен в политике и получаю имя пользователя, отправляю имя в функцию azure. Затем мы можем увидеть имя пользователя в журнале функций Azure.

Кстати, мы также можем получить идентификатор объекта пользователя, изменив код name = (jwt.Claims.GetValueOrDefault("name", "unknown")); name = (jwt.Claims.GetValueOrDefault("oid", "unknown")); в политике.