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

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

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


asp.net-web-api sharepoint-online sharepoint sharepoint-apps
person brennaman3    schedule 13.02.2015    source источник

Ответы (1)


arrow_upward
1
arrow_downward

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

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

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

Однако я думаю, что лучше всего использовать CORS, потому что это рекомендация W3C, она проще, удобнее в использовании, всеобъемлющая, не требует взлома и особенно: Веб-API ASP.NET 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.- Сервер внешних служб ищет строку в таблице задач:

SELECT * FROM authentication_chalenges WHERE authentication_chalenge_id = 31232

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

person Jesús López    schedule 28.08.2015