评论：Identity 2.0 何时真正到来？（一）小有所成的 OpenID http://blog.linjian.org/articles/identity-20-1-openid/ 有容乃大，无欲则刚 Fri, 10 Sep 2010 13:55:22 +0000 hourly 1 http://wordpress.org/?v=abc 由：詹小兵 http://blog.linjian.org/articles/identity-20-1-openid/comment-page-1/#comment-479 詹小兵 Wed, 19 Aug 2009 13:31:09 +0000 http://blog.linjian.org/?p=377#comment-479 你的想法代表了大部分电脑用户最头疼的事情，就是不听的去使用不同的注册信息去不停的登陆不同的认证界面，繁琐无趣而且时间速度都消耗不少，，。。我有个好建议，为什么不把电脑登陆边的更贴近用户自己性格习惯做法的更独立的识别认证系统，智能加锁保护用户权益，也最好是独立组件去管理控制哦，同时也可以消除卸载，。。 你的想法代表了大部分电脑用户最头疼的事情，就是不听的去使用不同的注册信息去不停的登陆不同的认证界面，繁琐无趣而且时间速度都消耗不少，，。。我有个好建议，为什么不把电脑登陆边的更贴近用户自己性格习惯做法的更独立的识别认证系统，智能加锁保护用户权益，也最好是独立组件去管理控制哦，同时也可以消除卸载，。。

]]> 由：Jian Lin http://blog.linjian.org/articles/identity-20-1-openid/comment-page-1/#comment-470 Jian Lin Sat, 15 Aug 2009 15:29:54 +0000 http://blog.linjian.org/?p=377#comment-470 @paul 我基本看明白了你的意思。我觉得做身份认证机制，首先需要回答的一个问题是：这是面向终端用户的认证机制，还是面向软件、系统内部使用的认证机制。从你的描述看，你想做的应该是面向终端用户的认证机制。对于这类机制，我觉得“最小吃惊原则”是很重要的：要让用户容易理解，一看就会；基于现有的 Web 机制，不在客户端部署额外的组件等等。OpenID 和 Information Card 的解决方案你应该清楚，我感兴趣的是你如何解决这些问题（或者你不认同我这些原则，可以说说你的原则）。 在面向软件、系统内部使用的认证机制中，Globus 的访问控制机制不知你有没有看过，它是一套基于代理证书的，可以实现单点登录、跨管理域用户认证和资源授权的安全框架。这套思路也许可以借鉴。但它的复杂度也可想而知（涵盖认证、管理、授权、证书、安全性），我觉得首先还是要确定自己的目标（比如只做认证一块并保证安全），然后“K.I.S.S.”为好。 @paul 我基本看明白了你的意思。我觉得做身份认证机制，首先需要回答的一个问题是：这是面向终端用户的认证机制，还是面向软件、系统内部使用的认证机制。从你的描述看，你想做的应该是面向终端用户的认证机制。对于这类机制，我觉得“最小吃惊原则”是很重要的：要让用户容易理解，一看就会；基于现有的 Web 机制，不在客户端部署额外的组件等等。OpenID 和 Information Card 的解决方案你应该清楚，我感兴趣的是你如何解决这些问题（或者你不认同我这些原则，可以说说你的原则）。
在面向软件、系统内部使用的认证机制中，Globus 的访问控制机制不知你有没有看过，它是一套基于代理证书的，可以实现单点登录、跨管理域用户认证和资源授权的安全框架。这套思路也许可以借鉴。但它的复杂度也可想而知（涵盖认证、管理、授权、证书、安全性），我觉得首先还是要确定自己的目标（比如只做认证一块并保证安全），然后“K.I.S.S.”为好。

]]> 由：Identity 2.0 何时真正到来？（二）处境尴尬的 Information Card | 林健的BLOG http://blog.linjian.org/articles/identity-20-1-openid/comment-page-1/#comment-466 Identity 2.0 何时真正到来？（二）处境尴尬的 Information Card | 林健的BLOG Fri, 14 Aug 2009 16:05:53 +0000 http://blog.linjian.org/?p=377#comment-466 [...] Identity 2.0 何时真正到来？（二）处境尴尬的 Information Card 2009/08/15 | 00:05 | 分类：IT杂谈 | 标签：Information Card微软服务用户网络 | 1次阅读 　　在 Identity 2.0 技术族中，Information Card（信息卡）算是 2006 年左右炒作得比较多，然而目前发展却不尽如人意的一支。当时微软把 Windows CardSpace——即它的 Information Card 套件同 WCF、WPF、WF 并列，作为 .NET Framework 3.0 的四大新兴组件来宣传。然而仅从现在的技术图书市场就可以看到：W*F 相关书籍在 .Net 书架上大行其道，而有关 Windows CardSpace 的书籍则是凤毛麟角。细心的 Windows 用户常常会疑惑：新版系统的控制面板中为什么会有一个似乎是制作名片用的 Windows CardSpace 工具？一般用户很少知道微软当年“Codename InfoCard”的雄心。 　　事实上，Information Card 不是微软一家独推的身份认证技术，它还得到了 Intel、Google、Novell、Oracle、Paypal 等公司的支持，并由这些公司共同组建了非盈利的 Information Card Foundation (ICF) 来推进这一技术。和 OpenID 一样，Information Card 也开放标准，没有中心节点，允许任何人按照标准独立实现和构建 Identity Provider 以及基于 Information Card 认证的网络应用，甚至允许用户使用相应的软件在本地自行创建个人 Information Card。Information Card 的工作模型源于生活中的实体证件认证机制：Identity Provider 是按照一定的规则给用户颁发 Information Card，并可以管理和验证自己颁发的 Information Card 的机构，相当于颁发驾照的交管部门或发行信用卡的银行；Identity Selector 是帮助用户保存和管理自己的 Information Card 的本地软件或网络应用，相当于钱包或保险柜；很多 Identity Selector 也兼具创建个人 Information Card 的功能，相当于名片印刷设备。对其工作机制的一个简单比喻是：用户自行制作数字名片，或在发证机关办理数字卡片或证件；平时把自己的数字名片、卡片或证件放在虚拟的钱包或保险柜中；在需要向目标网站证明自己身份的时候，打开钱包或输入保险柜密码，出示相关名片、卡片或证件（事实上只是它们部分“页面”的“复印件”）；目标网站获取其中的非敏感信息，有时还需要向发证机关求证一下卡片或证件的真伪；通过验证之后目标网站即可为用户提供相应的服务。 　　上文所谓的“名片”即个人（Personal）Information Card，这是 Information Card 最常见的一种形式。个人 Information Card 包含用户的非敏感信息，及其创建时间、创建软件和唯一的 ID 等。在发送给目标站点进行身份认证时，只有用户的非敏感信息被传送，因此不存在前文所述的缺点1、2。由于目标网站没有拿到 Information Card 上的 ID 等重要信息，所以它们无法伪造一个与原 Information Card 完全相同的复本来登录原用户注册过的其它网站。在登录时，一个根据协议生成的、不可修改的 Site-Specific Card ID 会发送给目标站点，它唯一表示了特定 Information Card 与特定目标站点的认证关联。Site-Specific Card ID 配合安全协议，具有双向认证特性，可以防止恶意用户伪造他人 Information Card 或钓鱼站点欺骗用户登录（缺点3）。缺点4和缺点5的克服与 OpenID 类似。而个人 Information Card 优于 OpenID 的，是它不存在单点失效问题——因为个人 Information Card 根本用不到 Identity Provider。个人 Information Card 的薄弱环节存在于 Identity Selector，不同的 Identity Selector 可以实现不同的 Information Card 管理和使用授权策略。例如 Windows CardSpace 使用 PIN 码验证本地用户对 Information Card 合法拥有，由于 PIN 码验证完全在本机进行，因此没有网络传输的危险；Windows CardSpace 也不允许导出非加密的 Information Card 文件，因此只要 Windows CardSpace 软件机制没有被破解，设置过 PIN 的 Information Card 是不能从本机或网络轻易窃取的——当然还有一个大前提是用户不滥用 Administrator 权限，否则“C:Users[Username]AppDataLocalMicrosoftCardSpace”目录还是有被盗取的危险。而另一家知名的 Identity Selector——Azigo 则提供跨平台的、在线的 Information Card 存储，其信任模型类似于密码托管服务。 　　而上文所谓的“卡片或证件”的学名则是托管（Managed）Information Card，它的主要功能不是验证用户身份和传递用户信息，而是用以证明用户具有某种资质（例如成年用户具有在购物网站购买酒精饮料的资质；持有特定信用卡的用户具有在银行网站使用贵宾服务的资质）。Identity Provider 通过额外的手段审查用户具有某种资质之后，在服务器端生成相应记录，并颁发给用户具有特定字段的托管 Information Card。托管 Information Card 本质上只是一个 XML 格式的、指向 Identity Provider 中相应记录的“指针”文件，它也可以像个人 Information Card 一样保存在 Identity Selector 中。当网站需要验证用户某种资质的时候，托管 Information Card 中的“指针”信息被传送给目标网站，目标网站再连接 Identity Provider 查证用户资质是否存在。托管 Information Card 同样可以克服传统用户名-密码机制的诸多缺点，然而单点失效的问题再一次显露。况且不同的 Identity Provider 提供的资质证明服务是异质的，它们与目标网站也通过证书认证等方式绑定，故不能像 Delegating OpenID 那样简单地找替代品绕过，这是托管 Information Card 有待解决的问题。另外，由于托管 Information Card 的“指针”文件容易复制和传播，为保证其安全，协议规定需要使用 X.509 证书、Kerberos ticket、个人 Information Card 或传统的用户名-密码等至少一种机制来验证用户对托管 Information Card 的合法拥有。这将托管 Information Card 的安全性问题划归到上述机制的安全性问题上了。 　　机制的灵活性使得创造其它类型的 Information Card 成为可能。但新的 Information Card 特性往往需要目标网站和 Identity Selector 的支持。例如 Azigo 支持的几种 Action Card类似于现实中的商场会员卡、打折卡，启用之后可以和 Google、Yahoo 或一些购物网站交互，对使用本卡可打折的商品加以图标提示。 　　Information Card 已经发布多年了，但支持用它登录的网站依然很少，ICF 官方的资源目录中登记的站点屈指可数。微软的 Windows Live 的 Information Card 支持长期处于“Beta”阶段。具有讽刺意味的是专门提供 CardSpace ASP.NET 控件的 Quality Data 公司自己的网站还在使用用户名-密码登录。稍微有点意义的托管 Information Card 是 Equifax 提供的“Over 18 I-Card”成人验证。它通过查证用户的美国社会保险号码发给其代表成人身份的托管 Information Card，目前唯一的用途是在 Watch-This 网站观看 18+ 的视频。而那几家提供 Azigo Action Card 的网站也往往只把虚拟打折卡和实体打折卡绑定，没有让用户体验到 Information Card 的优势，反而是用一种复杂的机制实现了简单的会员折扣提醒功能。 　　Information Card 市场接受程度远不如 OpenID 的原因，我想很可能与其 Identity Selector 机制有关。Identity Selector 确实在一定程度上增强了安全性，但它不像 OpenID 只基于现有的 Web 机制，而需要在客户端部署依赖于操作系统、浏览器的组件。这使得用户感到不便乃至不安，网站运营者因此不会有太大的兴趣。我目前还没有找到在 Chrome 和 Opera 下好使的 Identity Selector。就连 Windows CardSpace 在 IE8 下工作得都有问题，像 SignOn 等网站只有使用 IE7 兼容模式才能登录。可以想像网站运营者如果添加 Information Card 认证，只能收到更多用户的询问或抱怨。Windows Vista 以后 Windows CardSpace 以成为了系统标配，但微软这种把标准协议绑定到 IE 上的行为反而可能引起某些第三方开发者的不满，正如 Mono 常常被一些“纯粹”的自由软件人士抵制一样。Information Card 要想摆脱现在这种尴尬境地，任重而道远。 相关文章Identity 2.0 何时真正到来？（一）OpenID 及其类似物Windows Live 和 Google 账号的一些差别及其对创建个人统一账号的影响浅谈存储系统的信任边界Godaddy Economy Plan Hosting SSH 体验认证你的IPv6能力 [...] [...] Identity 2.0 何时真正到来？（二）处境尴尬的 Information Card 2009/08/15 | 00:05 | 分类：IT杂谈 | 标签：Information Card微软服务用户网络 | 1次阅读 　　在 Identity 2.0 技术族中，Information Card（信息卡）算是 2006 年左右炒作得比较多，然而目前发展却不尽如人意的一支。当时微软把 Windows CardSpace——即它的 Information Card 套件同 WCF、WPF、WF 并列，作为 .NET Framework 3.0 的四大新兴组件来宣传。然而仅从现在的技术图书市场就可以看到：W*F 相关书籍在 .Net 书架上大行其道，而有关 Windows CardSpace 的书籍则是凤毛麟角。细心的 Windows 用户常常会疑惑：新版系统的控制面板中为什么会有一个似乎是制作名片用的 Windows CardSpace 工具？一般用户很少知道微软当年“Codename InfoCard”的雄心。 　　事实上，Information Card 不是微软一家独推的身份认证技术，它还得到了 Intel、Google、Novell、Oracle、Paypal 等公司的支持，并由这些公司共同组建了非盈利的 Information Card Foundation (ICF) 来推进这一技术。和 OpenID 一样，Information Card 也开放标准，没有中心节点，允许任何人按照标准独立实现和构建 Identity Provider 以及基于 Information Card 认证的网络应用，甚至允许用户使用相应的软件在本地自行创建个人 Information Card。Information Card 的工作模型源于生活中的实体证件认证机制：Identity Provider 是按照一定的规则给用户颁发 Information Card，并可以管理和验证自己颁发的 Information Card 的机构，相当于颁发驾照的交管部门或发行信用卡的银行；Identity Selector 是帮助用户保存和管理自己的 Information Card 的本地软件或网络应用，相当于钱包或保险柜；很多 Identity Selector 也兼具创建个人 Information Card 的功能，相当于名片印刷设备。对其工作机制的一个简单比喻是：用户自行制作数字名片，或在发证机关办理数字卡片或证件；平时把自己的数字名片、卡片或证件放在虚拟的钱包或保险柜中；在需要向目标网站证明自己身份的时候，打开钱包或输入保险柜密码，出示相关名片、卡片或证件（事实上只是它们部分“页面”的“复印件”）；目标网站获取其中的非敏感信息，有时还需要向发证机关求证一下卡片或证件的真伪；通过验证之后目标网站即可为用户提供相应的服务。 　　上文所谓的“名片”即个人（Personal）Information Card，这是 Information Card 最常见的一种形式。个人 Information Card 包含用户的非敏感信息，及其创建时间、创建软件和唯一的 ID 等。在发送给目标站点进行身份认证时，只有用户的非敏感信息被传送，因此不存在前文所述的缺点1、2。由于目标网站没有拿到 Information Card 上的 ID 等重要信息，所以它们无法伪造一个与原 Information Card 完全相同的复本来登录原用户注册过的其它网站。在登录时，一个根据协议生成的、不可修改的 Site-Specific Card ID 会发送给目标站点，它唯一表示了特定 Information Card 与特定目标站点的认证关联。Site-Specific Card ID 配合安全协议，具有双向认证特性，可以防止恶意用户伪造他人 Information Card 或钓鱼站点欺骗用户登录（缺点3）。缺点4和缺点5的克服与 OpenID 类似。而个人 Information Card 优于 OpenID 的，是它不存在单点失效问题——因为个人 Information Card 根本用不到 Identity Provider。个人 Information Card 的薄弱环节存在于 Identity Selector，不同的 Identity Selector 可以实现不同的 Information Card 管理和使用授权策略。例如 Windows CardSpace 使用 PIN 码验证本地用户对 Information Card 合法拥有，由于 PIN 码验证完全在本机进行，因此没有网络传输的危险；Windows CardSpace 也不允许导出非加密的 Information Card 文件，因此只要 Windows CardSpace 软件机制没有被破解，设置过 PIN 的 Information Card 是不能从本机或网络轻易窃取的——当然还有一个大前提是用户不滥用 Administrator 权限，否则“C:Users[Username]AppDataLocalMicrosoftCardSpace”目录还是有被盗取的危险。而另一家知名的 Identity Selector——Azigo 则提供跨平台的、在线的 Information Card 存储，其信任模型类似于密码托管服务。 　　而上文所谓的“卡片或证件”的学名则是托管（Managed）Information Card，它的主要功能不是验证用户身份和传递用户信息，而是用以证明用户具有某种资质（例如成年用户具有在购物网站购买酒精饮料的资质；持有特定信用卡的用户具有在银行网站使用贵宾服务的资质）。Identity Provider 通过额外的手段审查用户具有某种资质之后，在服务器端生成相应记录，并颁发给用户具有特定字段的托管 Information Card。托管 Information Card 本质上只是一个 XML 格式的、指向 Identity Provider 中相应记录的“指针”文件，它也可以像个人 Information Card 一样保存在 Identity Selector 中。当网站需要验证用户某种资质的时候，托管 Information Card 中的“指针”信息被传送给目标网站，目标网站再连接 Identity Provider 查证用户资质是否存在。托管 Information Card 同样可以克服传统用户名-密码机制的诸多缺点，然而单点失效的问题再一次显露。况且不同的 Identity Provider 提供的资质证明服务是异质的，它们与目标网站也通过证书认证等方式绑定，故不能像 Delegating OpenID 那样简单地找替代品绕过，这是托管 Information Card 有待解决的问题。另外，由于托管 Information Card 的“指针”文件容易复制和传播，为保证其安全，协议规定需要使用 X.509 证书、Kerberos ticket、个人 Information Card 或传统的用户名-密码等至少一种机制来验证用户对托管 Information Card 的合法拥有。这将托管 Information Card 的安全性问题划归到上述机制的安全性问题上了。 　　机制的灵活性使得创造其它类型的 Information Card 成为可能。但新的 Information Card 特性往往需要目标网站和 Identity Selector 的支持。例如 Azigo 支持的几种 Action Card类似于现实中的商场会员卡、打折卡，启用之后可以和 Google、Yahoo 或一些购物网站交互，对使用本卡可打折的商品加以图标提示。 　　Information Card 已经发布多年了，但支持用它登录的网站依然很少，ICF 官方的资源目录中登记的站点屈指可数。微软的 Windows Live 的 Information Card 支持长期处于“Beta”阶段。具有讽刺意味的是专门提供 CardSpace ASP.NET 控件的 Quality Data 公司自己的网站还在使用用户名-密码登录。稍微有点意义的托管 Information Card 是 Equifax 提供的“Over 18 I-Card”成人验证。它通过查证用户的美国社会保险号码发给其代表成人身份的托管 Information Card，目前唯一的用途是在 Watch-This 网站观看 18+ 的视频。而那几家提供 Azigo Action Card 的网站也往往只把虚拟打折卡和实体打折卡绑定，没有让用户体验到 Information Card 的优势，反而是用一种复杂的机制实现了简单的会员折扣提醒功能。 　　Information Card 市场接受程度远不如 OpenID 的原因，我想很可能与其 Identity Selector 机制有关。Identity Selector 确实在一定程度上增强了安全性，但它不像 OpenID 只基于现有的 Web 机制，而需要在客户端部署依赖于操作系统、浏览器的组件。这使得用户感到不便乃至不安，网站运营者因此不会有太大的兴趣。我目前还没有找到在 Chrome 和 Opera 下好使的 Identity Selector。就连 Windows CardSpace 在 IE8 下工作得都有问题，像 SignOn 等网站只有使用 IE7 兼容模式才能登录。可以想像网站运营者如果添加 Information Card 认证，只能收到更多用户的询问或抱怨。Windows Vista 以后 Windows CardSpace 以成为了系统标配，但微软这种把标准协议绑定到 IE 上的行为反而可能引起某些第三方开发者的不满，正如 Mono 常常被一些“纯粹”的自由软件人士抵制一样。Information Card 要想摆脱现在这种尴尬境地，任重而道远。 相关文章Identity 2.0 何时真正到来？（一）OpenID 及其类似物Windows Live 和 Google 账号的一些差别及其对创建个人统一账号的影响浅谈存储系统的信任边界Godaddy Economy Plan Hosting SSH 体验认证你的IPv6能力 [...]

]]> 由：paul http://blog.linjian.org/articles/identity-20-1-openid/comment-page-1/#comment-465 paul Fri, 14 Aug 2009 02:14:22 +0000 http://blog.linjian.org/?p=377#comment-465 我最近刚好在考虑一种松散的域间认证机制。这种机制中关注的核心信息是”User u is valid @ Domain da"。 所有参与此机制的域独立维护自己的用户系统，用户可以使用u@da尝试登录任何一个域dn（不需要密码），则dn将redirect到已在dn注册的da的登录点，由da对用户进行常规的验证（cookie|password），之后带着ticket返回dn，dn再用一个https webservice获得用户在da的基本信息。这种过程本身是很常见的，貌似就是在Google API上学到的。 此时dn只是确认当前用户是da上的u，至于dn对da上的u提供怎样的服务，取决于dn的策略。不在此机制内（如若便于推广，也应提供一些常见的策略的建议以及在常见系统forums/wp等的实现）。 提供认证的Provider Domain和接受认证信息的Customer Domain是这种机制中的两种基本角色。所谓松散，就是任何两个以上站点都可以使用这种机制建立互相接受认证的机制。 此外，为了进一步增强通用性，可以设立公益的Provider Discovery Server。当u@da尝试登录dn，而dn上并没有da登录接口的注册时，dn可向pds请求da，如da已在pds注册，而dn设置为接受来自pds的注册时，dn可使用pds返回的信息完成da的注册，进而完成u@da的登录过程。这种过程虽然形成了对单点pds的依赖，但是只在da在dn上注册时发生一次（或在之前的注册失效后），而在用户登录过程中并不发生；当然这种注册过程也可以手动完成。（在标准形成后，可约定一个webservice获取provider的必要信息。只需在dn上指定这个discovery webservice即可）。 在这种机制中，参与各方da/dn对认证开关都是可控的;用户信息也是安全的，也没有对单点的过分依赖。参与各方基本对等。从成本/受益上说，da虽然为dn提供验证，但验证的都是da的用户，dn虽然接受的da的用户，但也扩大了自己的用户范围。 目前这个想法还不很成熟，但是一个美好愿景就是你可以用linjian@linjian.org登录所有的站点，而我也可以在任何站点使用paul@wangxiaoxing.net这个唯一的身份。 尚有很多细节不及赘述，我将尝试写一份文档来详细阐述。林兄见多识广，我有一个问题是，这种机制在以前或者现在是否已经有（类似的）实现？ 我最近刚好在考虑一种松散的域间认证机制。这种机制中关注的核心信息是”User u is valid @ Domain da"。
所有参与此机制的域独立维护自己的用户系统，用户可以使用u@da尝试登录任何一个域dn（不需要密码），则dn将redirect到已在dn注册的da的登录点，由da对用户进行常规的验证（cookie|password），之后带着ticket返回dn，dn再用一个https webservice获得用户在da的基本信息。这种过程本身是很常见的，貌似就是在Google API上学到的。
此时dn只是确认当前用户是da上的u，至于dn对da上的u提供怎样的服务，取决于dn的策略。不在此机制内（如若便于推广，也应提供一些常见的策略的建议以及在常见系统forums/wp等的实现）。
提供认证的Provider Domain和接受认证信息的Customer Domain是这种机制中的两种基本角色。所谓松散，就是任何两个以上站点都可以使用这种机制建立互相接受认证的机制。
此外，为了进一步增强通用性，可以设立公益的Provider Discovery Server。当u@da尝试登录dn，而dn上并没有da登录接口的注册时，dn可向pds请求da，如da已在pds注册，而dn设置为接受来自pds的注册时，dn可使用pds返回的信息完成da的注册，进而完成u@da的登录过程。这种过程虽然形成了对单点pds的依赖，但是只在da在dn上注册时发生一次（或在之前的注册失效后），而在用户登录过程中并不发生；当然这种注册过程也可以手动完成。（在标准形成后，可约定一个webservice获取provider的必要信息。只需在dn上指定这个discovery webservice即可）。
在这种机制中，参与各方da/dn对认证开关都是可控的;用户信息也是安全的，也没有对单点的过分依赖。参与各方基本对等。从成本/受益上说，da虽然为dn提供验证，但验证的都是da的用户，dn虽然接受的da的用户，但也扩大了自己的用户范围。
目前这个想法还不很成熟，但是一个美好愿景就是你可以用linjian@linjian.org登录所有的站点，而我也可以在任何站点使用paul@wangxiaoxing.net这个唯一的身份。

尚有很多细节不及赘述，我将尝试写一份文档来详细阐述。林兄见多识广，我有一个问题是，这种机制在以前或者现在是否已经有（类似的）实现？

]]>