大型的互联网网站总有不少独立的网络应用，而每个应用都有些需要用户登陆后才能看到的内容。很明显，你不想在每个应用里搞一套自己的登陆方案，设置自己的登陆页面。再说，如果用户每换一个应用就需要登陆一次，很麻烦，我们需要一个统一的登陆方案，用户登陆一次即可访问其他应用的方案。

在论坛上看到过一些建议，一般都是利用ASP.NET里基于Form的认证方法，其中一个方案是把所有的应用变成子目录，而非单独的虚拟目录，然后集中起来放在一个虚拟目录下，然后在虚拟目录下设置单一的认证。但这方案大概只适用于网络应用都集中在单一服务器上的情形，而且强制去虚拟化也减少了其中应用们的相对独立性。

当然，微软已经提供了一个很好的方案，Passport认证服务。ASP.NET也支持这服务，查看一下System.Web.Security命名空间下以Passport开头的类名就知道了。如果你想在你的应用里使用Passport认证服务的话，你需要下载.NET Passport SDK，可以参考

.NET Passport Single Sign-In

或DEVX网站上的这篇文章

Set Up Passport Authentication in ASP.NET

看是如何设置的。

但在很多情形下，这方案也许不是很恰当，但我们可以模仿Passport认证服务的工作机理来定做一个方案。在MSDN上好象找不到详细的Passport协议内容，找到的这一页则不够详细。你可以参考下列文章来了解一下Passport认证过程：

Enable Single Sign-on in ASP.NET with Passport

但大概的过程是这样的：

一。用户访问你网站上的某一网页
二。两种情形
A。如果你的网页发现用户尚未被认证，则显示认证登陆(Sign In)按钮
1。用户按登陆按钮
2。你的网页重新定向用户请求到认证服务器，并提供你的网站的ID
3。两种情形
a。如果认证服务器通过cookie发现用户尚未被认证，认证服务器显示用户名字/密码登陆表单，用户输入名字/密码，认证服务器认证后，在用户浏览器端生成一个认证cookie，并重新定向用户请求回到原来你的网页，并在URL里提供用预先生成的你网站的公钥加密过的ticket和用户profile信息，这些信息的细节参考上述文章
b。如果认证服务器通过cookie发现用户已经被认证过(也许是在别的应用/网站里)，认证服务器更新那个认证cookie，并重新定向回到原来你的网页，并在URL里提供用预先生成的你网站的公钥加密的ticket和用户profile信息

你的网页检查URL，用预先生成的你网站的私钥，获取用户信息，生成一认证cookie，然后显示退出认证(Sign Out)按钮

B。如果你的网页发现用户已经被认证，显示退出认证(Sign Out)按钮

三。如果用户点击退出认证按钮，则将触发一个到认证服务器的退出认证网页的请求，认证服务器的退出网页根据回来的认证cookie，为每个目前用户已经登陆的应用/网站生成一个〈IMG〉，其属性SRC则指向各个应用/网站的退出认证页面，并使认证服务器的认证cookie过期。而各个应用/网站的退出认证网页，则把自己的认证cookie过期。

结果是，用户点击退出认证按钮的话，他将从目前登陆的所有应用/网站退出。

当然，你定制的方案也许不用这么复杂或健壮，你可以考虑不使用PKI。