Сценарий междоменной библиотеки SharePoint 2013: механизм аутентификации для удаленного приложения

У меня есть приложение, размещенное провайдером SharePoint, которое предоставляет конечную точку Web API. Я использую эту конечную точку в качестве посредника для вызова защищенного внешнего веб-сервиса. Я хочу совершать вызовы к моей конечной точке веб-API с помощью JavaScript на странице SharePoint (страница публикации) в моем веб-узле. Поскольку это междоменный вызов, я использую междоменную библиотеку SharePoint (SP.RequestExecutor.js). Я выполнил шаги, описанные в этой статье, чтобы создать свою собственную страницу прокси, которая требуется для междоменной библиотеки. Все отлично работает Я могу позвонить в мой сервис через SP.RequestExecutor без проблем. Теперь я просто хочу требовать аутентификацию для доступа к конечной точке Web API.

В статье, на которую я ссылаюсь, говорится, что я отвечаю за механизм аутентификации. Я просто не могу придумать действительно безопасный вариант, и в сети буквально нет примеров. Мне бы очень хотелось как-то использовать личность пользователя SharePoint, поскольку только конечные точки Web API будут попадать только на пользователей SharePoint, я просто не могу понять, как это сделать. SP.RequestExecutor не позволит мне передать параметр строки запроса SPHostUrl при попадании в конечную точку, поэтому я не могу использовать доверительные отношения между SharePoint и удаленным приложением. Есть ли у кого-нибудь идеи для аутентификации в этом сценарии, которые будут хорошо работать при использовании SP.RequestExecutor для вызова моей конечной точки?

Источник

1 ответ

Решение

Подводя итог, у вас есть следующий сценарий:

  • У вас есть надстройка SharePoint (приложение SharePoint).
  • Страница на веб-сайте надстройки (веб-приложение) должна вызывать внешнюю службу.
  • У вас есть внешний сервис, реализованный с использованием ASP.NET Web Api.
  • Внешний сервис нуждается в аутентификации.

Первая проблема, которую вам нужно решить, - это Политика единого происхождения. Чтобы преодолеть эту проблему, документация Microsoft описывает три варианта, как вы знаете:

Тем не менее, я думаю, что лучше всего использовать CORS, потому что это рекомендация W3C, она проще, проще в использовании, всеобъемлющей, без взлома и особенно: ASP.NET Web API 2 поддерживает CORS.

Другая проблема, которую нужно решить, - это аутентификация. К сожалению, документация Microsoft не дает ни примеров, ни подсказок, она просто говорит вам, что это ваша ответственность. Поиск в Интернете не дает ни примера, ни подсказки. Итак, я делаю вывод: вам нужно изобрести механизм аутентификации. Несколько протоколов аутентификации основаны на таких процедурах, как аутентификация NTLM. Проверка адреса электронной почты также использует процедуру, которая позволяет вам прочитать письмо, отправленное на адрес электронной почты. Я предлагаю вам механизм, основанный на той же парадигме. Я предлагаю пользователю создать определенный элемент списка в веб-приложении SharePoint (добавить). Итак, нам нужен список в App Web, который называется AutenticationChalenges со следующими полями:

  • ID: автоинкремент встроенный в поле.
  • ChanlengeValue: одна строка текста.
  • CreatedBy: пользователь, встроенный в поле.

Процесс аутентификации состоит из следующих шагов:

1.- JavaScript на веб-странице приложения вызывает https://myexternalservice.mycompay.com/create-chalenge конечная точка веб-API со следующей полезной нагрузкой:

{
    "UserId": "3432" // the SharePoint UserId
    "AppWebUrl": "https://mysharpointonline-e849d5bbe0ddc2.sharepoint.com/MySharePointApp"
    "HostWebUrl": "https://mysharepointonline.sharepoint.com/MySharePointApp"
}

2. Внешний сервер генерирует два 16-32 байта случайных значений: ChalengeValue а также CorrelationTokenи он вставляет их вместе с полезной нагрузкой в ​​какое-то хранилище, например в следующую таблицу:

CREATE SEQUENCE authentication_chalenges_authentication_chalenge_id_seq
START WITH 1;

CREATE TABLE authentication_chalenges
(
    authentication_chalenge_id int NOT NULL DEFAULT NEXT VALUE FOR authentication_chalenges_authentication_chalenge_id_seq
    CONSTRAINT authentication_chalenges_authentication_chalenge_id_seq PRIMARY KEY,
    user_id int NOT NULL,
    correlation_token binary(16) NOT NULL,
    chalenge_value binary(16) NOT NULL,
    app_web_url varchar(4000) NOT NULL,
    host_web_url varchar(4000) NULL,
    created_timestamp datetime NOT NULL
)

Затем сервер возвращает следующий результат:

{
    "ChalengeId": 31232, // the value of authentication_chalenge_id column of the table
    "CorrelationToken" : "95AE040FE6844345B36B5E33BE03437F",
    "ChalengeValue" : "E38A022B7F744D3BA8C676259AECD607"

}

3.- JavaScript на веб-странице приложения вставляет элемент в AuthenticationChanlenges настройка списка ChalengeValue столбец = "E38A022B7F744D3BA8C676259AECD607" и звонки https://myexternalservice.mycompay.com/login конечная точка веб-API со следующей полезной нагрузкой:

{
    "ChalengeItemId" : 4133, // the ID column of the AuthenticationChalenges SharePoint list
    "ChalengeId" : 31232,
    "CorrelationToken" : "95AE040FE6844345B36B5E33BE03437F",
    "ChalengeValue" : "E38A022B7F744D3BA8C676259AECD607"
}

4.- Внешний сервер служб ищет строку в таблице chalenges:

SELECT * FROM authentication_chalenges WHERE authentication_chalenge_id = 31232

Если запрос возвращает строку и CorrelationToken а также ChanlengeValue совпадение, и оно еще не истекло, сервер подключается к sharepoint в поисках элемента с ID = 4133 на AuhenticationChalenges список и проверяет, что ChalengeValue равно E38A022B7F744D3BA8C676259AECD607и, наконец, это проверяет, что CreatedBy идентификатор пользователя равен 3432, Если все проверки успешны, то он отвечает и ок ответит и устанавливает cookie аутентификации. Если какая-либо из проверок завершается неудачей, она отвечает результатом 401.

Источник
Другие вопросы по тегам