单点登录SSO详解

2013-03-22和鸣605楼整理，大四没学生正好整理了，呵呵！（材料来源于网络）

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的产品也是满天飞扬。所有著名的软件厂商都提供了相应的解决方案。而是对SSO技术本身进行解析，并且提供自己开发这一类产品的方法和简单演示。

单点登录的机制其实是比较简单的，用一个现实中的例子做比较。颐和园是北京著名的旅游景点。在颐和园内部有许多独立的景点，例如“苏州街”、“佛香阁”和“德和园”，都可以在各个景点门口单独买票。很多游客需要游玩所有德景点，这种买票方式很不方便，需要在每个景点门口排队买票，钱包拿进拿出的，容易丢失，很不安全。于是绝大多数游客选择在大门口买一张通票（也叫套票），就可以玩遍所有的景点而不需要重新再买票。他们只需要在每个景点门口出示一下刚才买的套票就能够被允许进入每个独立的景点。

单点登录的机制也一样，如下图所示，当用户第一次访问应用系统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的实现（ASP.NET安全认证）

ASP.NET 的安全认证，共有“Windows”“Form”“Passport”“None”四种验证模式。“Windows”与“None”没有起到保护的作用，不推荐使用；“Passport”我又没用过，唉……所以我只好讲讲“Form”认证了。我打算分三部分：

第一部分 —— 怎样实现From 认证；

第二部分 —— Form 认证的实战运用；

第三部分 —— 实现单点登录（Single Sign On）

3.1 第一部分 ——怎样实现From认证；

一、新建一个测试项目

为了更好说明，有必要新建一个测试项目（暂且为“FormTest”吧），包含三张页面足矣（Default.aspx、Login.aspx、UserInfo.aspx）。啥？有人不会新建项目，不会新增页面？你问我咋办？我看这么办好了：拖出去，打回原藉，从幼儿园学起……

二、修改 Web.config

1、双击项目中的Web.config（不会的、找不到的打 PP）

2、找到下列文字 <authentication mode="Windows" />把它改成：

<authentication mode="Forms">

<forms loginUrl="Login.aspx" name=".ASPXAUTH"></forms>

</authentication>

3、找到<authorization> <allow users="*" /></authorization>换成

<authorization><deny users="?"></deny></authorization>

这里没什么好说的，只要拷贝过去就行。虽说如此，但还是有人会弄错，如下：

<authentication mode="Forms">

 <forms loginUrl="Login.aspx" name=".APSX"></forms>

<deny users="?"></deny>

 </authentication>

若要问是谁把 <deny users="?"></deny>放入 <authentication>中的，我会很荣幸地告诉你，那是 N年前的我：<authentication>与 <authorization>都是以 auth字母开头又都是以 ation结尾，何其相似；英文单词背不下来的我以为他们是一伙的……

三、编写 .cs 代码——登录与退出

1、登录代码：

a、书本上介绍的

    private void Btn_Login_Click(object sender, System.EventArgs e)

       {

          if(this.Txt_UserName.Text=="Admin" && this.Txt_Password.Text=="123456")

           {

  System.Web.Security.FormsAuthentication.RedirectFromLoginPage(this.Txt_UserName.Text,false);

  }

       }

b、偶找了 N久才找到的

private void Btn_Login_Click(object sender, System.EventArgs e)

         {

              if(this.Txt_UserName.Text=="Admin" && this.Txt_Password.Text=="123456")

              {

System.Web.Security.FormsAuthentication.SetAuthCookie(this.Txt_UserName.Text,false);

     Response.Redirect("Default.aspx");

     }

}

以上两种都可发放验证后的 Cookie，即通过验证，区别：

方法 a) 指验证后返回请求页面，俗称“从哪来就打哪去”。比如：用户没登录前直接在 IE地址栏输入 http://localhost/FormTest/UserInfo.aspx，那么该用户将看到的是 Login.aspx?ReturnUrl=UserInfo.aspx，输入用户名与密码登录成功后，系统将根据“ReturnUrl”的值，返回相应的页面

方法 b) 则是分两步走：通过验证后就直接发放 Cookie，跳转页面将由程序员自行指定，此方法多用于 Default.aspx使用框架结构的系统。

2、退出代码：

private void Btn_LogOut_Click(object sender, System.EventArgs e)

{

System.Web.Security.FormsAuthentication.SignOut();

}

四、如何判断验证与否及获取验证后的用户信息

有的时候，在同一张页面需要判断用户是否已经登录，然后再呈现不同的布局。有人喜欢用 Session来判断，我不反对此类做法，在此我只是想告诉大家还有一种方法，且看下面代码：

if(User.Identity.IsAuthenticated)

         {

              //你已通过验证，知道该怎么做了吧？

}

3.2 第二部分 Form认证的实战运用

五、 Web.config 的作用范围

新建项目时， VS.Net 会在项目根目录建立一个内容固定的 Web.config。除了在项目根目录，你还可以在任一目录下建立 Web.config，条件就是应用程序级别的节点只能在根目录的 Web.config中出现。至于哪些是应用程序级别节点呢，这个问题嘛，其实我也不太清楚，呵呵。电脑不是我发明的，微软不是我创建的，C#更不是我说了算的，神仙也有不知道的，所以我不晓得是正常的。话虽如此，只要它不报错，那就是对的。

