SAML，全稱為Security Assertion Markup Language，是一種用于安全性斷言的標記預壓，目前的最新版本是2.0。原文地址
本系列相關文章：
OAuth2.0 協議入門指南
OpenID Connect 協議入門指南
OpenSAML示例
SAML在單點登錄中大有用處：在SAML協議中，一旦用戶身份被主網站（身份鑒別服務器，Identity Provider，IDP）認證過后，該用戶再去訪問其他在主站注冊過的應用（服務提供者，Service Providers，SP）時，都可以直接登錄，而不用再輸入身份和口令。
SAML本身是一個很復雜的協議，這里只選取最重要的部分為大家講解，更多細節請見官方文檔，后續的文章也會進一步解析。
SAML協議的核心是: IDP和SP通過用戶的瀏覽器的重定向訪問來實現交換數據。
SP向IDP發出SAML身份認證請求消息，來請求IDP鑒別用戶身份；IDP向用戶索要用戶名和口令，并驗證其是否正確，如果驗證無誤，則向SP返回SAML身份認證應答，表示該用戶已經登錄成功了，此外應答中里還包括一些額外的信息，來卻確保應答被篡改和偽造。
下面我們以用戶登錄SP，SP向IDP發起請求來確認用戶身份為例子，看看SAML的工作流程。比如SP是Google的Apps，IDP是一所大學的身份服務器，Alice是該大學的一名學生。
現在Alice要通過瀏覽器查閱她的郵件，Alice一般會通過瀏覽器訪問一個網頁，比如https://mail.google.com/a/my-university.nl (step1)。因為這是個聯合身份域，所以Google不會向用戶索要用戶名和密碼，而是將其從定向到IDP來認證其身份（step3）。用戶被重定向的URL類似于這種：
https://idp.uni.nl/sso?
SAMLRequest=fVLLTuswEN0j8Q…c%3D
嵌入到HTTP請求中的SAMLRequest就是SAML認證請求消息。因為SAML是基于XML的（通常比較長），完整認證請求消息要經過壓縮（為Url節省空間）和編碼（防止特殊字符）才能傳輸。在壓縮和編碼之前，SAML消息有如下格式：
<AuthnRequest ID="kfcn...lfki"
Version="2.0"
IssueInstant="2013-02-05T08:28:50Z"
ProtocolBinding="urn:oasis:names:tc:SAML: 2.0:bindings:HTTP-POST"
ProviderName="google.com"
AssertionConsumerServiceURL="https://www.google.com/a/uni.nl/acs">
<Issuer>google.com</Issuer>
<NameIDPolicy AllowCreate="true"
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"/>;
</AuthnRequest>;
上面的內容用最直白的方式解釋出來就是：這個來自Google的請求，請驗證當前用戶的身份，并將結果返回。
當IDP收到消息并確認要接受認證請求之后，就會要求Alice輸入用戶名和口令來驗證其身份(如果Alice已經登錄過了，就會跳過該步驟)；當驗證通過之后，Alice的瀏覽器將會跳轉回Google的特定頁面（AssertionConsumerService，簡稱ACS，step6）。同樣，SAML身份認證響應的內容也是在壓縮并編碼后以參數的形式傳輸。在壓縮和編碼之前，其結構類如下：
<Response Version="2.0"
IssueInstant="2013-02-05T08:29:00Z"
Destination="https://www.google.com/a/my.uni.nl/acs" InResponseTo="kfcn...lfki">
<Issuer>https://idp.uni.nl/</Issuer>
<Status>
<StatusCode
Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</Status>
<Assertion Version="2.0"
IssueInstant="2013-02-05T08:29:00Z">
<Issuer>https://idp.uni.nl/</Issuer>
<Subject>
<NameID>alice</NameID>
<SubjectConfirmation ...>
<SubjectConfirmationData
NotOnOrAfter="2013-02-05T08:34:00Z"
Recipient="https://www.google.com/a/my.uni.nl/acs" InResponseTo="kfcn...lfki"/>
</SubjectConfirmation>
</Subject>
<Conditions NotBefore="2013-02-05T08:28:30Z" NotOnOrAfter="2013-02-05T08:34:00Z">
</Conditions>
<AuthnStatement
AuthnInstant="2013-02-05T08:29:00Z"
SessionNotOnOrAfter="2013-02-05T16:29:00Z>
</AuthnStatement>
</Assertion>
</Response>
雖然內容很多，但是其主要表達的是：該消息來自idp.uni.nl，名為Alice用戶的身份已經被我驗證，該消息的有效期為2分鐘。此外，重定向的URL中還要有該消息的簽名以保證其不備篡改，驗證簽名的公鑰和算法，都是IDP和SP提前協商好的。
當Google接受到SAML認證響應之后，會首先驗證消息的簽名是否正確（step7）以及是否因超時而失效。然后再從認證消息中提取出Google能識別用戶身份（NameID，即Alice），如果以上的步驟都是順利的，用戶將會成功登陸Google（Step8）。
為了便于解釋，以上例子中的信息都保持了可讀性，如果想要去看看真實的SAML信息，建議推薦使用火狐瀏覽器的插件工具 SAML tracer。該插件將會在瀏覽器中添加一個窗口來顯示SAML消息，以下是截圖：
希望以上的內容能幫助你理解SAML協議。SAML協議的內容十分復雜，但是涉及到單點登錄的內容都是以上述內容為基礎的。
更多關于SAML協議的是實現的內容，請參見本人編寫的一系列教程文章來介紹如何使用OpenSAML，歡迎閱讀指正：
