我正在使用多個SP實施單點登錄。這是我的基本理解：重複使用SAML聲明
1）瀏覽器（用戶）向服務提供商（SP）請求資源。
2）SP重定向（使用SAML請求）身份提供商（IdP）。
3）由於是第一次登錄，所以用戶給予（IdP）他/她的有效憑證。
4）然後，IdP將瀏覽器（包含SAML令牌的SAML響應）重定向到SP頁面。
現在假設我有服務提供者A和服務提供者B.用戶已經完成了服務提供者A的步驟。從服務提供者A（在我的場景中的salesforce.com），我已經編寫了一個服務器端方法該實例標註來對服務提供商B.端點是否有可能在這種情況下，重新使用SAML斷言？即服務提供商B會相信後端方法嗎？
您必須自定義服務提供者B才能接受，理解和解釋由服務提供者A獲得的Assertion。它肯定無法即裝即用。
包括在SAML Response到服務提供商A包含數據段，它與原來的關聯並定義消息的接收者（例如，使用的元件和SubjectConfirmationDataAudience）的SAML Assertion。服務提供商B需要忽略這些字段中的值，因爲它實際上不是Assertion的縮進收件人。
如何在身份提供者聲明用戶身份的兩臺機器之間代理信任的問題可以通過多種標準方法解決。一種是使用Session Token Service（基於WS-Trust），它定義瞭如何請求和問題令牌第三方服務。另一種是使用OAuth 2.0。你當然也可以簡單服務提供者A使用自定義方案，使用密碼，HMAC，...
簡短的回答驗證到業務提供商B - 如果業務提供商B實現不作爲標準SAML 2.0 SP。
SAML 2.0聲明是「有針對性」和簽名的。他們有指定的受衆和收件人網址。你不能改變他們沒有破壞簽名。 SP A收到的斷言包含作爲受衆的SP A的名稱和作爲收件人URL的SP A的ACS終點。這樣的說法會不會被SP B.接受
什麼阻止你只是在一個標準的調用方式SP B，讓它開始了自己的SAML 2.0流？另一種選擇是爲SP B執行由IDP啓動的SSO流程。但並非所有的IDP實施都支持它。