2

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

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

ответ

1

Итак, у вас есть следующий сценарий:

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

Первый номер, который вам нужно указать, - Same Origin Policy. Чтобы преодолеть эту проблему, документации Microsoft описывает три варианта, как вы знаете:

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

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

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

proccess аутентификации имеет следующие этапы:

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

{ 
    "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 на веб-странице App вставляет элемент в список AuthenticationChanlenges настройки ChalengeValue столбец = "E38A022B7F744D3BA8C676259AECD607" и вызывает https://myexternalservice.mycompay.com/login веб-апи конечную точку со следующим Полезная нагрузка:

{ 
    "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 списке, ANDS проверяет, что ChalengeValue будет равна E38A022B7F744D3BA8C676259AECD607, и наконец, он проверяет, что идентификатор пользователя CreatedBy равен 3432. Если все проверки успешны, тогда он отвечает и отвечает нормально и устанавливает cookie аутентификации. Если какая-либо из проверок терпит неудачу, она отвечает результатом 401.