关于 Web.config 设置的作用范围，记住以下两点：

1、 Web.config的设置将作用于所在目录的所有文件及其子目录下的所有东东（继承：子随父姓）

2、子目录下的 Web.config设置将覆盖由父目录继承下来的设置（覆盖：县官不如现管）

给大家提个问题：有没有比根目录Web.config的作用范围还大的配置文件呢？看完第三部分便知分晓。

六、学会拒绝与巧用允许

回到我们在第一回合新建的测试项目“FormTest”，既然要进行验证，按国际惯例，就得有用户名与密码。那，这些用户是管理员自己在数据库建好呢，还是用户注册、管理员审核好呢。只要不是一般的笨蛋，都知道选择后者。你们还别说，我公司还真有个别项目是管理员连到数据库去建帐号的，属于比较特殊的笨蛋，咱们不学他也罢，还是老老实实添加两个页面吧——注册页面（Register.aspx）与审核页面（Auditing.aspx）。

问题终于就要浮出水面啦，当你做好 Register.aspx时，想访问它的时候突然觉得不对劲，怎么又回到了登录页面？你仔细瞧瞧网址，是不是成了：Login.aspx?ReturnUrl=Register.aspx。怎么办，用户就是因为没有帐号才去访问注册页面的呀？（这句纯属废话，有帐号谁还跑去注册。）我时常对我的同事说：“办法是人想出来滴！！”

1、新建一个目录 Public，用于存放一些公用的文件，如万年历、脚本呀……

2、在“解决方案资源管理器”中右击点击目录 Public，新增一个 Web.config

3、把上述 Web.config的内容统统删除，仅留以下即可：

<?xml version="1.0" encoding="utf-8"?>

<configuration>

  <system.web>

   <authorization><allow users="*"/></authorization>

 </system.web>

</configuration>

终于切入正题了，不容易呀。根据“覆盖”原则，我们知道上述 Web.config将替代根目录 Web.config中的 <authorization>节点设置，即：

<allow users="*"/> 替换 <deny users="?"></deny>

注解：“allow”允许的意思；“*”表示所有用户；

“deny” 拒绝的意思；“?”表示匿名用户；

因此，处于 Public 目录下的文件，允许所有人浏览，包括未验证的用户。把 Register.aspx 拖进来吧，再也不会有人阻止你浏览啦。

除了注册页面，我们还提到一个审核页面（Auditing.aspx），审核权限一般都在管理员或主管手里，并不想让其他人浏览此页面（真理往往掌握在少数人的手里，这也是没法子的事），怎么办？“办法是人想出来滴”呵呵……新建一个管理员的目录 ManageSys ，在此目录下再新增一个 Web.config。内容如下：

<?xml version="1.0" encoding="utf-8"?>

<configuration>

<system.web>

<authorization>

<allow users="Admin"/>

<deny users="*"/>

</authorization>

  </system.web>

</configuration>

现在的问题就是怎么才能知道谁是“Admin”呢，这个问题就有点象“我的鞋底有个洞”——天不知地知，你不知我知。闲话少说，大家还记得我在第一部分的结尾吗？什么，忘啦！罚你回去看一百遍，记住了再回来。站住，回来！一想到你的记性，我就不放心，第一部分的浏览网址是http://blog.csdn.net/cityhunter172/archive/2005/11/06/524043.aspx，回到此处的网址是http://blog.csdn.net/cityhunter172/archive/2005/11/13/528463.aspx

好了，不管那些记不好的家伙了，大伙继续往下看。

System.Web.Security.FormsAuthentication.SetAuthCookie(this.Txt_UserName.Text,false); //通过验证，发放 Cookie

之前我曾强调，要注意，第一个参数很重要，重要到什么程度？说到这，恐怕地球人都知道了——它就是allow与deny的依据。假如此处用户填写的是“Admin”即 this.Txt_UserName.Text = "Admin"; 那么进入系统后，他就能访问 ManageSys目录下的网页了，其它闲杂人等一律拒之门外。

为巩固上述内容，给大伙留个课外作业：此项目有两部门使用，其中每个部门分别都有些特定的页面仅供本部门用户浏览使用，请问该如何使用 Web.config达到效果？同样，答案在第三部分揭晓

七、分散与集中

乍看之下，就象是马克思列宁主义、毛泽东思想、邓小平理论中的辩证关系，大伙放心，偶是学理科的，只明白“高举程序员的伟大旗帜，以编写代码为中心”。停……

到目前为此，我们的测试项目“FormTest”已经拥有两个目录三个 Web.config，伴随用户需求的多样化，Web.config也会越来越多，比如常用的文件上传功能等等。众多的 Web.config分布在不同的目录里面，维护起来肯定比较烦人。能不能集中起来管理呢，应该咋办哩？“办法是……”哟，有人先说出来啦。不错，“办法的确是人想出来滴”，我不说，你是不是只有在一边凉伴？开玩笑的，为了让更多的人记住这句话，我打算告诉你集中管理的办法。

要想集中管理，不得不用到 <location>节点与 path属性。在本项目中，我们将目录 Public与 ManageSys下的设置放在根目录下的 Web.config里面，如下：

<?xml version="1.0" encoding="utf-8"?>

<configuration>

<location path ="Public">

            <system.web>

                <authorization>

