c# 軟件開發人員沒有將授權外化嗎?



java .net (8)

在許多網站現在接受OpenID,CardSpace或聯合身份的情況下,外部化身份的價值主張開始增加。 但是,許多開發人員還沒有採取下一步的措施來將授權和使用基於XACML的方法進行外部化。

原因是缺乏意識還是別的什麼? 您如何期望了解基於XACML的軟件開發方法?

請注意,我正在詢問授權,而不是身份驗證。


Answer #1

我們繼續推出自己的主要原因是,像openid等人的選擇似乎只有技術網站的支持。 我們是一個較小的玩家,所以我們不會開始使用外部提供商,直到有更多的用戶接受為止。

我們不希望用戶必須在我們的網站上做的第一件事涉及到另一個網站。


Answer #2

對我個人而言,這是我聽說過的關於外部授權的第一件事情。所以可能只是缺乏意識。

現在使用Google搜索


Answer #3

一個問題就是“不在這裡發明”和對外化當局對(甚至是自治)身份的不信任的結合。 這裡有一個很好的寫法:

另外,我認為這可能是慣性。 沒有一個殺手級的應用程序,人們移動速度很慢。 鑑於我最近看到的Facebook整合數量的增加,我認為我們正處在一個陡峭的斜坡的頂端,即將進入這個世界。


Answer #4

我所做的大多數項目都是在大公司中使用的專有應用程序,在這種情況下,外部驗證服務幾乎不是一種選擇,但驗證是由一些內部服務(如Active Directory)來處理的。

如果我碰巧成為一個項目的一部分,將建立一個公共的網站,我肯定會嘗試使用像OpenID的東西,而不是託管我自己的身份驗證。


Answer #5

幾個原因:

  1. 正如一些評論所表明的那樣,人們普遍認為“授權是本地的”,這意味著重用訪問決策所需要的昂貴維護的高質量“主體屬性”幾乎沒有潛力。 (我相信由於一些法律/法規是廣泛適用的,因此有很高的再利用潛力,但是對於這種格式的充分討論太長了。)
  2. 缺乏數據基礎設施:在組織之間應用基於策略的訪問控制(我使用/信任一些其他組織的授權(“AuthZ”)數據來解鎖對我的數據的訪問)至少要求我理解屬性的語義(什麼是“執法人員”?什麼是“美國公民”)。然後,很容易理解屬性質量標準和第三方認證。 (有些人可能會注意到,這些要求與PKI互操作性的要求是類似的:這是怎麼回事?這只是一個數據,還有支持的東西。
  3. 對角色/職責的影響:將授權外化,無論是“角色”還是“屬性”,還是“數字策略屬性”,都意味著本地“數據擁有者”失去了對資源的控制權。 他還卸下了維護用戶列表的大量工作和責任。 這種變化將外部AuthZ從技術問題的實施提升到具有政治性的組織問題。
  4. 大多數組織不知道,也沒有寫下他們的政策。 訪問可以是“誰問”或“誰問我喜歡誰”或“誰能給我一些東西,比如訪問他們的數據”。 當用政策語言表達這些規則時,實際應用的規則可能會非常難看。 而將書面政策轉化為數字政策的技能也不會在樹上增長。 事實上,這個技能組合是業務分析師或律師,而不是IT人員,這些人的工具很少存在。
  5. 當你有一個堅實的政策規則,你可能會發現,處理它所需的屬性不存在 - 他們通常不是你在AD發現的東西。 電話號碼作為一個AuthZ屬性是沒有用的,甚至“組織”可能不適合大多數法律或法規,你可以實際記錄。 這甚至沒有提到你必須實施(並得到批准)的解決方法和近似,以表達像“可能的原因”這樣的政策要求。
  6. 比較容易理解,但仍然真實的是,許多非常普遍的COTS應用程序不支持外部授權,許多應用程序開發人員不習慣做外部化,所以將(a)試圖說服你擺脫它; 或者(二)在你的硬幣上學習,並做得不好。

聽起來很不好,對吧? 所以,讓我最後說,儘管如此,我認為這場比賽是值得的。 潛在好處的列表是在另一個時間另一個職位。

祝你好運!


Answer #6

我似乎陷入了其他人的誤解 - 問題是關於外部授權。 就個人而言,我只信任本地網絡上的分佈式授權,在這個網絡上我可以控制認證和授權服務器。 我絕不會在網站上使用外部授權。

以下是我對OpenID作為認證服務的評論。

1)正如所指出的,授權!=認證。 OpenID處理身份驗證,但是Web應用程序所有者仍然完全控制分配給該登錄名的權限。 這是積極的,但對此的混淆是消極的。

2)我找不到鏈接,但是OpenID向社交工程/主要中/釣魚攻擊開放。 提供商試圖防止這種情況(身份證件圖像,瀏覽器證書,回撥驗證等),但當黑帽子網站彈出一個對話框/頁面,說“輸入您的OpenID用戶名和密碼”和天才用戶遵守。

3)聯邦ID的每個提供者都有能力(並且有些人會說責任)來跟踪他們用戶的所有活動,而不管他們使用該ID的站點。 這就是谷歌和雅虎為什麼要提供聯合身份證的原因,但並不那麼興奮。

4)與上面的評論相反,使用OpenID通常會降低註冊的障礙,尤其是當有用戶界面指出新用戶可能已經擁有OpenID的時候。 當您使用諸如RPX的組合OpenID / OAuth解決方案時,情況更是如此。

所以,從我的角度來看,使用OpenID的風險是在用戶上,而不是在網站上。 我無法阻止用戶使他們嘗試記住另一個用戶ID和密碼。 此外,黑帽並不需要做任何更為惡意的事情,比用純文本存儲用戶的密碼來訪問用戶的其他賬戶。 有多少人使用不同的密碼登錄每個網站?


Answer #7

我認為外部授權的前景比外部認證(OpenID,CardSpace等)要困難得多。 這主要是由於授權更具體的應用程序。 什麼人A有權在我的申請中做他可能無法完成的申請,甚至假設我的申請和你的申請之間有一些共同的平行點,這很可能是不存在的。

我不想說外在化授權永遠不會完成,但是我真的很難想出真正想要這樣做的理由。 也許對於一組並行的應用程序來說,但是再一次,這很可能在內部得到支持,而不是在外部得到支持。


Answer #8

我認為這取決於你的工作類型。 如果客戶想要存儲授權,則無法使用OpenID ...我使用谷歌應用程序引擎開發一個小項目,因此我使用谷歌來進行授權。 所以它強烈依賴於項目的類型。





jaas