最近燃料公司門戶做了一個待辦的彙總,從三個數據源拿數據彙總到首頁,這三個數據源分別是域認證的介面,域認證的webservices,證書加密的介面,下麵就這些介面,做一下簡單總結 1 pfx證書的探索過程 0.1 提供的代碼 1.1 pfx 百度百科對pfx的解釋是: 公鑰加密技術12號標準。 公鑰加 ...
最近燃料公司門戶做了一個待辦的彙總,從三個數據源拿數據彙總到首頁,這三個數據源分別是域認證的介面,域認證的webservices,證書加密的介面,下麵就這些介面,做一下簡單總結
1 pfx證書的探索過程
0.1 提供的代碼
private static string GetNewAccessToken()
{
var stsEndpoint = "https://sts.hpi.com.cn/adfs/services/trust/13/certificatemixed";
var relayPartyUri = "https://opendata.hpi.com.cn";
var pfxFilePath = ConfigurationManager.AppSettings["pfxFilePath"];
Uri u = new Uri(relayPartyUri);
var certPath = System.IO.Path.Combine(pfxFilePath, "DVT2.pfx");
var certFile = File.OpenRead(certPath);
var certficateBytes = new byte[certFile.Length];
certFile.Read(certficateBytes, 0, (int)certFile.Length);
var cert = new X509Certificate2(certficateBytes, "DVT**&&90", X509KeyStorageFlags.Exportable | X509KeyStorageFlags.MachineKeySet | X509KeyStorageFlags.PersistKeySet);
var factory = new System.ServiceModel.Security.WSTrustChannelFactory(
new CertificateWSTrustBinding(SecurityMode.TransportWithMessageCredential), stsEndpoint
)
{ TrustVersion = TrustVersion.WSTrust13 };
if (factory.Credentials != null)
{
factory.Credentials.ClientCertificate.Certificate = cert;
}
var rst = new System.IdentityModel.Protocols.WSTrust.RequestSecurityToken
{
RequestType = RequestTypes.Issue,
KeyType = KeyTypes.Bearer,
AppliesTo = new System.IdentityModel.Protocols.WSTrust.EndpointReference(relayPartyUri),
KeySizeInBits = 0,
TokenType = "urn:ietf:params:oauth:token-type:jwt"
};
var genericXMLSecurityToken = factory.CreateChannel().Issue(rst) as System.IdentityModel.Tokens.GenericXmlSecurityToken;
string accessToken = genericXMLSecurityToken != null ? Encoding.UTF8.GetString(Convert.FromBase64String(genericXMLSecurityToken.TokenXml.InnerXml)) : string.Empty;
return accessToken;
}
1.1 pfx
百度百科對pfx的解釋是:
公鑰加密技術12號標準。
公鑰加密技術12號標準(Public Key Cryptography Standards #12,PKCS#12)為存儲和傳輸用戶或伺服器私鑰、公鑰和證書指定了一個可移植的格式。它是一種二進位格式,這些文件也稱為PFX文件。開發人員通常需要將PFX文件轉換為某些不同的格式,如PEM或JKS,以便可以為使用SSL通信的獨立Java客戶端或WebLogic Server使用
是一種Microsoft協議,使用戶可以將機密信息從一個環境或平臺傳輸到另一個環境或平臺。使用該協議,用戶就可以安全地將個人信息從一個電腦系統導出到另一個系統中。
1.2 WSTrustChannelFactory
在微軟的代碼段中有一段看不明白:
var factory = new System.ServiceModel.Security.WSTrustChannelFactory( new CertificateWSTrustBinding(SecurityMode.TransportWithMessageCredential), stsEndpoint ) { TrustVersion = TrustVersion.WSTrust13 };
在瞭解了相關內容之後,我理解pfx只是一種加密的技術,加密出來的證書格式也不止這一種,但是瞭解到這裡並不能幫助我理解到底是如何通過證書去獲取信任包括代碼中的stsEndpoint到底是什麼意思,在檢索WSTrustChannelFactory的過程中,我發現這是和WCF密切相關的一個允許客戶端直接與 WS-Trust 頒發者進行通信的對象
WSTrustChannelFactory 和 WSTrustChannel
1.3 WS-Trust
百度百科的解釋:
WS-Trust是WS-*規範族中的一員,也是OASIS(Organization for the Advancement of Structured Information Standards)其中的一項標準。
它對WS-Security規範提供了一些擴展,專門處理有關安全tokens的發佈,整新和驗證,確保各方參與者的互操作處在一個可信任的安全數據交換環境中。
WS-Trust規範發起於一些有代表性的公司,最後於2007年3月被OASIS核准通過並作為一項標準發佈。
通過使用WS-Trust中定義的這些擴展規範,可以確保工作在Web服務框架中的Web應用之間的通信是安全的。
上面這篇文章是對WS-TRUST的全面解析,
消費者向STS請求token的請求結構
我覺得非常有用的是這兩段:
The AppliesTo field is optional and enables the requester to specify the endpoint to which the returned token will be sent. In some cases, the STS is configured to know what token type must be returned for a specific endpoint.
If the AppliesTo and TokenType fields are both present in the request, the precedence goes to the AppliesTo field; that is, if the STS knows that the endpoint uses a different token type than the one specified in the TokenType field, it ignores the TokenType field and returns the token that is used by the endpoint. This assumes that the STS is the only party knowing what token types are supported by the providers' endpoints. The advantage of this mechanism is that each consumer doesn't have to maintain the whole list of supported token types and endpoints.
所以我們知道endpint 這個終端在待辦開發裡面,就指的微軟的WCF服務,STS會判斷這個終端用的是哪種令牌然後返回這個令牌。
STS返回令牌的結構是:
正好也對應了這一段:
var genericXMLSecurityToken = factory.CreateChannel().Issue(rst) as System.IdentityModel.Tokens.GenericXmlSecurityToken;
string accessToken = genericXMLSecurityToken != null ? Encoding.UTF8.GetString(Convert.FromBase64String(genericXMLSecurityToken.TokenXml.InnerXml)) : string.Empty;
return accessToken;
即向STS建立channel,發送請求令牌的請求結構,然後在返回的xml中,提取需要的token,因為微軟的服務用的是WCF,SOAP所使用的都是xml。在檢索WS-TRUST時,最多匹配到的中文結果都是與WCF相關的,也側面推測出了微軟的服務就是用WCF做得。
1.4 小結
在這兩個小時的瞭解過程中,並沒有執著於對這段代碼的技術分析,而是主要瞭解背後的邏輯和協議,如果以後再遇到類似的情況,我覺得再做深入的探索也不遲,知道對目前的我來說,現在的瞭解已經滿足了我的求知欲。
2 windows域認證
在web頁面寫js 的時候,我同時遇到了windows的域和js的域問題。
同時我們都知道web裡面認證分為windows認證和form認證,在部署了AD的環境下,使用windows認證其實更方便,因為開發者不需要編寫登錄頁面和登錄邏輯,但是這部分我有一個疑惑,就是如果我想拿到域登錄用戶的個人憑證,拿著這個憑證去訪問其他的資源,比如請求某些數據源,這些操作是否只能在客戶端完成,因為在服務端是沒法完整拷貝整個用戶憑證的,目前我遇到的具體的問題就是不能在服務端拿到用戶的密碼。
2.1 windows域
域英文叫DOMAIN——域(Domain)是Windows網路中獨立運行的單位,域之間相互訪問則需要建立信任關係(即Trust Relation)。信任關係是連接在域與域之間的橋梁。當一個域與其他域建立了信任關係後,2個域之間不但可以按需要相互進行管理,還可以跨網分配文件和印表機等設備資源,使不同的域之間實現網路資源的共用與管理。
域既是 Windows 網路操作系統的邏輯組織單元,也是Internet的邏輯組織單元,在 Windows 網路操作系統中,域是安全邊界。域管理員只能管理域的內部,除非其他的域顯式地賦予他管理許可權,他才能夠訪問或者管理其他的域;每個域都有自己的安全策略,以及它與其他域的安全信任關係。
2.2 js域
javascript處於安全方面的考慮,不允許跨域調用其他頁面的對象,javascript的同源策略:a.com下的js無法操作b.com或者c.a.com下的對象
具體的是否跨域的判斷可以看下表:
具體跨域的解決方案可以在下麵的鏈接裡面瞭解
2.3 IE中跨域的處理
IE中有一個信任站點的概念,假如a.com 和b.com的網站屬於同一個windows域,那麼在IE上把他們都添加到信任站點可以實現免登陸,如果在IE信任站點的高級配置裡面,允許跨域瀏覽視窗和框架+允許跨域請求數據源,那麼就相當於放開了js 的同源策略,即在a.com的腳本可以操作b.com的對象和數據源。
詳細的圖文設置如下:
3.1 webservice介面
3.1 webservice允許get、post網路請求
在webconfig裡面添加
<system.web>
<webServices>
<protocols>
<add name="HttpPost"/>
<add name="HttpGet"/>
</protocols>
</webServices>
</system.web>
3.2 webservice 允許跨域訪問
把跨域文件放到web伺服器,跨域xml示例:
<?xml version="1.0" encoding="utf-8"?>
<access-policy>
<cross-domain-access>
<policy>
<allow-from>
<domain uri="*"/>
</allow-from>
<grant-to>
<resource path="/" include-subpaths="true"/>
</grant-to>
</policy>
</cross-domain-access>
</access-policy>
4 總結
雖然寫到了總結,但是還有有一個遺留問題,就是保存域用戶的身份憑證,在瀏覽器里我看到一些cookie應該是用做認證用的,但是還沒詳細的去研究,下午搞這個。