2009-10-20 172 views
1

我們公司A可能很快將與B公司通過某種許可協議進行合作。如果通過,公司B的Web服務用戶有必要訪問公司A的Web服務。換句話說,任何擁有公司B服務帳戶的用戶都應該自動擁有公司A的帳戶,但無需創建新帳戶......他們應該是共享帳戶。Web服務的共享身份驗證

我不是這方面的專家(顯然),但我認爲這個方案需要沿着OpenID的方向發展,但只是在我們兩個網站之間。我們如何去分享身份驗證是這樣呢?我不太瞭解這個主題的問題,這使得谷歌難以獲得指導。這是否是單一標誌?

謝謝。

+0

說明: 1.如果/當他們想使用A的功能時,必須爲B的每個用戶創建一個帳戶。2. B使用電子郵件/密碼來驗證其用戶。 3. A或B當前都不使用OpenID或任何其他共享身份驗證方案。 4.情況與Emil描述的StackOverflow的工作原理幾乎完全相同,除了公司A只會在公司B(而不是任何OpenID提供商)確定用戶在創建本地帳戶之前是誰。 – mateolargo 2009-10-20 18:20:52

回答

0

你真的描述聯合會在這裏,它的OpenID是一個例子(儘管是一個不適合在這種情況下)。憑藉聯合身份,公司A允許公司B對其用戶進行身份驗證。該認證過程導致來自公司B的令牌包含關於發送給公司A並用於授權的用戶的信息(權利要求)。

聯合不是單點登錄,它傾向於描述公司A運行大量服務和身份驗證服務的情況 - 並且登錄到身份驗證服務允許用戶訪問所有資源,而無需重新認證。

不知道所涉及的體系結構是什麼,很難推薦一種方法。運輸索賠的標準方式是使用SAML令牌。在Microsoft環境中,您可以使用Windows Identity Framework來編寫理解SAML的Web服務,以及ADFS「Geneva」從Active Directory發出SAML令牌。其他身份商店也有類似的解決方案,例如IBM的Higgins。

0

我不認爲OpenID真的是一個答案。 B的Web服務用戶目前對這些Web服務進行身份驗證非常重要。我假設他們使用用戶名/密碼對,並假設你希望他們繼續這樣做,即使對於A的Web服務。

如果是這樣,下一個問題是密碼如何傳輸和驗證。我假設B當前使用「基本認證」(您需要用B進行確認)。如果是這樣,認證原則上是直截了當的:在A web服務中,也使用基本身份驗證,它使用戶將他們的密碼發送到A,IN PLAIN TEXT。使用https加密電線上的密碼。

然後,有密碼的副本,用B驗證它們,例如,通過讓A的服務向B發送一些專門服務的請求,這只是確認密碼是正確的。

此設置的缺點是用戶必須向A顯示其密碼;通過許可協議,您需要確信A不會濫用這些密碼(即不會濫用這些密碼(即,他們不會存儲它們,也不會使用它們在商定的過程之外對其進行體現)。

0

我覺得你有兩個問題。

  1. 允許公司A向機器B公司用戶進行身份驗證(反之亦然?)
  2. 上A公司機器公司B的用戶提供資源。

單點登錄或任何認證解決方案(如OpenID)解決了第一部分(對於靜態內容可能足夠了);您仍然需要爲這些現在通過身份驗證的用戶實際創建帳戶或以其他方式爲公司A計算機分配資源。

例如,StackOverflow使用OpenID對用戶進行身份驗證。這意味着StackOverflow可以讓你知道你是誰的其他服務,例如Google或Facebook等。但是,StackOverflow仍然需要爲你創建一個本地帳戶,跟蹤你的聲譽,向你發送更新到你的問題,和其他東西。

對於剛剛在認證部分,這裏有幾個選項:

  • 如果A公司已經支持OpenID,然後B公司可能僅僅是一個OpenID提供商。您仍然需要向公司A的網站添加一些代碼,以確保使用OpenID登錄的用戶是授權的,即來自B公司。
  • 如果公司A和B都使用LDAP(例如,Microsoft Active Directory)來處理內部身份驗證,那麼您可以添加一個轉發器讓公司A查詢公司B的LDAP服務器來驗證用戶身份(受適當的防火牆隧道處理)。
  • 或者,您可以通過讓公司B提供用戶列表以及讓公司A提前爲所有這些用戶預先創建帳戶來更靜態地執行此操作。這是最簡單的,但不能有效地處理來自B公司的人員變更,除非您設置了額外的同步過程。在這裏,您可能會爲每個帳戶生成密碼(例如姓氏+職員ID或隨機字符串),並讓公司B將其分發給其用戶。