<allow users="*"/>

</authorization>

            </system.web>

       </location>

<location path ="ManageSys">

            <system.web>

       <authorization>

<allow users="Admin"/>

<deny users="*"/>

</authorization>

            </system.web>

       </location>

       <system.web>

　

                   <!-- 这里放置原来根目录 Web.config 的内容，就不列出来了 -->

　

       </system.web>

</configuration>

需要提醒的是

1、 <location>节点的位置是在 <configuration>的一个子节点，它与原有的 <system.web>属于并列关系

2、 <location>节点只需要放入对应子目录 Web.config中的 <system.web>的节点内容

八、额外的保护

第二部分就要结束了，现在时间已是凌晨 4点50分，我容易嘛我。认证的目的就是为了防止他人非法浏览页面，或未经许可使用某些功能。当然，世上没有绝对的安全，如今 MD5加密都被我们国人给破解了，就是最好的例证。

细心的人可能早就发现 ASP.NET的安全认证只针对 .aspx、.ascx ……等 ASP.NET文件起作用，而对普通页面与文件却“视而不见”，如 .htm、.js、.jpg等。通过以下步骤你就可以保护你想保护的文件类型。

1、 打开 Internet信息服务(IIS)管理器 →右击本项目虚拟 →属性，如下图

2、 点击按钮“配置”，出现如下对话框：

3、 双击 .aspx的应用程序扩展 →查看对话框内容，如下图：

4、 复制“可执行文件”的全路径名称后 →点击“取消”返回上一层对话框 →点击按钮“添加”

5、 粘贴刚才复制的内容（我的系统装在 D盘，所以内容为 D:/WINDOWS/Microsoft.NET/Framework/v1.1.4322/aspnet_isapi.dll） →填写后缀名为 .htm →填写动作限制为“GET,HEAD,POST,DEBUG”（为方便省事你可选全部）

6、 最后点击“确定” →往项目中添加 HtmlPage1.htm →在 IE浏览器的地址栏直接输入http://localhost/FormTest/HtmlPage1.htm →观看测试效果

3.3 第三部分实现单点登录（Single Sign On）

Web.config 中的 <location>节点的path属性可以是一张具体页面的相对 URL路径，如下：<location path ="ManageSys/Auditing.aspx">

好了，接下来就要揭开“比根目录Web.config的作用范围还大的配置文件”之谜啦，它就是藏匿在 Windows系统目录下，支配整个 .Net Framework 配置的传说中的Machine.config！！下面请大家以热烈的掌声，欢迎我们这位神秘侠客的闪亮登场……

九、 Machine.config

Machine.config ，性别不详，年龄未知，家庭出身：XML。深藏于“云深不知处”的操作系统目录下的某某地方（注：C:\WINDOWS【或 WINNT 】\Microsoft.NET\Framework\v1.1.4322【或 v1.0.3705】\CONFIG），控制着“更上一层楼”的 .NET Framework的本机配置。接下来简要的讲解一下它的内容，以及它与 Web.config的关系。

经过“松下问童子”，我们好不容易找到这位隐者，打开一看，乖乖，足有 3700多行！！“叫我怎么能不难过，偶只想看看是啥结构，可内容实在是太多太繁琐……”还记得偶经常对同事说的一句话么：“办法是人想出来的！”它不是有三千七百多行吗，那我们就不管三七能否得出二十一啦，把它拷出来先。它不是 XML 出身吗，那咱们就还其正身，重新命名为“machine.xml”。接着用 IE浏览器将这位改头换面的隐者打开，把节点与注释一一合拢。这回你看到了吧，是不是很有成就感？

Machine.config 与 Web.config是啥关系？四个字 ——父子关系。记得我在第二部分第五节讲解 Web.config作用范围的时提到两点 ——继承与覆盖（详见http://blog.csdn.net/cityhunter172/archive/2005/11/13/528463.aspx），在此也同样适用。

1、 Machine.config中的设置将作用于运行在本机的所有站点及其虚拟目录，遇到子目录将一直继承下去。

2、 Web.config中的设置将覆盖由 Machine.config中继承下来的对应的节点设置

说到这，再告诉大家一个秘密 —— “世上本无秘密，知道的人多了，便成了不是秘密的秘密！”

a、 Machine.config中的 <system.web>节点所有内容都能出现在项目根目录下的 Web.config中，也就是说能在 Web.config中的内容已经在 Machine.config中一一列出；

b、其中 <system.web>节点下的 <pages>还能出现在页面上，如： HTML视图下，在WebForm1.aspx的第一行加上<pages>的节点内容validateRequest="false"（此句意思是不对WebForm1.aspx页面文本框输入的值，是否包含 “<” “>”等等具有危险性的代码进行检查，下一节将具体运用到）

<%@ Page language="c#" Codebehind="WebForm1.aspx.cs" AutoEventWireup="false" Inherits="FromTest.WebForm1" validateRequest="false" %>

十、单点登录（Single Sign On）的前提条件

之前说了这么多关于 Machine.config的事，都是为了实现单点登录作铺垫，那何为单点登录（Single Sign On）？从字面理解就是在一个地方登录，通常运用于 ASP.NET分布式环境中（跨单个服务器上的多个应用程序或在网络场中）的 Forms 身份验证。打个比方，就好比现在 Sohu（搜狐）与 Chinren（中国校友录）的做法，我在 Sohu登录以后就不需要在 Chinaren登录了。台湾与香港又把 Single Sign On称之为“单一登入”。

