安全斷言標記語言

安全主張標記語言是一個基於XML的開源標準資料格式，它在當事方之間交換身份驗證和授權資料，尤其是在和服務提供者之間交換。SAML是OASIS安全服務技術委員會的一個產品，始於2001年。其最近的主要更新發佈於2005年，但協議的增強仍在透過附加的可選標準穩步增加。SAML解決的最重要的需求是網頁瀏覽器單一登入原則.SAML規範定義了三個角色：委託人。在用SAML解決的使用案例中，委託人從服務提供者那裡請求一項服務。服務提供者請求身份提供者並從那裡並獲得一個身份主張。服務提供者可以基於這一主張進行存取控制的判斷——即決定委託人是否有權執行某些服務。在將身份主張傳送給服務提供者之前，身份提供者也可能向委託人要求一些資訊——例如使用者名稱和密碼，以驗證委託人的身份。SAML規範了三方之間的主張，尤其是主張身份訊息是由身份提供者傳遞給服務提供者。在SAML中，一個身份提供者可能提供SAML主張給許多服務提供者。同樣的，一個服務提供者可以依賴並信任許多獨立的身份提供者的主張。SAML沒有規定身份提供者的身份驗證方法；他們大多使用使用者名稱和密碼，但也有其他驗證方式，包括採用多重要素驗證。諸如輕型目錄訪問協議、RADIUS和Active Directory等目錄服務允許使用者使用一組使用者名稱和密碼登入，這是身份提供者使用身份驗證令牌的一個典型許多流行的網際網路社交網路服務也提供身份驗證服務，理論上他們也可以支援SAML交換。歷史.OASIS安全服務技術委員會於2001年1月首次舉行會議，提出“定義一個用於交換身份驗證和授權的XML框架。”為完成此目標，下列智慧財產權在該年的頭兩個月內向SSTC進行了捐獻：在這項工作的基礎上，OASIS於2002年11月宣佈“安全主張標記語言”V1.0規範成為一個OASIS標準。與此同時，大型企業、非營利及政府組織的聯盟提出了一個擴充套件SAML標準的“自由聯盟統一聯合框架”，其中每個參與域被信任將準確記錄識別使用者的過程、所使用的身份驗證型別，以及任何與生成身份驗證憑據相關的策略。信任圈中的其他成員可以查驗這些策略，以決定是否信任此類資訊。雖然ID-FF開發了Liberty，SSTC已開始小規模升級到SAML規範。這使得SSTC在2003年9月批准了SAML V1.1規範。在同月，Liberty將ID-FF貢獻至OASIS，從而為SAML下一版本奠基。2005年3月，SAML V2.0被宣佈成為一項OASIS標準。SAML V2.0意味著Liberty ID-FF及其他專有擴充套件的收斂，以及包括SAML本身的早期版本。大多數SAML實現支援V2.0，並也大多支援V1.1以實現向後相容。截至2008年1月，SAML V2.0的開發已在政府、高等教育和全球商業企業中普遍存在。版本.SAML自V1.0以來已進行一次重大及一次次要修訂。Liberty Alliance在2003年9月將其自由聯盟統一聯合框架貢獻至OASIS SSTC：SAML的1.0和1.1版本很類似，僅存在微小差異。SAML 2.0與SAML 1.1 則有著實質性的差異。雖然兩者都是解決相同的使用案例，但SAML 2.0與1.1並不相容。儘管ID-FF 1.2已作為SAML 2.0的基礎貢獻至OASIS，但在SAML 2.0與ID-FF 1.2之間 有著一些重要的差異。尤其是儘管這兩個規範同根同源，但兩者並不相容。設計.SAML 建立在一些現有標準之上：SAML很大程度上依賴超文字傳輸協議作為其通訊協議。SAML定義了基於XML的主張、協議、繫結和配置。術語SAML核心。因此SAML核心只定義了“純粹的”SAML主張，以及SAML的請求和響應元素。SAML繫結決定SAML請求和響應如何對映到標準的訊息或通訊協議。一個重要的、同步的繫結是SAML SOAP繫結。SAML配置是使用特定主張、協議和繫結組成的適用於所定義使用情況的一個具體表現形式。主張.一個SAML主張包含一個安全資訊包：簡而言之，依賴方按下述方式解釋一個主張：主張"A"是在條件"C" 有效的前提下由釋出者"R" 關於主題"S"在時間"t釋出的 。"SAML主張通常從IdP傳送到SP。主張包括一些SP用來做許可權控制的"宣告"。SAML提供如下三種語句："身份驗證宣告"會向SP主張，該委託人確實被IdP在一個特定的時間透過一個特定的認證方式成功認證。關於該被認證的委託人的其他資訊也可能會包含在一條身份驗證宣告中。"屬性聲"明會主張，一個主題和一些屬性關聯。一個屬性是一個簡單的鍵值對。依賴方使用屬性來實現訪問控制。授權決策宣告會主張，在證據"E"下一個主題是否被允許在資源"R"上執行動作"A"。SAML中的授權決策宣告的功能被有意的限制了，因為在更高階的使用場景中更推薦使用XACML。協議.A SAML "protocol" describes how certain SAML elements (including assertions) are packaged within SAML request and response elements, and gives the processing rules that SAML entities must follow when producing or consuming these elements. For the most part, a SAML protocol is a simple request-response protocol.The most important type of SAML protocol request is called a "query". A service provider makes a query directly to an identity provider over a secure back channel. Thus query messages are typically bound to SOAP.Corresponding to the three types of statements, there are three types of SAML queries:Of these, the "attribute query" is perhaps most important (and still the object of much research). The result of an attribute query is a SAML response containing an assertion, which itself contains an attribute statement. See the SAML 2.0 topic for .Beyond queries, SAML 1.1 specifies no other protocols.SAML 2.0 expands the notion of "protocol" considerably. The following protocols are described in detail in SAML 2.0 Core:Most of these protocols are completely new in SAML 2.0.繫結.A SAML "binding" is a mapping of a SAML protocol message onto standard messaging formats and/or communications protocols. For example, the SAML SOAP binding specifies how a SAML message is encapsulated in a SOAP envelope, which itself is bound to an HTTP message.SAML 1.1 specifies just one binding, the SAML SOAP Binding. In addition to SOAP, implicit in SAML 1.1 Web Browser SSO are the precursors of the HTTP POST Binding, the HTTP Redirect Binding, and the HTTP Artifact Binding. These are not defined explicitly, however, and are only used in conjunction with SAML 1.1 Web Browser SSO. The notion of binding is not fully developed until SAML 2.0.SAML 2.0 completely separates the binding concept from the underlying profile. In fact, there is a brand that defines the following standalone bindings:This reorganization provides tremendous flexibility: taking just Web Browser SSO alone as an example, a service provider can choose from four bindings (HTTP Redirect, HTTP POST and two flavors of HTTP Artifact), while the identity provider has three binding options (HTTP POST plus two forms of HTTP Artifact), for a total of twelve (12) possible deployments of the SAML 2.0 Web Browser SSO Profile.配置.A SAML "profile" describes in detail how SAML assertions, protocols, and bindings combine to support a defined use case. The most important SAML profile is the Web Browser SSO Profile.SAML 1.1 specifies two forms of Web Browser SSO, the Browser/Artifact Profile and the Browser/POST Profile. The latter passes assertions "by value" whereas Browser/Artifact passes assertions "by reference". As a consequence, Browser/Artifact requires a back-channel SAML exchange over SOAP. In SAML 1.1, all flows begin with a request at the identity provider for simplicity. Proprietary extensions to the basic IdP-initiated flow have been proposed (by , for example).The Web Browser SSO Profile was completely refactored for SAML 2.0. Conceptually, SAML 1.1 Browser/Artifact and Browser/POST are special cases of SAML 2.0 Web Browser SSO. The latter is considerably more flexible than its SAML 1.1 counterpart due to the new "plug-and-play" binding design of SAML 2.0. Unlike previous versions, SAML 2.0 browser flows begin with a request at the service provider. This provides greater flexibility, but SP-initiated flows naturally give rise to the so-called "Identity Provider Discovery" problem, the focus of much research today. In addition to Web Browser SSO, SAML 2.0 introduces numerous new profiles:Aside from the SAML Web Browser SSO Profile, some important third-party profiles of SAML include:安全.SAML規範推薦、並在某些情況下要求各種安全機制：Requirements are often phrased in terms of (mutual) authentication, integrity, and confidentiality, leaving the choice of security mechanism to implementers and deployers.使用.SAML的主要用途是“網頁瀏覽器單點登入。A user wielding a "user agent" (usually a web browser) requests a web resource protected by a SAML "service provider". The service provider, wishing to know the identity of the requesting user, issues an authentication request to a SAML "identity provider" through the user agent. The resulting protocol flow is depicted in the following diagram.The value of the codice_5 parameter is the base64 encoding of a codice_6 element.In SAML 1.1, the flow begins with a request to the identity provider's inter-site transfer service at step 3.In the example flow above, all depicted exchanges are "front-channel exchanges", that is, an HTTP user agent (browser) communicates with a SAML entity at each step. In particular, there are no "back-channel exchanges" or direct communications between the service provider and the identity provider. Front-channel exchanges lead to simple protocol flows where all messages are passed "by value" using a simple HTTP binding (GET or POST). Indeed, the flow outlined in the previous section is sometimes called the "Lightweight Web Browser SSO Profile".Alternatively, for increased security or privacy, messages may be passed "by reference". For example, an identity provider may supply a reference to a SAML assertion (called an "artifact") instead of transmitting the assertion directly through the user agent. Subsequently, the service provider requests the actual assertion via a back channel. Such a back-channel exchange is specified as a SOAP message exchange (SAML over SOAP over HTTP). In general, any SAML exchange over a secure back channel is conducted as a SOAP message exchange.On the back channel, SAML specifies the use of SOAP 1.1. The use of SOAP as a binding mechanism is optional, however. Any given SAML deployment will choose whatever bindings are appropriate.