SharePoint 2013 開發——APP安全模型

除非開啟了SharePoint網站的匿名訪問，否則對於入站的請求，必須要有一個身份驗證的過程（Authentication），這個很重要。

SharePoint身份驗證依賴於目錄服務（如AD、identity providers（IdPs）像Google和Facebook），服務（如IIS、Azure Access Contro Service（ACS），以及Active Directory Services（ADFS）來實現它的身份驗證業務邏輯。

基於程式設計模型的改變，SharePoint 2013需要處理兩種型別的認證：使用者認證和APP認證。對於使用者認證，SharePoint使用安全組和儲存在內容資料庫中的Access Control List（ACL）來跟蹤，但是對於APP，SharePoint使用了另一種方式。APP的認證通過ACS來提供給SharePoint，叫做OAuth（OAuth 2.0是OAuth的下一個版本，需要HTTPS）。這種架構使得使用者可以授權APP去代表他們工作而不需要儲存他們的憑據資訊。

當SharePoint收到一個入站請求時，會檢查請求中是否包含標識使用者身份的登入令牌，如果找到該令牌，SharePoint就假定該請求是由通過驗證的使用者發出的而不是APP。然後SharePoint會檢查請求的目標URL指向的是一個標準的網站還是與APP有關係的子網站（APPWeb）。如果該請求指向了一個標準的網站，那麼SharePoint 2013會遵循之前版本典型的認證過程；如果是與APP相關的話，則會初始化一個包含使用者認證和APP認證的上下文（context）。

如果沒有找到登入令牌，SharePoint就知道這不是使用者發起的請求。在這種情況下，SharePoint會尋找OAuth令牌來識別遠端應用。當找到安全令牌之後，它會建立包含APP認證和使用者認證（可選）的上下文。

身份認證（Authentication）之後再來看授權（Authorization）。上下文建立之後，SharePoint會決定授予APP什麼樣的許可權，跟使用者許可權一樣，SharePoint通過自身的內部內容資料庫來跟蹤授權。

具體的認證授權流可參加下圖，更多資訊。

每個APP都有一個manifest.xml清單檔案，開發人員可以在這裡通過AppPermissionRequests節點來定義APP需要訪問的資源列表，下面的程式碼片段提供了一個示例（provider-hosted APP）：

<AppPermissionRequests AllowAppOnlyPolicy="true">
  <AppPermissionRequest Scope="http://sharepoint/content/sitecollection"   Right="Read"/>
  <AppPermissionRequest Scope="http://sharepoint/content/sitecollection/web/list"   Right="Write">
    <Property Name="BaseTemplateId" Value="101"/>
  </AppPermissionRequest>
  <AppPermissionRequest Scope="http://sharepoint/userprofilestore/feed"   Right="Post"/>
  <AppPermissionRequest Scope="http://exchange/calendars" Right="Schedule"/>
</AppPermissionRequests>

注意這裡面的第一行，APP的許可權請求啟用了app-only策略，它意味著只有APP（沒有當前使用者）需要必要的許可權。如果沒有使用該策略，則表示APP和當前使用者都需要必要的許可權來完成任務如訪問整個網站集或在列表中建立專案，這會使上下文同時包含APP和使用者的身份。

app-only策略可以提高APP的許可權，使得它可以比當前使用者做更多的事。當使用者安裝包含AppPermissionRequest條目的APP時，該使用者必須在安裝時授予APP清單中宣告的許可權。

ACS不能在本地部署的非Office 365環境中使用，意味著本地部署也沒有OAuth令牌。本地APP需要使用一種不同的安全令牌，該令牌由Server-to-Server（S2S）配置建立，更多資訊。

關於APP的安全，我們還應該知道以下事情：

APP執行在它們自己的域內（防止跨網站指令碼攻擊），用JavaScript編寫，但這並不意味著它們是安全的。作為開發人員，仍需考慮因為APP的設計導致的安全漏洞和敏感資訊洩漏的問題。

SharePoint-hosted APP沒有指定列表或網站級別的授權，換句話說，如果一個APP對一個列表有寫入許可權，它對另一個列表也有。

當使用者為provider-hosted APP授權的時候，這是一個一次性過程，即使之後APP的邏輯程式碼改變了，SharePoint對此也並不知情。

當APP使用OAuth令牌來完成一些任務時，頁面上另一個APP也可以使用該APP的身份和使用者的身份。在這種情況下，黑客可以通過不安全的通訊協議（HTTP）來攔截OAuth令牌。

所以，我們在開發APP時，需要用心設計並儘量使用HTTPS來加密通訊協議。