要想实现此功能，首要条件是需要一组用于加密与验证加密的密钥。它们位于 Machine.config中，修改 <system.web>节点下的 <machineKey>节点属性，如下：

<machineKey firstKey="172" copyrightKey="Cityhunter172" validationKey="AD117F2F286CDCB15A9D1D4535E16DB0248026939**AUTHOR**CITYHUNTER172****WEBSITE**172*MEIBU*COM****MAILTO**CITYHUNTER172@126*COM*****F2F286CDCB15A9D1D4535E16DB0248026939" secondKey="meibu"  decryptionKey="3C89AE62AD117F2F286CDCB15A9D1D4535E16DB0248026939" validation="SHA1" thirdKey="com" />

1、 validationKey为用于验证加密数据的密钥。最小长度为 40个字符（20字节），最大长度为 128个字符（64字节）。

2、 decryptionKey为用于加密数据的密钥。长度只有 16个字符（8字节）与 48个字符（24字节）两种。

3、 validation为用数据验证使用的加密类型。拥有“SHA1”“MD5”“3DES”三种方法

4、大伙参照上述 <machineKey>试着在WebForm1.aspx运行下列语句：

this.TextBox2.Text ="ht"+"tp"+"://"+firstKey+"."+secondKey +"."+thirdKey

大家在修改之前请先备份一下 Machine.config，到时要是出错可别怪我没提醒你。以上密钥并不是胡乱得来的，接下来向大家介绍生成密钥的方法。

我们把上一节中提到的 WebForm1.aspx拖入本项目的 Public目录下，再往页面上拖入一个 TextMode=MultiLine的TextBox3与一个 Button编写按钮事件与函数：

         private void Button1_Click(object sender, System.EventArgs e)

         {

              string decStr = this.CreateKeyString(int.Parse(this.TextBox1.Text));

              string valStr = this.CreateKeyString(int.Parse(this.TextBox2.Text));

             this.TextBox3.Text=string.Format("<machineKey validationKey=\"{0}\" decryptionKey=\"{1}\" validation=\"SHA1\"/>",valStr,decStr);

     }

         /// <summary>

         /// 生成加密型强随机 Key值

         /// </summary>

         /// <param name="i">Key的有效长度：

         /// decryptionKey 的有效值为 8 或 24；

         /// validationKay 的有效值为 20 至 64

         /// </param>

         private string CreateKeyString(int i)

         {

              System.Security.Cryptography.RNGCryptoServiceProvider rng = new System.Security.Cryptography.RNGCryptoServiceProvider();  //加密随机数生成器

              byte[] bt = new byte[i];

              rng.GetBytes(bt);//用加密型强随机值序列填充字节数组

              System.Text.StringBuilder str = new System.Text.StringBuilder();

              for(int j= 0;j<i;j++)

              {

                   str.Append(string.Format("{0:X2}",bt[j])); //转换成大写的十六进制文本

              }

              return str.ToString();

         }

每次点击按钮生成密钥都不同，大家不妨多点几次。切换至 HTML视图，到WebForm1.aspx第一行把 validateRequest="false"去掉，然后再多点几次 Button1试试，看看会有什么效果，嘿嘿………

十一、单点登录（Single Sign On）的站点示例

将上述 TextBox3 产生的文本，覆盖Machine.config 中的，现在你的机器已经具备了单点登录的条件。大伙可以再新建一个项目 FormTest2，从 FormTest2登录后直接输入 FormTest中的Default.aspx的网址（http://localhost/FormTest/ Default.aspx），反之亦可。

【转载】下面结合实例讲解：偶在山东每步科技网站申请了一个免费二级域名 172.meibu.com，并下载了每步的 4.0版的动态域名解析客户端。现在使用 ADSL拔号上网，也就是说我的电脑已经成了 Web服务器，同时支持 SQL Server、Oracle空间高达 200 G想怎么弄就怎么弄，够牛吧，嘿嘿。布署上来的项目有环胜数码网站、权限管理系统、IT内部管理网，以上三个项目是偶一人全权开发的。所谓全权就是从数据库存储过程写到 .cs代码再到 javascript，最后到美工都是偶一手搞定的。^_^我把这三个不相干的项目做成了单点登录的模式，加上整合站点的主页面，共有四个地方可以进行登录。因为用户 Table的结构不同，因此只有一个入口能在进入后，在跳转站点时不会出错，那就是在整合页面登录。

现在我想把环胜数码这个站点单独脱离出来，而剩下的两个站点继续实现单点登录，该怎么做呢？或者是我的 ASP.NET的空间是租的，服务商肯定不可能让我修改 Machine.config ,我又咋办哩？“办法是人想出来滴！！”，根据上述 Machine.config与 Web.config 的关系，我们可以把 <machineKey>节点放入项目根目录下Web.config的 <system.web>节点。如下：

1、权限管理系统项目的 Web.config用于 Form认证的设置

<machineKey validationKey="AD117F2F286CDCB15A9D1D4535E16DB0248026939**AUTHOR**CITYHUNTER172****WEBSITE**172*MEIBU*COM****MAILTO**CITYHUNTER172@126*COM*****F2F286CDCB15A9D1D4535E16DB0248026939" decryptionKey="3C89AE62AD117F2F286CDCB15A9D1D4535E16DB0248026939" validation="SHA1" />

