Browser / POST和Browser / Artifact SAML配置文件的便捷應用程序

[英]Convenient applications for Browser/POST and Browser/Artifact SAML profiles


I'm proposing the use of SAML 1.1 as technology to prove Web SSO in a customer environment, and they asked me something interesting:

我建議使用SAML 1.1作為在客戶環境中證明Web SSO的技術,他們問我一些有趣的事情:

Which scenario Browser/POST profile is appropriate, and which scenarios Browser/Artifact profile of SAML is appropriate?

哪種情況下瀏覽器/ POST配置文件是合適的,哪些方案SAML的瀏覽器/工件配置文件是合適的?

In fact, SAML 1.1 Specifications don´t talk about the best neither most appropriate scenario for both Browser profiles.

事實上,SAML 1.1規范並未談及兩種瀏覽器配置文件的最佳選擇。

Maybe security threats of each one can be used to pick up the best. In my vision, both can be applyed equally in any scenario so far.

也許每個人的安全威脅都可以用來獲得最好的威脅。在我看來,到目前為止,兩者都可以平等地應用於任何場景。

*Note: The solution uses Weblogic Server 10.0 and its support to SAML 1.1.

*注意:該解決方案使用Weblogic Server 10.0及其對SAML 1.1的支持。

2 个解决方案

#1


It seemed to me that both profiles offer similar levels of security. With the POST profile, the user has to explicitly initiate the POST. This might help to thwart something along the lines of a CSRF attack, but I don't know of any actual exploits. The Artifact profile, with its use of the GET method, can provide a more seamless experience for the user.

在我看來,兩個配置文件都提供類似的安全級別。使用POST配置文件,用戶必須顯式啟動POST。這可能有助於阻止CSRF攻擊的某些方面,但我不知道任何實際的漏洞。通過使用GET方法,Artifact配置文件可以為用戶提供更加無縫的體驗。

For me, the drawback to the Artifact profile is the complexity in opening the back channel. My application server dedicates a thread to handling the user request, and if that thread is blocked (waiting for the back-channel IO to complete) for very long, the app server begins to perform very poorly. So, the back-channel communication has to be performed very carefully to ensure that it times out after a defined period of time.

對我來說,Artifact配置文件的缺點是打開后通道的復雜性。我的應用程序服務器專門用一個線程來處理用戶請求,如果該線程被阻塞(等待反向通道IO完成)很長時間,應用服務器開始執行得非常糟糕。因此,必須非常小心地執行反向信道通信,以確保它在規定的時間段后超時。

Even then, if the IdP is down having trouble, it's not as obvious to my users that the fault is at the IdP. With a POST profile, if the IdP is misbehaving, users are less likely to blame me.

即使這樣,如果IdP出現故障,我的用戶也不會明白故障是在IdP。使用POST配置文件,如果IdP行為不端,用戶不太可能責怪我。

#2


In terms of security, the main difference is that, with POST profile, the SAML response (containing the assertion) travels via the end-user's browser, so it MUST be at least signed, and possibly encrypted, if there's anything you wouldn't want the end-user to be able to see.

在安全性方面,主要區別在於,對於POST配置文件,SAML響應(包含斷言)通過最終用戶的瀏覽器傳播,因此必須至少簽名,並且可能加密,如果有什么你不會希望最終用戶能夠看到。

With the artifact profile, you can use SSL to secure the back-channel and send an unsigned, unencrypted assertion, since it is passed directly from the IdP to the SP. You may still want to sign the assertion for non-repudiation, though.

使用工件配置文件,您可以使用SSL來保護反向通道並發送無符號的未加密斷言,因為它直接從IdP傳遞到SP。不過,您可能仍希望簽署不可否認的斷言。

As Erickson mentions, though, setting up the outbound 'back-channel' connection from the SP to the IdP comes with its own challenges. Most SAML deployments I've seen use POST for this reason.

正如埃里克森所提到的那樣,建立從SP到IdP的出站“反向通道”連接也有其自身的挑戰。出於這個原因,我見過的大多數SAML部署使用POST。

BTW - any reason you're using SAML 1.1 rather than 2.0?

BTW - 您使用SAML 1.1而不是2.0的任何原因?


注意!

本站翻译的文章,版权归属于本站,未经许可禁止转摘,转摘请注明本文地址:https://www.itdaan.com/blog/2009/05/13/72f48113fb47eb66c2b3893496680f39.html



 
粤ICP备14056181号  © 2014-2021 ITdaan.com