Проверка подлинности для функций 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
маркер.
на самом деле это просто смотрит прямо на меня, Я действительно не тестировал его как носитель, поэтому немного осторожности там.
механизм называется Легкий 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 года это не полностью реализовано.