<authentication mode="Forms">

<forms loginUrl="Login.aspx" name="172.MEIBU.COM_WARRANT"></forms>

</authentication>

<authorization><deny users="?"></deny></authorization>

2、 IT内部管理网项目的 Web.config用于 Form认证的设置

<machineKey validationKey="AD117F2F286CDCB15A9D1D4535E16DB0248026939**AUTHOR**CITYHUNTER172****WEBSITE**172*MEIBU*COM****MAILTO**CITYHUNTER172@126*COM*****F2F286CDCB15A9D1D4535E16DB0248026939" decryptionKey="3C89AE62AD117F2F286CDCB15A9D1D4535E16DB0248026939" validation="SHA1" />

<authentication mode="Forms">

<forms loginUrl="Login.aspx" name="172.MEIBU.COM_IT"></forms>

</authentication>

<authorization><deny users="?"></deny></authorization>

大家可能会迫不急待的去试一把，偶赞成这样的做法，因为事实是检验真理的唯一办法。你不去试着自己动手，光看我在这说是很难提高的。先别急，我已经知道你想说什么，听听我慢慢向你解释：

a) 两个项目Web.cinfig的<machineKey>节点确保以下几个字段完全一样：validationKey、decryptionKey、validation

b) 两个项目的 Cookie名称必须相同，也就是 <forms>中的 name属性，这里我们把它统一为 name ="172.MEIBU.COM_PROJECT"

c) 注意区分大小写

在整合的过程中，我把遇到的问题向大伙说一下，以免你们走同样的路。

1) 首先应该是用户管理的问题，把两个项目的用户整合在一起，可不是一件容易的事，原则是新建一个新的 Table只存放帐号与密码，用账号做关联，编写触发器，做到 Table之间的同步；

2) 不要指望两个项目间用 Session进行传值，两个应用程序的 Session是无法共享的。网上有人曾把类库（编译后的 .dll文档）放入同一个 bin文件夹实现过 Session共享，这样的做法实际上是把两个项目变相合并成一个应用程序，不是我们所想要的，理由很简单：Sohu与 Chinaren的服务器分处两地该怎么办？

3) 项目间的传值，可用 Cookie实现。在第一部分的第三节（http://blog.csdn.net/cityhunter172/archive/2005/11/06/524043.aspx）我们介绍了只要运行 System.Web.Security.FormsAuthentication.SetAuthCookie方法即可实现登录，单点登录的实质就是含有身份验证票的 Cookie能在项目间共用。

接下来，有必要向大家介绍一下 Cookie在 .Net中的用法。

十二、 Cookie 在 ASP.NET中的用法

大家也许和我一样，很少在 ASP.NET中使用 Cookie，传参数呀，存变量呀，用的比较多的是 Session或 ViewState以及隐藏控件，有的干脆用“ ? ”的请求方式。

1、 Cookie存放的目录

Cookie 是存放在客户端的东东，放在“Temporary Internet Files”目录，所以说存在安全性的问题。大伙可通过以下方式找到具体位置：打开控制面板 → Internet选项 → 常规 → Internet临时文件 →设置 →即可看到“当前位置”，→点击“查看文件”将直接打开该文件夹，你也可以点击“移动文件夹”变更它所在的位置。参照下图

2、 Cookie的有效期

从上图我们可以清楚的看到每个 Cookie文档的“截止期”（即为有效期）。在有效期内，当登录计算机的用户 Administrator再次访问 172.meibu.com 时，那么 IE就会在请求页面的同时，连同上述的名称为“Cookie:[e-mail]”的Cookie文档内容一起发送给服务器。

若该文档包含多个 Cookie的值时，截止期则以最后的失效期为准。

3、 Cookie的类型

这里我们按有效期来分，分为两种：

a)即时型

指的是关闭浏览器（所有浏览 172.meibu.com的 IE）后，Cookie便失效，此类 Cookie不会在“Temporary Internet Files”目录出现。其实它也有截止期的，为“0001-01-01”

b)持久型

就是已指定具体“截止期”的，能够在“Temporary Internet Files”目录里面找到的 Cookie

4、 Cookie的内容

双击打开“Cookie:[e-mail]”，我们看到以下内容，如下图：

上图中，“■”是换行符，你若是要打破什么锅来问我到底是怎么知道的话。我倒是会很乐意的告诉你：这就是经验！偶从学习 C#那刻起，就拿第一个 Windows程序 €€€€记事本来开刀，保存文档时得来的经验。

所以服务器读出来的格式如下图：

5、在 ASP.NET页面发放 Cookie

发送上述 Cookie 的 .cs 代码为：

System.Web.HttpCookie ck = new HttpCookie("ckValue0");

ck["Author"] ="CityHunter";

ck.Expires = System.DateTime.Now.AddMinutes(10);//若不指定，则为即时型 Cookie

//ck.Path="/FormTest/ManageSys"; //设置 Cookie的虚拟路径，注意一定要以“/”开头，否则为无效 Cookie；请大家自行看一下它与在客房端的 Cookie 文档“名称”与“Internet地址”的关系

Response.Cookies.Add(ck); 

