Visual Studio 2013 甫於 10/18 正式發行正式版本，且所屬的 Windows Azure SDK for .NET 及 Visual Studio Tools for Windows Azure Platform 2.2 也在隔約四五天後正式發行了，Visual Studio 2013 在 Web 端的重大改變之一就是 ASP.NET 的開發由過去的各自為政整合為單一入口，稱為 “One ASP.NET”，並且導入了一個新的身份識別框架：ASP.NET Identity...
單一簽入 (Single Sign On) 一直是驗證存取權機制的最終境界，整合單一簽入的技術在市場上早已炒到不能再炒了，而且也有相當多的單一簽入解決方案，其中包含 OAuth 1.0/2.0，Open ID，Active Directory，LDAP 等等協定和服務，而在社群網路流行後，幾個重要的大型帳戶儲存庫像 Facebook, Google, Yahoo, Twitter, Plurk, Linked In 等廠商也相繼的開發了認證的 API 群，以支援來自不同設備或用戶端的驗證需求，而在台灣最新的個人資料保護法正式施行前，外部的單一簽入已經成為應用程式認證機制的首選，尤其是小型網站或新進市場的應用程式，透過大廠來處理驗證，使用者不但不用記太多的帳戶密碼，也容易吸引使用者登錄資料...
早期企業在打造應用程式時，除了少數較宏觀的主導者以外，多數都是按照當下的需求以及業務條件來發展的，很少會有考量到軟體特性（例如Scalability、Extensibility、Maintainability等）的規劃。隨著時代的進步，物件導向程式設計與系統分析的發展，讓資訊產業開始重視軟體元件（Software Component）的概念，軟體元件的可重覆使用性愈高，則軟體元件的效益就會愈高，同時也代表該軟體的價值也愈高。但只要是在資訊產業涉足一段時間的人，通常都會知道資訊產業的主流總是掌握在幾個大廠商或是領導社群中，企業需要在不同的廠商標準間將內部所有的系統整併以維持或強化企業的資訊體質...
我們在階段 1 中已經完成了最基本的 DACL 資料結構，能針對簡單的 CRUD 權限做控制，但一般來說權限設定沒那麼簡單 (尤其是複雜度高又講求安全的系統)，很多程式或系統有時無法只單純用 CRUD 就可以解決...
前面兩篇文章已經大略說明了 DACL 的概念，而在本文中，我們來實際建構一個 DACL ...
在前一篇文章中，我簡單的說明了 DACL 的資料結構組成，以及簡單的存取方法，如果資料長度愈長的話，可以設定的權限就愈多，也可以有更多的組合，但資料量仍然可以控制在很小的長度，這是因為在 DACL 中，每個權限都是一個旗標值 (flag)，而一個 bit 就代表一個旗標，所以 bit 多的話旗標就愈多，一個 byte 可以容納 8 個 bits，也就是可以有 8 種旗標，之所以會選擇位元來作為旗標，是因為 bit 的值不是 0 就是 1，單純有力。
判別式存取控制表 Discretionary Access Control List (DACL)，這個自由度頗高的存取控制方法，在 Windows 以及其他作業系統中已行之有年，它最大的特色就是使用者和群組可以擁有自己的存取控制設定，而系統物件也可以擁有自己的存取控制項目，也就是說系統物件不會只有 CRUD 四種權限，還可以因為物件的特性而定義額外的權限，例如存取詮釋資料 (metadata), 列印 (printing) 或是下載檔案 (download) 等權限，discretionary 這個字有 "任意的"，"無條件的" 的意思，而 DACL 也是讓消費者和生產者可以擁有自己的權限設定，只需要在存取時進行檢查即可。
最近做了幾個在 Windows Azure 上架設服務的案子，都有涉及到使用 Windows Azure Platform 的費率的計算 (要報價用)，所以在費率的評估上略有心得，特別整理一下給未來想要使用 Windows Azure Platform 的參考。
筆者所講授的研討會或教育訓練課程 (可公開的) 的簡報彙總庫，可取用，但請註明來源，且此處資訊將不定期更新。