修改 LDAP 架构以支持 Cardspace 和 OpenID
我正在寻找其他人如何修改 LDAP 模式以支持 Cardspace 和/或 OpenID 的示例。 非常感谢 LDIF 或其他文档的链接。
I am seeking examples of how others have modified LDAP schemas to support Cardspace and/or OpenID. Links to LDIFs or other documentation is greatly appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果没有完成 LDAP-InfoCard-OpenID 集成，我认为修改 LDAP 架构以合并所需信息并不那么困难。
对于 OpenID，您必须存储 OpenID；对于识别 InfoCard 授权的用户，您必须在 LDAP 用户对象中存储相应 InfoCard 的私有个人标识符 (PPID)。
由于 OpenID 只是一个 URI，LDAP 属性可以是相同的类型，例如
labeledURI(Directory String (1.3.6.1.4.1.1466.115.121.1.15), caseExactMatch (2.5.13.5) ）。InfoCard 私有个人标识符 (PPID) 是一个 base64 编码的字节数组（长度未定义，因此您应该需要适当的最大长度；只是猜测，但我认为 48 个字符就足够了，因为 PPID 是 32 个 SHA256 哈希值字节和 base64 编码将需要大约 1.3 倍的存储空间），因此您可以使用
IA5 String。Without having done a LDAP-InfoCard-OpenID-integration I don't think that modifying the LDAP schema to incorporate the required information is that difficult.
For OpenID you have to store the OpenID and for identifiying InfoCard-authorized users you have to store the private personal identifier (PPID) of the respective InfoCard in your LDAP user object.
As an OpenID is merely a URI the LDAP attribute can be of the same type as for example
labeledURI(Directory String (1.3.6.1.4.1.1466.115.121.1.15), caseExactMatch (2.5.13.5)).The InfoCard private personal identifier (PPID) is a base64-encoded byte array (the length is undefined so you should require an appropriate maximum length; just a guess, but I think 48 characters will be enough as the PPID is a SHA256 hash with 32 bytes and base64-encoding will require about 1.3 times the storage space), so you could go with an
IA5 String.