使用/uaa/
來轉發(fā)基于uaa的認證請求至auth組件
來轉發(fā)請求至account組件，并標記serviceId為account-service，與圖一中的withClient對應。
圖一為瀏覽器打開應用入口后，輸入用戶名和密碼后，發(fā)出的認證請求：
認證url為/uaa/oauth/token，這是uaa模式下標準的請求獲取token的url
表單中包含了字段scope(認證范圍)和字段password(認證類型)
圖二為圖一發(fā)出認證請求的返回結果：
Access_token為有效認證token，將來被其他請求使用
圖三為發(fā)出獲取當前用戶的信息的請求：
在請求里的Authorization的值為圖二中獲得的access_token
圖一為Account組件在Config組件(配置中心)定義的OAuth2協(xié)議下獲取token的方式，這里定義了：
clientID和clientSecret
accessTokenUrl，這里指定了auth組件的uaa獲取token的url
grant-type，即認證類型，這里指定為client_credentials
scope，這里指定了server，說明是這個認證請求只適用在各微服務之間的訪問。
圖二為Accout組件業(yè)務代碼中定義了需要使用Auth組件進行事先鑒權的方法：
[email protected]
annotation中可以指定認證范圍的具體條件，這里是限定了server或者是demo賬戶，才有權限發(fā)起認證。
最后小結下Spring Cloud Security的特點：
基于UAA，使用OAuth2協(xié)議。不會暴露用戶的敏感信息
基于認證類型和認證范圍，實現(xiàn)細粒度的鑒權機制
非瀏覽器客戶端下良好的操作性
Q&A
問題：Basic Auth + Central Auth DB這種方式中，每個服務有自己的鑒權DB，這塊只是一個緩沖嗎?如果中途通過別的方式修改了中心DB的數(shù)據(jù)，而緩沖又沒過期，這個時候有什么解決方案嗎?
答：不是緩沖，這里的Central Auth DB是指各個微服務共用一個數(shù)據(jù)庫。
問題：微服務架構需要服務路由和服務注冊么?跟esb的區(qū)別在哪里?
答：服務路由組件和服務注冊組件和是相對必要的，他們保證了用戶請求能發(fā)到正確的微服務中去。ESB企業(yè)服務總線是相對比較重的組件，而不是像微服務組件一樣只負責單個業(yè)務。
問題:在微服務中，對于數(shù)據(jù)權限的粒度，是可以集中在在gateway中進行還是由每個微服務自己獨立配置?
答：推薦由那個專門負載權限的微服務組件來配置。
問題：您好，辛苦了，請問現(xiàn)在有類似SAML協(xié)議，但是不基于XML，而是基于JSON或者其他簡化格式的協(xié)議嗎?
答：目前據(jù)我所知沒有基于JSON的SAML協(xié)議。有個叫JWT(JSON web token)的協(xié)議，它是完全基于JSON的，Spring Cloud架構中也使用了JWT。
問題：對于這個架構，服務劃分的粒度有沒有什么好的建議?另外登錄憑證保存在客戶端如何解決報文被攔截的安全漏洞?
答：服務劃分需要按具體業(yè)務來說，一般來說，一個業(yè)務實體作為一個微服務。使用https可以一定程度上提高安全性。
問題:spring cloud security可以解決token重放攻擊么?
答：token重放攻擊不是特別了解，可能是數(shù)據(jù)弱一致性導致的，建議設計盡可能短的過期時間。
問題：我們公司現(xiàn)在在設計DMP，從行業(yè)的狀況來看，采用了微服務，但是有一點，首先對于應用本身暴露出來的服務，是和應用一起部署的，也就是并非單獨的部署，那么業(yè)務組件接口暴露部署是否合理呢?
答：業(yè)務組件的接口一般可以通過統(tǒng)一網(wǎng)關來管理。也可以對業(yè)務接口像spring cloud中設置訪問scope限制。
問題：所有暴露的微服務是否需要一個統(tǒng)一的服務管控和治理平臺?
答：是的，一般有服務網(wǎng)關和服務發(fā)現(xiàn)組件來管理用戶請求。
問題：微服務的gateway需要實現(xiàn)底層多個細粒度的API組合的場景，我們現(xiàn)在一部分使用異步，但是遇到了沒辦法全面的解藕。我想問問，對于此，使用響應式?還是異步回調(diào)式?它們的區(qū)別點會有哪些呢?