ck = new HttpCookie("ckValue1"); //重新新建一个名为 ckValue1的 Cookie

ck.Expires = System.DateTime.Now.AddMinutes(20);   //即刻起 20分钟后失效

ck["E_Mail"] ="[e-mail]";         //设置 ckValue1中的 E_Mail值

ck["PersonalWeb"] ="172.meibu.com";

Response.Cookies.Add(ck);   //添加此 Cookie

6、取回已发放 Cookie的值

Response.Write(Request.Cookies["ckValue0"]["Author"]+"<br>");//用不着说明了吧

Response.Write(Request.Cookies["ckValue1"]["E_Mail"]+"<br>");

Response.Write(Request.Cookies["ckValue1"]["PersonalWeb"]);

好久没有出作业啦（何出此言？），这第三篇呀，可是花了偶两个星期的业余时间调试、总结、撰写哪，都说时光贵如金，不知我花的这些时间能换来多少银子？换银子，我看是没指望啦，能得到阁下的一句评论，偶也满足了。记住，你的评论就是偶继续写下去的动力。

作业：给 Cookie 赋于以下值，怎样得到它的正确值

ck["str1"] ="2222";

ck["str"] ="str0=11111&str1=223";

可以肯定的是Request.Cookies["ckValue1"]["str"]得不到 “str0=11111&str1=223”这个字串，大家不妨试一下 Request.Cookies["ckValue1"]["str1"]会得到意想不到的字串哟。

提示：使用 Server.UrlEncode()与Server.UrlDecode()

十三、发放永久性的验证 Cookie

大家登录 CSDN的时候是否留意到一个“2周内不用再登录”的复选框，它又是怎么做到的呢？大家是否曾遇到过这样的困惑：在执行System.Web.Security.FormsAuthentication.SetAuthCookie时明明已指定createPersistentCookie为 true为何关闭浏览器仍不能直接访问网站？下面我们就这个问题给大家解释一下，且介绍如何手工创建身份验证票并加入 Cookie中。

     System.Web.Security.FormsAuthenticationTicket tk = new System.Web.Security.FormsAuthenticationTicket(

         1,                 //指定版本号：可随意指定

"Admin", //登录名：对应 Web.config中 <allow users="Admin"… />的 users属性

         System.DateTime.Now,   //发布时间

         System.DateTime.Now.AddYears(100),   //失效时间：100年以后，够永够久了吧

false,   //是否为持久 Cookie：尚未发现有何用，至少目前偶还不知，下面会有说明

"测试用户数据"//用户数据：可用 ((System.Web.Security.FormsIdentity)User.Identity).Ticket.UserData获取

         );

string str = System.Web.Security.FormsAuthentication.Encrypt(tk);//加密身份验票

             

     //声明一个 Cookie，名称为 Web.config中 <forms name=".APSX"… />的 name属性，对应的值为身份验票加密后的字串

     System.Web.HttpCookie ck = new HttpCookie(System.Web.Security.FormsAuthentication.FormsCookieName,str);        

                   //指定 Cookie为 Web.config中 <forms path="/"… /> path属性，不指定则默认为“/”

     ck.Path=System.Web.Security.FormsAuthentication.FormsCookiePath;  

//此句非常重要，少了的话，就算此 Cookie在身份验票中指定为持久性 Cookie，也只是即时型的 Cookie关闭浏览器后就失效；因此上面我说：我是真的还不知在身份验票中指定为持久性 Cookie有何用。

     ck.Expires = System.DateTime.Now.AddYears(100);

Response.Cookies.Add(ck); //添加至客房端 

第四部分 Form 认证的补充

前三篇在 CSDN 论坛公布后，效果如同“神仙放屁——果然不同凡（反）响”。为感谢广大网友的热情与支持，这不，经过这一阵子的酝酿、修炼，特意准备了这第四响。

之前我们讲述的使用 Form 认证实现单点登录，正如网友所说的那样，只能在同一域名下使用。对于跨域名的单点登录，除了使用 Passport认证外，我们还是可以用 Form认证的，只是要讲究方法而已啦。正所谓“山不转水转，人不转心转”。

一、跨域名的解决思路

在MSDN 2003 上搜索关键字“Passport”，偶找到一篇“Passport身份验证提供程序”。文章讲述了 Passport的认证原理，共 8 条，我就不多说了，大伙自个看吧。其中有一句话，引起偶的注意：“……响应在查询字符串中包含一个加密的 Passport Cookie……”。也正是此句才有了下面的思路。

所谓认证的通过与否，其实质就是检测有无发放有效的 Cookie，使用 Form也好，运用 Passport也罢，都是 Cookie在起作用。也就是说，我们只要把有效的 Cookie在登录后一次性发放给客户端就得了。

二、跨域名、跨服务器的单点登录方法

1、如何在本机模拟跨域名、跨服务器的Single Sign On

只要浏览网址不同就相当于不同域名，在本机至少有以下三种。它们虽然是同一项目，彼此却不能共用 Session与 Cookie，也就无法共享身份验证票：

a). http://localhost/FormTest/Login.aspx

b). http://127.0.0.1/FormTest/Login.aspx

c). http://My_Computer_Name/FormTest/Login.aspx //以电脑名称浏览站点

d). http://192.168.0.8/FormTest/Login.aspx //以网卡地址浏览站点

