SSO打算用在哪里的？Internet or Intranet?
Ying-Shen:
先考虑Intranet
Bruce ：
Session是一个系统已经提供的非常好的工具，可以利用。
微软的网站上有介绍的使用cookie的例子，可以去看看。
我的想法
SSO系统是各个系统共享同一份用户数据，并不公用一个用户管理系统，在一个机构内部，可以存在很多不同的系统，这些内部的用户权限实现要求是不一样的
我现在要弄个跨服器的统一认证，一个是主站，一个是论坛，用户注册，登陆，注销操作全在主站进行，论坛要同步，因为它们不在一台服务器，以前没接触过，比较头疼，你有好的建议么~
kwklover :
安全信息和控制可以不一样。
为了简单考虑，可以认为是一样的逻辑。我现在做的系统就是用的统一的安全控制服务。微软的passport估计就不是一样的了。
我们也还没有考虑多种验证方式：自己制作的，还是系统集成的等等。
maxwolf ：
我这里讨论的主要目的就就是解决这个问题。
现在有了解决办法，正在测试和继续论证。不过，我这里没有主站和从站的的划分，只是我的UI不再一台服务器上，或者一台机器的不同站点下。
接着抛砖，基本的思路是这样的:利用系统的Session管理，自己在这个基础上制作一个统一的SystemUserSessionIndentify管理。
这里准备开发一个SSOServer：
http://community.hf-mstc.org/cs/blogs/dcding/archive/2005/07/27/161.aspx
另外如果不作通用的SSO，可以参考SPS（Sharepoint Server）和Biztalk中的SSO实现。另外在MSDN上还有一篇文章说明如何在ASP.NET中怎么实现SSO：
Single Sign-On Enterprise Security for Web Applications
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspp/html/singlesignon.asp
目前Java下做得比较好的一个真正的SSO是JOSSO项目：
www.josso.org
其他的SSO都是由集中认证来消除SSO的努力，对于已经开发完成的应用并没有太多帮助。
谢谢大家的关注，那我就继续抛砖。
考虑这种情况
用户在A系统中登陆，A系统位于新加坡的一台服务器上，这时因为业务需求，A系统弹出一个对话框对你说“小伙子，想要更多的信息，去B公司的xxx系统里面去仔细看！”，恰巧，B公司和A公司都是基于我们的平台制作的（做个广告先），这时候，你点击了一下“确定”，网页接着给你新打开了一个url:
http://xxx.com/default.aspx?suid=xxx&pn=xx&app=xxx (该服务位于济南市)，然后，你等了大约1.5秒钟，网页打开了，你看到了你想要的信息。当然，这个信息不是对外公开的，是要注册帐户才能察看的，而你因为已经在新加坡的服务器上登陆过了，而我们的平台又是支持单点登陆的，所以你没有在此登陆就直接看到了你想要的信息。
好了，这个故事的前提是，这两家公司是一家大公司的两个子公司，享有共同的登陆服务，安全服务。
这种效果怎么样？
@随心所欲
这个应用场景很普通了。就好像在网易上通行证登录后就可以访问同样的mail、论坛....
正如我前面所说，这种场景不过是基于统一个认证系统，是最最容易实现、最简单的SSO，而我们经常遇到的情况是很多应用基于不同的认证系统，而且很难更改。
真正的SSO实现那是要求可以跨越企业实现和多个合作伙伴的认证的。你看看SourceID.NET的UseCases(
http://www.pingidentity.com/resources/listResources.action?category=17)就明白了。SAML、WS-Federation等等标准协议作的不就是这件事情么。
Sorry,弄错了。发现你文章的前提都和我理解的不一样：“1：单点登陆也就是用一个统一的用户管理系统（包括部分权限控制模块）。”。
我所遇到过的SSO解决方案都不是这个前提下的。
@jumper:
楼主所说的SSO其实没有任何意义，也不存在任何技术含量。关于SSO，目前Java上提供的方案都是基于客户端技术(包括Cookie)或者操作系统进程标识或者平台标识。我见过的SUN或者IBM提供的解决方案，基本上都需要一些额外的前提。MS的Passport当然是比较成功的，传说中MS使用了一些“暗门”技术，所以只依赖服务端技术。听起来有些神秘，也正是如此所以非常令我好奇。以前我一直认为是MSN的客户端程序(包括MSN所依赖的Windows支持库)实现了Passport，后来听网友讲，Passport在MAC机器的浏览器上一样有效，这真的是很了不起。
@jumper，双鱼座
sorry，这个讨论的前提是我根据我开发遇到的问题制定的，太高了，所以“其实没有任何意义，也不存在任何技术含量”。
因为我想解决的问题只是针对我所开发的一个平台之上的应用的单点登陆，没考虑跨平台、多种验证方式、集成原有系统等功能。
@maxwolf
IBM的那篇文章的确不错。
但是有没有其他方式代替“代理转发”这个模式呢？感觉这种模式是不是会比较浪费性能？
还有就是使用cookie，会不会有安全性上的隐患，或者还要担心用户是不是禁用了cookie？
我实现了个类似于微软passport的认证授权系统，使用cookie。实现跨域SSO。不过目前仅限aspx。需要单独认证服务器。应用程序遵循相同开发原则。
@ jumper 没有这个前提:“单点登陆也就是用一个统一的用户管理系统”，用户从一个系统转到另一个系统有什么意义？ 肯定要有一个统一的身份管理的
关于跨域的Cookie访问的文章太多了，如果一定要用Cookie、并且仅限于aspx、并且需要一个共同的用户管理平台...这限制也太多了点，所以我说没有什么意义，而且的确非常简单。
用户从A系统的一种身份转换了B系统的另外一种身份的过程也是“单点登录”技术的一部分，自动提供纯服务端的身份交换，不依赖任何客户端技术，这才是微软的passport，所以你这个“类似”事实上并不存在。
@ 双鱼座
是的，我考虑的模型的确是存在一个问题，只能对使用我的Login服务和Security服务的系统集成，没有考虑集成已经做好的其他的系统。
“代理转发”这个模式也不错，不过可能还是不可避免的要修改原来的系统。因为别人的系统你是不知道具体是怎么运作的，使用的是什么验证方式，什么安全管理机制等等。
你可以把你知道的passport的机制和大家交流一下，看看是不是对我们都有启发。
呵呵，发现问题不是我们的目的，我们的目的是---解决问题。
我也在研究这个问题. 我看目前的难点是如何在不同域的服务端取到客户端的一个令牌. 据我所知cookie只能被同一个域名的服务端所读取, 不同域名怎么办?
1 . cookie 可以设置域
2 . 相对sso服务器，域名是不是就是固定了?
令牌的cookie可以设置域
to：凌晨的太阳
“域名是不是就是固定了?”什么意思？
我想做一个java平台的单点高登陆，谁知道用什么服务器好啊？需要不同语言开发的系统都要可以认证授权
好多sso的解决方案是要求应用系统修改自己的认证部分，使用统一的认证服务器。
实际上这种解决方案没有技术难度，有的只是管理难度，就是是否能够让这些应用系统的作者去改自己的东西。至于统一的认证服务器，商业的，免费的，已经存在很多年了。这种方案对于已经运行多年的老系统，是没有作用的
我看到有人提到这样的解决方案
also called legacy single sign-on, after primary user authentication, intercepts login prompts presented by secondary applications, and automatically fills in fields such as a login ID or password. E-SSO systems allow for interoperability with applications that are unable to externalize user authentication, essentially through "screen scraping."
简单的说就是在老应用的界面里面自动填上密码，从原理上说，应该是可以实现的。
不知道有没有这样的现成的系统？
“实际上这种解决方案没有技术难度，有的只是管理难度，就是是否能够让这些应用系统的作者去改自己的东西。”
同感
我们单位目前有很多内部使用的系统,C/S,B/S的都有.后来我们领导牵头,自行开发了一套软件分发系统,类似现在QQ游戏大厅这样的(据说是玩网游的时候突然的想法),现在已经实现了部分软件的单点登录,用的是WEBSERVICE,实现单点登录的系统目前都还是独立的用户权限管理系统,个人觉得这个功能虽然可能不是真正意义上的单点登录,不过效果还是很明显的.
现在,我们准备对一些比较成功的系统向下属单位进行推广,从而实现在单位内部形成办公软件的大集中管理模式.这里就涉及到统一用户管理的标准了.
目前的想法是在软件分发大厅(下面统称为大厅)建立标准的用户库,各个系统从标准库中选择用户后给用户授权使用本系统.第一,提出了关于一个用户的生命周期的概念(当用户更换部门或者单位时,他的用户信息必然发生变化,但是考虑到他原用户可能还存在需要处理的业务,因此不能马上将该用户删除,这时的处理办法?);第二,提出了一个用户多个密码的想法(考虑到用户可能需要将密码告知别人替他进行业务操作,但是并不希望别人可以进入某些特别的系统时?),或者多级密码?
总之目前还是没有整理清楚,也不怕大家见笑了,拿出来跟大家讨论讨论,希望从中得到好的启发^_^