單點登錄加密
❶ 單點登錄SSO和密碼代填有什麼區別
首先需要明確的是：密碼代填不是單點登錄。
例如 公司A 目前想實現單點登錄，但是應用沒有標准介面，也沒有相應的開發人員，只能通過密碼代填的方式來實現。需要注意的是，密碼代填可能需要知道用戶的賬戶密碼進行傳輸。所以還是建議公司里應該試用基於協議的單點登錄。
目前市面上玉符科技專注於做單點登錄，對於有些公司不得不通過密碼代填的形式來實現單點登錄的話，玉符可以確定的是他們所有傳輸都是通過https發生的，並且專門開發了非常安全的密鑰管理機制KMS，經過多層加密，確保密碼不會被竊取。
以上。希望採納
❷ qq 單點登錄是怎麼實現的會不會造成密碼泄露
年初的時候領導讓研究過sso單點登錄...
記得當時是主要通過cookie來實現的,訪問頁面時先檢查cookie是否有登錄信息(登錄是否成功,用戶標識),如果登錄成功就直接跳轉到模塊對應的主頁,如果cookie里沒有登錄信息或登錄失敗就讓用戶重新登錄.
整個過程中密碼只在第一次訪問站點時用了一次(檢查是用戶名密碼是否匹配)..後續訪問其他模塊時只需要檢查cookie的登錄是否成功即可, 所以不會造成密碼泄露....
騰訊好像也是這么做的, 記得登錄他旗下某個站點後就有更新cookie, 好象是存了一個md5值
❸ CAS單點登錄用MD5加密就登錄不了了
參考答案: 做人要謙卑，因為謙卑不醉。
❹ 問下單點登錄如何實現加密
如果單點是指統一一個後台管理還是可以實現的，這樣操作無論安裝多少終端都可以在後台管理加密文件，了解文件的狀態許可權的設置等等管理。
❺ 單點登錄是採用了什麼安全保障機制
根據實現方式的不同，單點登錄採用的安全機制也不相同，但主要是對系統間傳輸的數據信息進行加密，該機制依賴於所採用加密演算法的安全性。頁面重定向方式採用的token驗證的機制一定程度上克服了這一問題，但犧牲了一定的便捷性。
❻ 到底這個單點登錄系統能有什麼好處呢，為什麼一點要實現單點登錄
單點登錄SSO（Single Sign On）說得簡單點就是在一個多系統共存的環境下，用戶在一處登錄後，就不用在其他系統中登錄，也就是用戶的一次登錄能得到其他所有系統的信任。
1）提高用戶的效率。
用戶不再被多次登錄困擾，也不需要記住多個 ID 和密碼。另外，用戶忘記密碼並求助於支持人員的情況也會減少。
2）提高開發人員的效率。
SSO 為開發人員提供了一個通用的身份驗證框架。實際上，如果 SSO 機制是獨立的，那麼開發人員就完全不需要為身份驗證操心。他們可以假設，只要對應用程序的請求附帶一個用戶名，身份驗證就已經完成了。
3）簡化管理。
如果應用程序加入了單點登錄協議，管理用戶帳號的負擔就會減輕。簡化的程度取決於應用程序，因為 SSO 只處理身份驗證。所以，應用程序可能仍然需要設置用戶的屬性（比如訪問特權）。
實現方式我了解到的大概分三種：
以Cookie作為憑證媒介
最簡單的單點登錄實現方式，是使用cookie作為媒介，存放用戶憑證。
用戶登錄父應用之後，應用返回一個加密的cookie，當用戶訪問子應用的時候，攜帶上這個cookie，授權應用解密cookie並進行校驗，校驗通過則登錄當前用戶。通過JSONP實現
對於跨域問題，可以使用JSONP實現。
用戶在父應用中登錄後，跟Session匹配的Cookie會存到客戶端中，當用戶需要登錄子應用的時候，授權應用訪問父應用提供的JSONP介面，並在請求中帶上父應用域名下的Cookie，父應用接收到請求，驗證用戶的登錄狀態，返回加密的信息，子應用通過解析返回來的加密信息來驗證用戶，如果通過驗證則登錄用戶。通過頁面重定向的方式
最後一種介紹的方式，是通過父應用和子應用來回重定向中進行通信，實現信息的安全傳遞。
父應用提供一個GET方式的登錄介面，用戶通過子應用重定向連接的方式訪問這個介面，如果用戶還沒有登錄，則返回一個的登錄頁面，用戶輸入賬號密碼進行登錄。如果用戶已經登錄了，則生成加密的Token，並且重定向到子應用提供的驗證Token的介面，通過解密和校驗之後，子應用登錄當前用戶。
❼ 門戶中如何實現單點登錄和統一身份認證
本案涉及三個概念及功能模塊，即門戶、單點登錄和統一身份認證。
單點登錄(Single Sign-On，縮寫為SSO)，它是目前業務整合時使用較多的一種解決方案，通過SSO，用戶只需要在某個應用系統入口登錄一次，就可以訪問所有與該應用系統相互信任的其它應用系統。
目前成熟的SSO實現框架有很多，開源的有JOSSO、CAS等很多，你可以選擇其中之一與門戶集成即可，集成方法的問題可在選型後在網路中查找，可選方案請參考《Liferay 集成 CAS 實現單點登錄與應用系統集成》 http://www.ibm.com/developerworks/cn/opensource/os-cn-liferay-cas/index.html
所謂身份認證，就是判斷一個用戶是否為合法用戶的處理過程。最常用的簡單身份認證方式是系統通過核對用戶輸入的用戶名和口令，看其是否與系統中存儲的該用戶的用戶名和口令一致，來判斷用戶身份是否正確。復雜一些的身份認證方式採用一些較復雜的加密演算法與協議，需要用戶出示更多的信息(如私鑰)來證明自己的身份，如Kerberos身份認證系統。
目前基於SOA架構，可跨平台與多種類型的應用系統對接的統一身份認證平台也有很多，
身份存儲方式有：通用關系型資料庫、LDAP目錄、Microsoft Active Directory(AD)等形式，可選方案可參考《Web Service Case Study: 統一身份認證服務》
https://www.ibm.com/developerworks/cn/webservices/ws-casestudy/part4/
或《Liferay與CAS及LDAP》http://www.huqiwen.com/2013/12/18/liferay-cas-ldap/
❽ 單點登錄集成三方系統存儲的密碼密文怎麼辦
這個問題要詳細講就很長很復雜了，簡要說一下。
首先，你所說的「第三方登陸」概念很模糊，有很多方法可以實現。不過現在主流的方法是使用OAUTH授權，這里就簡單講一下。
流程：
A網站向第三方網站B申請使用相關登陸服務，B對A進行審核，通過後，B會提供給A相關的調用介面(api)和一些憑證，例如token、id、secret id等等。在用戶登錄時，A會向B提供的介面發送上面提到的憑證並將用戶引導到B的某一頁面進行輸入密碼等登陸操作，B在驗證A和用戶的合法性後，會將部分用戶信息（例如昵稱、郵箱等等，但不包括密碼）發送給A，某些網站B還會授權A對用戶的賬戶進行有限的操作（例如使用用戶賬戶發布信息（qq、微薄等）、讀取用戶的聯系人（gmail等），該授權可由用戶手動取消），A根據B返回的內容決定對用戶採取的後續操作（繼續完善注冊或者直接顯示內容）。
由上可知，至少在採取oAuth授權協議的網站，你的密碼不會泄露。事實上，絕大部分第三方登陸服務都不會泄露用戶密碼。
❾ cas 單點登錄是怎麼驗證密碼
通過上述部署與配置，多個Web應用已經可以共用一個登錄服務。但是，上述過程中作為CAS Client端的Web應用只取得了用戶登錄名稱信息，而在實際應用中，Web應用往往需要獲得登錄用戶更多的信息，例如會員等級、性別、住址等。要達到此目的，只需對Server端稍做修改即可實現。
1. 服務端配置及修改
假定上述存儲用戶信息的數據表userinfo中還包含一個名為address的用於存儲用戶地址的欄位，而Web應用程序希望能夠從CAS Server處獲得當前登錄用戶的地址信息，則Server端需要按以下內容修改deployerConfigContext.xml。部分配置說明請參見注釋。
<!--將原有attributeRepository配置注釋 -->
<!--
<beanid="attributeRepository"
class="org.jasig.services.persondir.support.StubPersonAttributeDao">
<propertyname="backingMap">
<map>
<entrykey="uid" value="uid" />
<entrykey="ePersonAffiliation" value="ePersonAffiliation"/>
<entrykey="groupMembership" value="groupMembership" />
</map>
</property>
</bean>
-->
<!--新增attributeRepository配置(開始) -->
<bean class="org.jasig.services.persondir.support.jdbc."id="attributeRepository">
<!-- 指定使用的數據源，此處dataSource是已配置好的數據源 -->
<constructor-arg index="0"ref="dataSource"/>
<!-- 從資料庫中查詢信息的SQL語句，通常只需要修改表名即可 -->
<constructor-arg index="1" value="select * fromuserinfo where {0}"/>
<propertyname="queryAttributeMapping">
<map>
<!-- 上述查詢的參數，將userName替換為表中表示用戶名的欄位名稱 -->
<entrykey="username" value="userName"/>
</map>
</property>
<propertyname="resultAttributeMapping">
<map>
<!-- 需要返回給Web應用的其它信息，多個信息時可繼續增加entry節點-->
<!--key值為數據表中的欄位名稱，value值為Client端取值時的名稱標識-->
<entry key="address" value="address"/>
</map>
</property>
</bean>
<!--新增attributeRepository配置(結束) -->
<bean
id="serviceRegistryDao"
class="org.jasig.cas.services.">
<propertyname="registeredServices">
<list>
<beanclass="org.jasig.cas.services.RegexRegisteredService">
<propertyname="id" value="0" />
<propertyname="name" value="HTTP and IMAP" />
<propertyname="description" value="Allows HTTP(S) and IMAP(S)protocols" />
<propertyname="serviceId" value="^(https?|imaps?)://.*" />
<propertyname="evaluationOrder" value="10000001" />
<!--增加此項配置 -->
<property name="ignoreAttributes" value="true"/>
</bean>
… …
</list>
</property>
</bean>
CASServer要將額外的信息傳遞至Client端，還需要修改完成信息組裝的文件WEB-INF/view/jsp/protocol/2.0/casServiceValidationSuccess.jsp。casServiceValidationSuccess.jsp負責組裝包含用戶信息的XML，因此修改部分是將需要傳遞的額外信息加入到它最終生成的XML文件之中。具體修改如下：
<cas:serviceResponsexmlns:cas=''>
<cas:authenticationSuccess> <cas:user>${fn:escapeXml(assertion.chainedAuthentications[fn:length(assertion.chainedAuthentications)-1].principal.id)}</cas:user>
<!-- 新增額外信息(開始) -->
<c:iftest="${fn:length(assertion.chainedAuthentications[fn:length(assertion.chainedAuthentications)-1].principal.attributes)> 0}">
<cas:attributes>
<c:forEachvar="attr"items="${assertion.chainedAuthentications[fn:length(assertion.chainedAuthentications)-1].principal.attributes}">
<!--注意此行的正確寫法，網上資料基本都是錯誤的--> <cas:${fn:escapeXml(attr.key)}>${fn:escapeXml(attr.value)}</cas:${fn:escapeXml(attr.key)}>
</c:forEach>
</cas:attributes>
</c:if>
<!-- 新增額外信息(結束) -->
<c:if test="${not emptypgtIou}">
<cas:proxyGrantingTicket>${pgtIou}</cas:proxyGrantingTicket>
</c:if>
<c:if test="${fn:length(assertion.chainedAuthentications)> 1}">
<cas:proxies>
<c:forEachvar="proxy" items="${assertion.chainedAuthentications}"varStatus="loopStatus" begin="0"end="${fn:length(assertion.chainedAuthentications)-2}"step="1">
<cas:proxy>${fn:escapeXml(proxy.principal.id)}</cas:proxy>
</c:forEach>
</cas:proxies>
</c:if>
</cas:authenticationSuccess>
</cas:serviceResponse>
2. java Client端取得更多用戶信息
Java Client端不需要做任何修改就可以繼續正常使用CAS服務，如果需要取得用戶更多信息，可以通過AttributePrincipal對象取得Attribute列表(一個Map對象)後進行查詢。
修改前述Java Client的示例代碼，在最後追加取得address信息的代碼，重啟服務並重新訪問頁面，可以看到頁面上顯示了當前用戶的address信息。
<%@pageimport="org.jasig.cas.client.authentication.AttributePrincipal" %>
<%@pageimport="org.jasig.cas.client.validation.Assertion" %>
<%@page import="java.util.*" %>
<%
String loginName1 = request.getRemoteUser();
%>
request.getRemoteUser(): <%=loginName1%><br/>
<%
AttributePrincipal principal = (AttributePrincipal)request.getUserPrincipal();
String loginName2 = principal.getName();
%>
request.getUserPrincipal().getName():<%=loginName2%><br/>
<%
Object object =request.getSession().getAttribute("_const_cas_assertion_");
Assertion assertion =(Assertion)object;
String loginName3 =assertion.getPrincipal().getName();
%>
request.getSession().getAttribute("_const_cas_assertion_").getPrincipal().getName():<%=loginName3%><br/>
❿ Java單點登錄安全性怎麼保障
首先，登錄伺服器與安全伺服器是否都可以做安全審計，確保記錄每一項操作內容。其次，應用伺服器的許可權也應該是分角色配置的，不同的角色擁有不同的許可權進行不同的操作，上文的URL就是指具體現操作吧。
這個有兩種選擇，一種是選擇專業的SSO產品，涉及比較大的建設和原有系統改造成本，另外可以考慮使用ssl vpn作為單點登錄的替代方案，ssl vpn有嚴格的身份認證、傳輸加密和細粒度的訪問授權控制（可以做到頁面級），只要你所購買的ssl vpn支持單點登錄功能就能夠實現大部分web應用和cs應用通過自動填表功能完成單點登錄（如果有統一的域認證或radius認證實現起來更簡單）
網關是要和密鑰綁定的，並且分在線和旁路兩種。如果是旁路，則一次登錄，不再認證；如果是在線，則每次發起訪問都要重新更新登錄信息。按照你說的跳轉，應該是旁路方式，傳輸的安全性不由網關保證，直接盜取文件的URL，由於沒有身份，是無法訪問的。
旁路網關的作用是避免客戶端直接登錄應用系統，避免通過提交特殊字元串的BS方式攻擊，應用系統是不提供直接URL的登錄界面的。這個當然需要應用系統重新改良一下，以滿足網關登錄的方式。
如果你說的傳輸安全性是線路盜取信息，那不是網關的事兒，那是信息加密的事兒。
建議應用系統里對每一次登錄緩存其登錄位置信息等，設置睡眠時間即多長時間不操作就斷開並清除該緩存。如果網關支持的話，其實最好是在線網關，每次訪問都通過網關伺服器，應用系統只處理網關伺服器的ip提交的訪問，其他訪問一概拒絕，則解決你的安全需求。