e). http://172.meibu.com/FormTest/Login.aspx //拥有国际域名

2、在 ASP.NET中如何提交给其它页面

用过ViewState 的大概都知道，ViewState是保存在客户端的。不知大伙注意没有，ASP.NET为每张 .aspx页面都配备了独自的 ViewState，且被解析后都是以一个 name=" __VIEWSTATE"的隐藏控件值来保存ViewState。每次页面提交，服务器都会检查该控件的值有无被篡改，如此一来就注定 .aspx只能提交给本页。服务器是死的，人是活的，我们不能被这些条条框框限定死了，我们要把程序写成活的。

下面咱们从 http://localhost/FormTest/Login.aspx输入用户名与密码，然后提交给http://127.0.0.1/FormTest/Public/LoginTransfer.aspx。Login.aspx与LoginTransfer.aspx都包含用户名输入框一个、密码输入框一个、登录按钮一个。在 Login.aspx页面加入以下代码：

this.Btn_Login.Attributes["onclick"]="SingleSignOn()"; //指定执行脚本事件

在 Login.aspx 页面上插入以下脚本：

<script language="javascript">

         function SingleSignOn()

          {

//只能用脚本改变指定 Form提交的对象

document.getElementById("Form1").action="http://127.0.0.1/FormTest/Public/LoginTransfer.aspx?FromUrl="+window.location.href;

    

               //把隐藏控件 __VIEWSTATE中的值变更为 LoginTransfer.aspx解析后出现的值，以实际看到的值为准

document.all.__VIEWSTATE.value = "dDwtMTkyODUzMTMyNzs7Pv1cp2RaxUcr5hGYf8ILX9/EMKy8";

       }

</script>

注意事项

a). LoginTransfer.aspx 出现的控件及其 ID ，必须能够在 Login.aspx找到

b). 控件的 ID必须一致，且能一一对应

c). 关于 __VIEWSTATE中的值，它与页面控件ID无关，与浏览该页面的网址无关，目前我只知道和控件的数量、类型、名字空间（namespace FormTest.Public）以及存在的 ViewState有关系。大家在测试时，以直接浏览http://127.0.0.1/FormTest/Public/LoginTransfer.aspx后，查看页面源文件所看到的值为准。

d). 提交后，将触发并执行LoginTransfer.aspx中的Btn_Login_Click事件

3、基本思路

各个站点的登录页面统一将用户名与密码提交给 LoginTransfer.aspx，同时各个站点需要一个增加 Cookie的页面，用于将加密后的身份验证 Cookie添加至客户端。此乃经过一番考量后，最终确定的可行性方案。

4、第一种思路——天女散花

何谓天女散花，就是把 Cookie在登录后一次性全发放出去，就如同天仙在空中散花一样，场面是何等的壮观。下面开始写代码：

为更好的区分，我们将负责添加 Cookie的页面分开命名：

a). http://localhost/FormTest/Public/AddCookie_A.aspx

b). http://127.0.0.1/FormTest/Public/AddCookie_B.aspx

c). http://My_Computer_Name/FormTest/Public/AddCookie_C.aspx

这三张页面的功能一样，所以代码也就相同啰

private void Page_Load(object sender, System.EventArgs e)

   {

      string from = Request["FromUrl"];         //起始 URL路径

      string next = Request["NextUrl"];         //还需要跳转的 URL

      string key = Request["CookieTicket"];      //已加密的 Cookie文本

      if(key != null && key !="")

       {

           System.Web.HttpCookie ck = new HttpCookie(System.Web.Security.FormsAuthentication.FormsCookieName,key);

           ck.Path=System.Web.Security.FormsAuthentication.FormsCookiePath;

           ck.Expires = System.DateTime.Now.AddYears(100);

           Response.Cookies.Add(ck); //将传过来的已加密的身份验证票添加至客房端

                  

           string url = next.Split(';')[0]; //从 URL中拆分出将要跳转的下一张页面

           next = next.Replace(url+";",""); //带入下一轮跳转的字串

           if(url!="")

           {

                 //跳至下一页面     Response.Redirect(url+"?CookieTicket="+key+"&FromUrl="+from+"&NextUrl="+next);

            }

            else  //已没有下一页面可供跳转

            {

                 Response.Redirect(from);    //回到起始页面

            }

       }

    }

 

接下来编写 LoginTransfer.aspx的代码：

//页面常量 allLoginUrl存放所有站点的 AddCookie.aspx的 URL，注意以 ;分隔

public const string allLoginUrl =   

"http://localhost/FormTest/Public/AddCookie_A.aspx;"

+"http://127.0.0.1/FormTest/Public/AddCookie_B.aspx;"

+"http://My_Computer_Name/FormTest/Public/AddCookie_C.aspx;";

偶已在上面讲述了，如何点击 Login.aspx中的登录按钮Btn_Login将用户名与密码提交给 LoginTransfer.aspx，并执行LoginTransfer.aspx中的Btn_Login_Click事件。

