單點登陸代碼
㈠ java單點登陸和重復登陸有什麼區別存在怎樣的聯系能否給出形象的解釋望給出代碼啊！
希望來你能夠明白單點登錄的概念自和意義，我們做單點登陸一般的場景是多個獨立的系統需要用同一套鑒權系統來認證，可以自己用java來實現，但肯定還有別的技術，不管是CS還是BS系統。
核心就是各個系統把鑒權服務交給單點登陸系統來做，把登陸信息發送給單點登陸系統，系統鑒權成功後會返回消息。直接登陸系統就好。
目前互聯網論壇訪問流行的用微博賬號或QQ賬號登陸，也是一種登陸服務，當然需要開發他們的介面。
怎麼做就看你有什麼需求，方法很多
㈡ 用java來實現單點登錄大概有哪些種方法
1 什麼是單點登陸
單點登錄（Single Sign On），簡稱為 SSO，是目前比較流行的企業業務整合的解決方案之一。SSO的定義是在多個應用系統中，用戶只需要登錄一次就可以訪問所有相互信任的應用系統。
較大的企業內部，一般都有很多的業務支持系統為其提供相應的管理和IT服 務。例如財務系統為財務人員提供財務的管理、計算和報表服務；人事系統為人事部門提供全公司人員的維護服務；各種業務系統為公司內部不同的業務提供不同的 服務等等。這些系統的目的都是讓計算機來進行復雜繁瑣的計算工作，來替代人力的手工勞動，提高工作效率和質量。這些不同的系統往往是在不同的時期建設起來 的，運行在不同的平台上；也許是由不同廠商開發，使用了各種不同的技術和標准。如果舉例說國內一著名的IT公司（名字隱去），內部共有60多個業務系統，這些系統包括兩個不同版本的SAP的ERP系統，12個不同類型和版本的資料庫系統，8個不同類型和版本的操作系統，以及使用了3種不同的防火牆技術，還有數十種互相不能兼容的協議和標准，你相信嗎？不要懷疑，這種情況其實非常普遍。每一個應用系統在運行了數年以後，都會成為不可替換的企業IT架構的一部分，如下圖所示。
隨 著企業的發展，業務系統的數量在不斷的增加，老的系統卻不能輕易的替換，這會帶來很多的開銷。其一是管理上的開銷，需要維護的系統越來越多。很多系統的數 據是相互冗餘和重復的，數據的不一致性會給管理工作帶來很大的壓力。業務和業務之間的相關性也越來越大，例如公司的計費系統和財務系統，財務系統和人事系 統之間都不可避免的有著密切的關系。
為了降低管理的消耗，最大限度的重用已有投資的系統，很多企業都在進行著企業應用集成（EAI）。 企業應用集成可以在不同層面上進行：例如在數據存儲層面上的「數據大集中」，在傳輸層面上的「通用數據交換平台」，在應用層面上的「業務流程整合」，和用 戶界面上的「通用企業門戶」等等。事實上，還用一個層面上的集成變得越來越重要，那就是「身份認證」的整合，也就是「單點登錄」。
通常來說，每個單獨的系統都會有自己的安全體系和身份認證系統。整合以前，進入每個系統都需要進行登錄，這樣的局面不僅給管理上帶來了很大的困難，在安全方面也埋下了重大的隱患。下面是一些著名的調查公司顯示的統計數據：
用戶每天平均 16 分鍾花在身份驗證任務上 - 資料來源： IDS
頻繁的 IT 用戶平均有 21 個密碼 - 資料來源： NTA Monitor Password Survey
49% 的人寫下了其密碼，而 67% 的人很少改變它們
每 79 秒出現一起身份被竊事件 - 資料來源：National Small Business Travel Assoc
全球欺騙損失每年約 12B - 資料來源：Comm Fraud Control Assoc
到 2007 年，身份管理市場將成倍增長至 $4.5B - 資料來源：IDS
使用「單點登錄」整合後，只需要登錄一次就可以進入多個系統，而不需要重新登錄，這不僅僅帶來了更好的用戶體驗，更重要的是降低了安全的風險和管理的消耗。請看下面的統計數據：
提高 IT 效率：對於每 1000 個受管用戶，每用戶可節省$70K
幫助台呼叫減少至少1/3，對於 10K 員工的公司，每年可以節省每用戶 $75，或者合計 $648K
生產力提高：每個新員工可節省 $1K，每個老員工可節省 $350 �資料來源：Giga
ROI 回報：7.5 到 13 個月 �資料來源：Gartner
另外，使用「單點登錄」還是SOA時代的需求之一。在面向服務的架構中，服務和服務之間，程序和程序之間的通訊大量存在，服務之間的安全認證是SOA應用的難點之一，應此建立「單點登錄」的系統體系能夠大大簡化SOA的安全問題，提高服務之間的合作效率。
2 單點登陸的技術實現機制
隨著SSO技術的流行，SSO的產品也是滿天飛揚。所有著名的軟體廠商都提供了相應的解決方案。在這里我並不想介紹自己公司（Sun Microsystems）的產品，而是對SSO技術本身進行解析，並且提供自己開發這一類產品的方法和簡單演示。有關我寫這篇文章的目的，請參考我的博客（http://yuwang881.blog.sohu.com/3184816.html）。
單 點登錄的機制其實是比較簡單的，用一個現實中的例子做比較。頤和園是北京著名的旅遊景點，也是我常去的地方。在頤和園內部有許多獨立的景點，例如「蘇州 街」、「佛香閣」和「德和園」，都可以在各個景點門口單獨買票。很多遊客需要遊玩所有德景點，這種買票方式很不方便，需要在每個景點門口排隊買票，錢包拿 進拿出的，容易丟失，很不安全。於是絕大多數遊客選擇在大門口買一張通票（也叫套票），就可以玩遍所有的景點而不需要重新再買票。他們只需要在每個景點門 口出示一下剛才買的套票就能夠被允許進入每個獨立的景點。
單點登錄的機制也一樣，如下圖所示，當用戶第一次訪問應用系統1的時候，因為還沒有登錄，會被引導到認證系統中進行登錄（1）；根據用戶提供的登錄信息，認證系統進行身份效驗，如果通過效驗，應該返回給用戶一個認證的憑據－－ticket（2）；用戶再訪問別的應用的時候（3，5）就會將這個ticket帶上，作為自己認證的憑據，應用系統接受到請求之後會把ticket送到認證系統進行效驗，檢查ticket的合法性（4，6）。如果通過效驗，用戶就可以在不用再次登錄的情況下訪問應用系統2和應用系統3了。
從上面的視圖可以看出，要實現SSO，需要以下主要的功能：
所有應用系統共享一個身份認證系統。
統一的認證系統是SSO的前提之一。認證系統的主要功能是將用戶的登錄信息和用戶信息庫相比較，對用戶進行登錄認證；認證成功後，認證系統應該生成統一的認證標志（ticket），返還給用戶。另外，認證系統還應該對ticket進行效驗，判斷其有效性。
所有應用系統能夠識別和提取ticket信息
要實現SSO的功能，讓用戶只登錄一次，就必須讓應用系統能夠識別已經登錄過的用戶。應用系統應該能對ticket進行識別和提取，通過與認證系統的通訊，能自動判斷當前用戶是否登錄過，從而完成單點登錄的功能。
上面的功能只是一個非常簡單的SSO架構，在現實情況下的SSO有著更加復雜的結構。有兩點需要指出的是：
單一的用戶信息資料庫並不是必須的，有許多系統不能將所有的用戶信息都集中存儲，應該允許用戶信息放置在不同的存儲中，如下圖所示。事實上，只要統一認證系統，統一ticket的產生和效驗，無論用戶信息存儲在什麼地方，都能實現單點登錄。
統一的認證系統並不是說只有單個的認證伺服器，如下圖所示，整個系統可以存在兩個以上的認證伺服器，這些伺服器甚至可以是不同的產品。認證伺服器之間要通過標準的通訊協議，互相交換認證信息，就能完成更高級別的單點登錄。如下圖，當用戶在訪問應用系統1時，由第一個認證伺服器進行認證後，得到由此伺服器產生的ticket。當他訪問應用系統4的時候，認證伺服器2能夠識別此ticket是由第一個伺服器產生的，通過認證伺服器之間標準的通訊協議（例如SAML）來交換認證信息，仍然能夠完成SSO的功能。
3 WEB-SSO的實現
隨著互聯網的高速發展，WEB應用幾乎統治了絕大部分的軟體應用系統，因此WEB-SSO是SSO應用當中最為流行。WEB-SSO有其自身的特點和優勢，實現起來比較簡單易用。很多商業軟體和開源軟體都有對WEB-SSO的實現。其中值得一提的是OpenSSO （https://opensso.dev.java.net），為用Java實現WEB-SSO提供架構指南和服務指南，為用戶自己來實現WEB-SSO提供了理論的依據和實現的方法。
為什麼說WEB-SSO比較容易實現呢？這是有WEB應用自身的特點決定的。
眾所周知，Web協議（也就是HTTP）是一個無狀態的協議。一個Web應用由很多個Web頁面組成，每個頁面都有唯一的URL來定義。用戶在瀏覽器的地址欄輸入頁面的URL，瀏覽器就會向Web Server去發送請求。如下圖，瀏覽器向Web伺服器發送了兩個請求，申請了兩個頁面。這兩個頁面的請求是分別使用了兩個單獨的HTTP連接。所謂無狀態的協議也就是表現在這里，瀏覽器和Web伺服器會在第一個請求完成以後關閉連接通道，在第二個請求的時候重新建立連接。Web伺服器並不區分哪個請求來自哪個客戶端，對所有的請求都一視同仁，都是單獨的連接。這樣的方式大大區別於傳統的（Client/Server）C/S結構,在那樣的應用中，客戶端和伺服器端會建立一個長時間的專用的連接通道。正是因為有了無狀態的特性，每個連接資源能夠很快被其他客戶端所重用，一台Web伺服器才能夠同時服務於成千上萬的客戶端。
但是我們通常的應用是有狀態的。先不用提不同應用之間的SSO，在同一個應用中也需要保存用戶的登錄身份信息。例如用戶在訪問頁面1的時候進行了登錄，但是剛才也提到，客戶端的每個請求都是單獨的連接，當客戶再次訪問頁面2的時候，如何才能告訴Web伺服器，客戶剛才已經登錄過了呢？瀏覽器和伺服器之間有約定：通過使用cookie技術來維護應用的狀態。Cookie是可以被Web伺服器設置的字元串，並且可以保存在瀏覽器中。如下圖所示，當瀏覽器訪問了頁面1時，web伺服器設置了一個cookie，並將這個cookie和頁面1一起返回給瀏覽器，瀏覽器接到cookie之後，就會保存起來，在它訪問頁面2的時候會把這個cookie也帶上，Web伺服器接到請求時也能讀出cookie的值，根據cookie值的內容就可以判斷和恢復一些用戶的信息狀態。
Web-SSO完全可以利用Cookie結束來完成用戶登錄信息的保存，將瀏覽器中的Cookie和上文中的Ticket結合起來，完成SSO的功能。
為了完成一個簡單的SSO的功能，需要兩個部分的合作：
統一的身份認證服務。
修改Web應用，使得每個應用都通過這個統一的認證服務來進行身份效驗。
3.1 Web SSO 的樣例
根據上面的原理，我用J2EE的技術（JSP和Servlet）完成了一個具有Web-SSO的簡單樣例。樣例包含一個身份認證的伺服器和兩個簡單的Web應用，使得這兩個 Web應用通過統一的身份認證服務來完成Web-SSO的功能。此樣例所有的源代碼和二進制代碼都可以從網站地址http://gceclub.sun.com.cn/wangyu/ 下載。
樣例下載、安裝部署和運行指南：
Web-SSO的樣例是由三個標准Web應用組成，壓縮成三個zip文件，從http://gceclub.sun.com.cn/wangyu/web-sso/中下載。其中SSOAuth（http://gceclub.sun.com.cn/wangyu/web-sso/SSOAuth.zip）是身份認證服務；SSOWebDemo1（http://gceclub.sun.com.cn/wangyu/web-sso/SSOWebDemo1.zip）和SSOWebDemo2（http://gceclub.sun.com.cn/wangyu/web-sso/SSOWebDemo2.zip）是兩個用來演示單點登錄的Web應用。這三個Web應用之所以沒有打成war包，是因為它們不能直接部署，根據讀者的部署環境需要作出小小的修改。樣例部署和運行的環境有一定的要求，需要符合Servlet2.3以上標準的J2EE容器才能運行（例如Tomcat5,Sun Application Server 8, Jboss 4等）。另外，身份認證服務需要JDK1.5的運行環境。之所以要用JDK1.5是因為筆者使用了一個線程安全的高性能的Java集合類「ConcurrentMap」，只有在JDK1.5中才有。
這三個Web應用完全可以單獨部署，它們可以分別部署在不同的機器，不同的操作系統和不同的J2EE的產品上，它們完全是標準的和平台無關的應用。但是有一個限制，那兩台部署應用（demo1、demo2）的機器的域名需要相同，這在後面的章節中會解釋到cookie和domain的關系以及如何製作跨域的WEB-SSO
解壓縮SSOAuth.zip文件，在/WEB-INF/下的web.xml中請修改「domainname」的屬性以反映實際的應用部署情況，domainname需要設置為兩個單點登錄的應用（demo1和demo2）所屬的域名。這個domainname和當前SSOAuth服務部署的機器的域名沒有關系。我預設設置的是「.sun.com」。如果你部署demo1和demo2的機器沒有域名，請輸入IP地址或主機名（如localhost），但是如果使用IP地址或主機名也就意味著demo1和demo2需要部署到一台機器上了。設置完後，根據你所選擇的J2EE容器，可能需要將SSOAuth這個目錄壓縮打包成war文件。用「jar -cvf SSOAuth.war SSOAuth/」就可以完成這個功能。
解壓縮SSOWebDemo1和SSOWebDemo2文件，分別在它們/WEB-INF/下找到web.xml文件，請修改其中的幾個初始化參數
<init-param>
<param-name>SSOServiceURL</param-name>
<param-value>http://wangyu.prc.sun.com:8080/SSOAuth/SSOAuth</param-value>
</init-param>
<init-param>
<param-name>SSOLoginPage</param-name>
<param-value>http://wangyu.prc.sun.com:8080/SSOAuth/login.jsp</param-value>
</init-param>
將其中的SSOServiceURL和SSOLoginPage修改成部署SSOAuth應用的機器名、埠號以及根路徑（預設是SSOAuth）以反映實際的部署情況。設置完後，根據你所選擇的J2EE容器，可能需要將SSOWebDemo1和SSOWebDemo2這兩個目錄壓縮打包成兩個war文件。用「jar -cvf SSOWebDemo1.war SSOWebDemo1/」就可以完成這個功能。
請輸入第一個web應用的測試URL（test.jsp）,例如http://wangyu.prc.sun.com:8080/ SSOWebDemo1/test.jsp，如果是第一次訪問，便會自動跳轉到登錄界面，如下圖
使用系統自帶的三個帳號之一登錄（例如，用戶名：wangyu,密碼：wangyu），便能成功的看到test.jsp的內容：顯示當前用戶名和歡迎信息。
請接著在同一個瀏覽器中輸入第二個web應用的測試URL（test.jsp）,例如http://wangyu.prc.sun.com:8080/ SSOWebDemo2/test.jsp。你會發現，不需要再次登錄就能看到test.jsp的內容，同樣是顯示當前用戶名和歡迎信息，而且歡迎信息中明確的顯示當前的應用名稱（demo2）。
3.2 WEB-SSO代碼講解
3.2.1身份認證服務代碼解析
Web-SSO的源代碼可以從網站地址http://gceclub.sun.com.cn/wangyu/web-sso/websso_src.zip下載。身份認證服務是一個標準的web應用，包括一個名為SSOAuth的Servlet，一個login.jsp文件和一個failed.html。身份認證的所有服務幾乎都由SSOAuth的Servlet來實現了；login.jsp用來顯示登錄的頁面（如果發現用戶還沒有登錄過）；failed.html是用來顯示登錄失敗的信息（如果用戶的用戶名和密碼與信息資料庫中的不一樣）。
SSOAuth的代碼如下面的列表顯示，結構非常簡單，先看看這個Servlet的主體部分：
?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
package DesktopSSO;
import java.io.*;
import java.net.*;
import java.text.*;
import java.util.*;
import java.util.concurrent.*;
import javax.servlet.*;
import javax.servlet.http.*;
public class SSOAuth extends HttpServlet {
static private ConcurrentMap accounts;
static private ConcurrentMap SSOIDs;
String cookiename="WangYuDesktopSSOID";
String domainname;
public void init(ServletConfig config) throws ServletException {
super.init(config);
domainname= config.getInitParameter("domainname");
cookiename = config.getInitParameter("cookiename");
SSOIDs = new ConcurrentHashMap();
accounts=new ConcurrentHashMap();
accounts.put("wangyu", "wangyu");
accounts.put("paul", "paul");
accounts.put("carol", "carol");
}
protected void processRequest(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
PrintWriter out = response.getWriter();
String action = request.getParameter("action");
String result="failed";
if (action==null) {
handlerFromLogin(request,response);
} else if (action.equals("authcookie")){
String myCookie = request.getParameter("cookiename");
if (myCookie != null) result = authCookie(myCookie);
out.print(result);
out.close();
} else if (action.equals("authuser")) {
result=authNameAndPasswd(request,response);
out.print(result);
out.close();
} else if (action.equals("logout")) {
String myCookie = request.getParameter("cookiename");
logout(myCookie);
out.close();
}
}
.....
}
從代碼很容易看出，SSOAuth就是一個簡單的Servlet。其中有兩個靜態成員變數：accounts和SSOIDs，這兩個成員變數都使用了JDK1.5中線程安全的MAP類： ConcurrentMap，所以這個樣例一定要JDK1.5才能運行。Accounts用來存放用戶的用戶名和密碼，在init()的方法中可以看到我給系統添加了三個合法的用戶。在實際應用中，accounts應該是去資料庫中或LDAP中獲得，為了簡單起見，在本樣例中我使用了ConcurrentMap在內存中用程序創建了三個用戶。而SSOIDs保存了在用戶成功的登錄後所產生的cookie和用戶名的對應關系。它的功能顯而易見：當用戶成功登錄以後，再次訪問別的系統，為了鑒別這個用戶請求所帶的cookie的有效性，需要到SSOIDs中檢查這樣的映射關系是否存在。
在主要的請求處理方法processRequest()中，可以很清楚的看到SSOAuth的所有功能
如果用戶還沒有登錄過，是第一次登錄本系統，會被跳轉到login.jsp頁面（在後面會解釋如何跳轉）。用戶在提供了用戶名和密碼以後，就會用handlerFromLogin()這個方法來驗證。
如果用戶已經登錄過本系統，再訪問別的應用的時候，是不需要再次登錄的。因為瀏覽器會將第一次登錄時產生的cookie和請求一起發送。效驗cookie的有效性是SSOAuth的主要功能之一。
SSOAuth還能直接效驗非login.jsp頁面過來的用戶名和密碼的效驗請求。這個功能是用於非web應用的SSO，這在後面的桌面SSO中會用到。
SSOAuth還提供logout服務。
㈢ 單點登錄，java實現
可以直接通過玉符科技IDAAS平台來實現單點登錄，支持所有的標准協議，如果是老舊或者自研的系統，也有SDK去適配所有的開發語言，不止是java。
玉符單點登錄
㈣ java 單點登錄
單點登錄（SSO）的技術被越來越廣泛地運用到各個領域的軟體系統中。http://wenku..com/view/9cd850a8284ac850ad02422d.html
本文從業務的角度分析了單點登錄的需求和應用領域；從技術本身的角度分析了單點登錄技術的內部機制和實現手段，並且給出Web-SSO和桌面SSO的實現、源代碼和詳細講解；還從安全和性能的角度對現有的實現技術進行進一步分析，指出相應的風險和需要改進的方面。本文除了從多個方面和角度給出了對單點登錄（SSO）的全面分析，還並且討論了如何將現有的應用和SSO服務結合起來，能夠幫助應用架構師和系統分析人員從本質上認識單點登錄，從而更好地設計出符合需要的安全架構。
更深入學習請到廣州達內 www.ittarena.com
㈤ 單點登錄cas 中不需要自己寫代碼實現嗎
CAS 原理和協議 從結構上看，CAS 包含兩個部分： CAS Server 和 CAS Client。CAS Server 需要獨立部署，主要負責對用戶的認證工作
㈥ 誰有SSO單點登錄的簡單實現代碼。（最好是用 struts1 或 JSP+Servlet 實現）。求代碼，謝
http://www.51aspx.com/CV/SSO/
這個主要是用asp.net的
輕量級單點登錄系統源碼
實現原理：
使用使用<script type="text/javascript" src="http://localhost:7771/SSOSite/SSOContext.aspx?app=portal"> </script>形式遠程調用單點登錄系統上的腳本，獲取加密後的用戶登錄票據信息，自動綁定到當前頁表單的相應欄位，並自動提交到後台。後台解密前台提交的用戶登錄票據信息，判定用戶是否已在單點登錄系統上成功的登錄，如果已登錄返回系統首頁，如果沒有登錄，跳轉到單點登錄系統登錄頁。使用DES加密用戶登錄票據信息,不同應用系統使用不同密鑰。
開發環境（VS2008 + Eclipse3.2）
輕量級單點登錄系統解決方案包括以下項目：
1、公共組件SSOLab.SSOServer.Components
2、單點登錄系統SSOLab.SSOServer.WebApp
3、企業門戶系統系統演示SSOLab.Portal.WebApp
4、人力資源管理系統演示SSOLab. APP1. WebApp
5、財務管理系統演示SSOLab. APP2. WebApp
㈦ 如何用java實現單點登錄，最好能有代碼
單點登陸的話,你可以使用token來實現,比如一個用戶一次只生成一個token,這樣別人在訪問的時候,就會重新生成一個,之前的就會被踢出線
㈧ php 單點登錄代碼
假設有三個不同域名，a.com, b.com, c.com，將其中之一作為真正的登陸入口，所有的域名下發起的登陸，全部重定向到這個節點，這里假設選擇a.com/login.php為統一登入節點，為了方便說明，把a.com叫做主節點，其餘叫做從節點。
假設現在從任意站點發出登陸請求，最終都被帶到 a.com/login.php?from=b.com&sfkey=xxxxxx，用戶輸入登陸信息，假設登陸成功，返回一個登陸成功中間頁面，在這個頁面里，包含下面html代碼
<iframe width="0" height="0" src="b.com/sso.php?sessid=xxxxxxxxxxxx&sfkey=xxxxxxxxxxx"></iframe>
<iframe width="0" height="0" src="c.com/sso.php?sessid=xxxxxxxxxxxx&sfkey=xxxxxxxxxxx"></iframe>
sessid是登陸成功以後的session ID，sfkey是一個安全碼，這兩個串在login.php里綁定到當前登陸的用戶記錄上。
這個時候a.com實際已經登陸完畢，獲得了PHPSESSID的cookie。兩個iframe的作用是把獲得的session id立刻同步到從節點上，從節點的sso.php獲得sessid和sfkey後，首先校驗這個配對是否存在，如果存在，立刻把sessid值設為當前session id
session_id($_GET['sessid']); // 使用a.com產生的session id
session_start();
sso.php請求完畢後，b.com和c.com這兩個站點就獲得了和a.com一樣的PHPSESSID cookie；
這個頁面會把用戶重定向回所來自的頁面（到達login.php的時候記住了），重定向完成後，用戶已經在所有網站完成了同步登陸。
a.com發送iframe請求的時候使用加密的sessid=xxxxxx里的sessid，從節點的sso.php獲取密文後解密才獲得真實的session id
可以用單獨域名來作為登陸主節點，比如login.x.com，而不用a b c中的任意一個，login.x.com做且僅作登陸服務。
㈨ 怎麼實現簡單單點登錄
所謂單點登錄（Single Sign On就是在多個應用系統中，用戶只需要登錄一次就可以訪問所有相互信任的應用系統。其實對於程序員在技術上要實現就得就是多個不同域名間共享cookie的問題。
最近在為ERP添加一個部署在另一台機器上，鏈接到原有老系統中的子項目，調用原有老項目中的Login實現單點登錄，嘗試了N次屢試不成，最後確定問題，是，.net2.0與4.0中對cookie的加密/解密方法由此差異，於是經過研究，重寫實現了一個可以在不同.net版本中實現單點登錄的簡單方法。
代碼：
protected void btnLogin_Click(object sender, EventArgs e)
{
//認證開票，跳轉到原始請求頁面
System.Web.Security.FormsAuthentication.RedirectFromLoginPage("ejiyuan", false);
}
配置文件：
<!--訪問許可權控制-->
<authorization>
<deny users="?"/>
</authorization>
<!--身份認證方式-->
<authentication mode="Forms">
<forms name=".ASPNET" protection="All" enableCrossAppRedirects="true" loginUrl="Login.aspx" timeout="2880" path="/" domain=".local.com"/>
</authentication>
<!--驗證演算法-->
<machineKey validationKey="" decryptionKey="F8D923AC" validation="SHA1" decryption="3DES" /> <compilation debug="true"/>