Проверка подлинности для функций Azure

Я провел последние 24 часа, читая все о том, как создавать функции Azure, и успешно преобразовал MVC WebApi в новое приложение с несколькими функциями. Моя проблема в том, что я не нашел никакой ясной документации или учебников о том, как сделать самую основную аутентификацию с ними.

мой сценарий довольно прямолинейный. Подготовьте пользователей в my AAD, а затем предоставьте этим пользователям доступ к определенным функциям. Пользователи на веб-сайте будут нажимать на элементы UI это, в свою очередь, запускает Javascript, который вызывает мои функции Azure. В функции мне нужно как-то проверить их идентичность, поскольку я передам это другим функциям, которые взаимодействуют с экземпляром SQL.

может кто-нибудь указать мне на документы, статьи, пример, что-то, что показывает, как я могу этого достичь?

для записи я нашел на портале конфигурацию "аутентификация" для моего приложения функции и выбрал AAD в качестве поставщика аутентификации. Я добавлена моя функция приложение к нему и подготовили несколько пользователей. Затем я написал следующую тестовую функцию:

[FunctionName("GetThings")]
public static HttpResponseMessage Run([HttpTrigger(AuthorizationLevel.User, "GET", Route = null)]HttpRequestMessage req, TraceWriter log)
{
    log.Info("Getting all the things");
    var identity = ClaimsPrincipal.Current.Identity;

    return identity.IsAuthenticated ?
        req.CreateResponse(HttpStatusCode.Unauthorized, "Not authenticated!") :
        req.CreateResponse(HttpStatusCode.OK, $"Hi {identity.Name}!");
}

В настоящее время при попытке попасть в конечную точку я перенаправляюсь на страницу входа в систему... думаю, эта часть работает. Однако мне непонятно, как я генерирую / извлекаю пользовательские токены, отправляю их по запросу функциям или обрабатываю их на сервере.

помочь?

2 ответов


после проверки подлинности пользователя с помощью Azure AD вам будет представлен AppServiceAuthSessoin cookie. Это непрозрачный файл cookie, но вы можете обменять его на утверждения, вызвав

https://yourFunctionApp.azurewebsites.net/.auth/me

и передача в непрозрачный cookie как . Более того,id_token вы получаете назад хороши для пользы как Bearer маркер.

на самом деле это просто смотрит прямо на меня, Я действительно не тестировал его как носитель, поэтому немного осторожности там.

Get claims

механизм называется Легкий Auth, легче Google для этого имени.

подробнее о магазине здесь знак -
https://cgillum.tech/2016/03/07/app-service-token-store/

...который говорит, что вы можете захватить претензии, просто прочитав заголовки HTTP, поступающие из браузера пользователя:

доступ к Жетоны

из вашего бэкэнд-кода доступ к этим токенам так же прост, как чтение заголовка HTTP-запроса. Заголовки называются как X-MS-TOKEN-{provider}-{type}. Возможные имена заголовков токенов перечислены ниже:

Заголовки Запросов Маркеров Azure Active Directory:

X-MS-TOKEN-AAD-ID-TOKEN
X-MS-TOKEN-AAD-ACCESS-TOKEN
X-MS-TOKEN-AAD-EXPIRES-ON
X-MS-TOKEN-AAD-REFRESH-TOKEN

Я на самом деле только что узнал это прямо сейчас, так что спасибо за вопрос!

обновление:

моя догадка была верна, то id_token тоже хорошо как носитель:

$ curl -isk https://{funcApp}.azurewebsites.net/api/{someFunc} \
       -H "Authorization: Bearer eyJ0eXAiOi....oEU-Q"

HTTP/1.1 200 OK
Cache-Control: no-cache
Server: Microsoft-IIS/8.0
...

основное различие между двумя способами чтения утверждений (чтение заголовков против вызова /.auth/me из бэкэнда с Cookie пользователя) - это количество деталей, которые вы получаете. В последнем случае гораздо больше.

вот набор заголовки вы получаете от Easy Auth для аутентифицированного пользователя Twitter:

{
   "cookie": "AppServiceAuthSession=Lx43...xHDTA==",
   ...
   "x-ms-client-principal-name": "evilSnobu",
   "x-ms-client-principal-id": "35....",
   "x-ms-client-principal-idp": "twitter",
   "x-ms-token-twitter-access-token": "35...Dj",
   "x-ms-token-twitter-access-token-secret": "OK3...Jx",
}

и претензии, которые вы получаете по телефону /.auth/me:

{
   "access_token": "35...FDj",
   "access_token_secret": "OK3...sJx",
   "provider_name": "twitter",
   "user_claims": [
      {
         "typ": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier",
         "val": "352660979"
      },
      {
         "typ": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn",
         "val": "evilSnobu"
      },
      {
         "typ": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name",
         "val": "Safarihat Hacker"
      },
      {
         "typ": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/webpage",
         "val": "..."
      },
      {
         "typ": "urn:twitter:description",
         "val": "GENIUS. HAVE BRAIN. WILL TRAVEL."
      },
      {
         "typ": "urn:twitter:location",
         "val": ""
      },
      {
         "typ": "urn:twitter:time_zone",
         "val": "London"
      },
      {
         "typ": "urn:twitter:lang",
         "val": "en"
      },
      {
         "typ": "urn:twitter:verified",
         "val": "False"
      },
      {
         "typ": "urn:twitter:profile_image_url_https",
         "val": "https://pbs.twimg.com/profile_images/867473646876545024/1elebfK1_normal.jpg"
      }
   ],
   "user_id": "evilSnobu"
}

AuthorizationLevel.Пользователь в настоящее время не поддерживается функциями azure см. здесь

по состоянию на декабрь 2017 года это не полностью реализовано.