private void Btn_Login_Click(object sender, System.EventArgs e)

  {

     string from = Request["FromUrl"];    //起始 URL路径

     string next = this.allLoginUrl; 

             

     //由于控件 ID相同，所以此处得到的是由 Login.aspx提交过来的用户名与密码

     if(this.Txt_LoginName.Text=="Admin"&&this.Txt_Password.Text=="123456")

     {

        System.Web.Security.FormsAuthenticationTicket tk = new System.Web.Security.FormsAuthenticationTicket(1,"Admin", System.DateTime.Now, System.DateTime.Now.AddYears(100),false,"测试用户数据"  );

        string key = System.Web.Security.FormsAuthentication.Encrypt(tk); //得到加密后的身份验证票字串

 

        string url = next.Split(';')[0]; //从 URL中拆分出将要跳转的下一张页面

        next = next.Replace(url+";",""); //带入下一轮跳转的字串

        Response.Redirect(url+"?CookieTicket="+key+"&FromUrl="+from+"&NextUrl="+next); //跳至下一页面

     }       

  }

5、第二种思路——后羿射日

后羿射日，意思指的是用户点哪就跳哪。他若是点“火坑”，你也得往里跳，因为用户是上帝嘛。我们增加一个通行证页面 MyPassport.aspx，由 http://127.0.0.1/FormTest/Public/LoginTransfer.aspx发放验证 Cookie后直接跳转至 http://127.0.0.1/FormTest/MyPassport.aspx。不要告诉我你不会，你要是真不会，那偶也没法子啦，还得请你回头看看，偶在第三篇是如何讲述发放永久性验证 Cookie吧（http://blog.csdn.net/cityhunter172/archive/2005/12/06/545301.aspx）。还需要一张用作跳板的跳转页面 MyTransfer.aspx。

MyPassport.aspx 的代码：

<a target ="_blank"

href="MyTransfer.aspx?goto=http://localhost/FormTest/Public/AddCookie_D.aspx">

美丽的天使</a>

<a target ="_blank"  

href="MyTransfer.aspx?goto=http://127.0.0.1/FormTest/Public/AddCookie_E.aspx">

快乐的天堂</a>

<a target ="_blank"

href="MyTransfer.aspx?goto=http://My_Computer_Name/FormTest/Public/AddCookie_F.aspx">

大大的火坑</a>

MyTransfer.aspx 的代码：

 private void Page_Load(object sender, System.EventArgs e)

   {

      //获取身份验证票

       System.Web.Security.FormsAuthenticationTicket tk =((System.Web.Security.FormsIdentity)User.Identity).Ticket;

      string key = System.Web.Security.FormsAuthentication.Encrypt(tk); //每次加密后的字串都是不同的

      string next = Request["goto"]; //将要跳转的 URL

      Response.Redirect(url+"?CookieTicket="+key); //跳转至下一页面

   }

AddCookie_D.aspx、AddCookie_E.aspx、AddCookie_F.aspx这三张页面的代码：

string key = Request["CookieTicket"]; //已加密的 Cookie文本

if(key != null && key !="")

{

    System.Web.HttpCookie ck = new HttpCookie(System.Web.Security.FormsAuthentication.FormsCookieName,key);

    ck.Path=System.Web.Security.FormsAuthentication.FormsCookiePath;

    ck.Expires = System.DateTime.Now.AddYears(100);

    Response.Cookies.Add(ck); //将传过来的已加密的身份验证票添加至客房端

    Response.Redirect("../Index.aspx"); //跳转至你真正想带客户去的地方

}

6、点评

两者共同点：

a). 每个站点都需要一个登录的提交点、一张添加 Cookie的页面。

b). 因为只能靠发放验证 Cookie来识别身份，所以一台电脑不能同时登录两个帐号。

c). 都存在不同程度的安全隐患。

两者不同点：(天女散花以下简称“开女”，后羿射日就简称“后羿”)

a). 天女一次性发放 Cookie，如果站点较多，处理起来还是需要一些时间的。而后羿则相反，站点再多也不怕。

b). 天女在散花的过程中，如果中途被卡住，则需要一个错误处理机制做回退处理。后羿则不需要。

c). 天女在登录后可以直接在 IE地址浏览其想看的站点；而后羿则必须从通行证的跳板页面进入才行。

根据上述问题，给几点建议：

a). 不要使用永久性 Cookie，应指明身份验证票的过期时间，注意不是 Cookie的有效期。

b). 在身份验证票的 UserData中加入其它的验证信息或存放用户 ID

c). 在网络通畅的情况下，比如局域网，站点又相对较少，建议选用天女。50个站点之间做跳转应该不会超过 10秒（前提是已编译好了，且不是初次访问）。

三、跨域名、跨服务器的退出方法

只要理解了“天女散花”，退出就比较容易啦。为每个站点准备一个用于退出的页面，如下：

a). http://localhost/FormTest/Public/Logout.aspx

b). http://127.0.0.1/FormTest/Public/Logout.aspx

c). http://My_Computer_Name/Public/FormTest/Logout.aspx

private void Page_Load(object sender, System.EventArgs e)

{

    System.Web.Security.FormsAuthentication.SignOut();//删除 Cookie中的身份验证票

    string from = Request["FromUrl"];

    string next = Request["NextUrl"];

    string url = next.Split(';')[0];

    next = next.Replace(url+";","");

    if(url!="")

    {

       Response.Redirect(url+"?FromUrl="+from+"&NextUrl="+next);

    }

    else

    {

       Response.Redirect(from);

    }

}

对啦，还有一张 LogoutTransfer.aspx.，代码偶就不写，大家自个完成吧。