它只是一个 .NET 控件，您可以将其删除，配置少量内容，然后让它链接到 Forms 身份验证。相当不错。
To actually answer you question (i.e. disregarding all argumentative points) I'm as-we-speak using DotNetOpenAuth to implement OpenID authorisation for one of my sites; and it's been quite trivial.
It's just a .NET control you drop it, configure a tiny amount of things, and then let it link to Forms authentication. Quite nice.
Okay, you've got a lot of questions under one header there. Let me see if I can break it down.
XRD and Yadis:
"Yadis" was the name for the service discovery chunk of OpenID -- the bit that gets you from "my OpenID is example.com" to "the authoritative server for my OpenID is at openid.example.com/server and it supports v2 with AX extensions." XRDS is the XML schema that holds that information.
(The fact that OpenID (a standard we developed through no recognized standards body) depends on XRD (from another work-in-progress standard in an entirely different standards body) is perhaps regrettable. All I can say is that it seemed like a good idea at the time.)
How the OpenID provider identifies your site (the relying party):
That little text (e.g. "stackoverflow.com") is the OpenID "realm", which is a parameter you pass to the provider and is a strict subset of the endpoint URL you use to process their response. (So if you tell the server to send the OpenID response to server2.example.com/foobar, your realm can be example.com, or server2.example.com, or server2.example.com/foobar, but not server99.example.com.)
Secret API keys:
In general, there is no out-of-band secret API key to obtain. For general-purpose OpenID providers, keys are just issued through the standard OpenID association mechanism.
Now you've hit upon some features here which an OpenID provider might certainly consider valuable -- like "how can I tell the user in a more user-friendly way what site they're logging in to than showing them a URL excerpt" or "how can I identify this request is really coming from an RP I have some sort of contractual relationship with", but such features are not anything that's in the OpenID 2.0 standard.
// using DotNetOpenAuth
var openid = new OpenIdRelyingParty();
var response = openid.GetResponse();
if (response == null)
{
// Google account end point (works fine)
var googleID = "https://www.google.com/accounts/o8/id";
// Google hosted account end point
// https://www.google.com/accounts/o8/site-xrds?hd=mydomain.com
// I was unable to test this, but I was running my RP (this code)
// from localhost and it's quite possible that a hosted account RP
// has to return to the same domain.
// It went fine, but crashed with a "Unable to resolve mydomain.com" error
// once I logged in.
openid.CreateRequest(googleID).RedirectToProvider();
}
else
{
switch (response.Status)
{
case AuthenticationStatus.Authenticated:
// Success
// to allow persistance across sessions
// you'll have to track the "claimed identifier"
// some OpenID providers allow you to get an email address through
// extensions but this is not always possible.
// the claimed identifier is typically your safest bet
// and it's a big URL which uniquely identifies the guest
// as a specific user, however, you know very little about this user
// which is a good thing becuase you don't have to give out personal or
// sensitive information to start using a service.
break;
default:
// Something went wrong, check Status property
break;
}
}
I've actually found a solution to my problem, and surpsingly so, it was very simple. I still don't understand XRDS and Yadis but I'm leveraging it quite easily like so.
What you want, and what you're looking for is code for doing the OpenID "relaying party" stuff. That's "you" as a consumer of OpenID providers. You enter an OpenID endpoint and voila, you've OpenID enabled your site, this code illustrates that in practice.
// using DotNetOpenAuth
var openid = new OpenIdRelyingParty();
var response = openid.GetResponse();
if (response == null)
{
// Google account end point (works fine)
var googleID = "https://www.google.com/accounts/o8/id";
// Google hosted account end point
// https://www.google.com/accounts/o8/site-xrds?hd=mydomain.com
// I was unable to test this, but I was running my RP (this code)
// from localhost and it's quite possible that a hosted account RP
// has to return to the same domain.
// It went fine, but crashed with a "Unable to resolve mydomain.com" error
// once I logged in.
openid.CreateRequest(googleID).RedirectToProvider();
}
else
{
switch (response.Status)
{
case AuthenticationStatus.Authenticated:
// Success
// to allow persistance across sessions
// you'll have to track the "claimed identifier"
// some OpenID providers allow you to get an email address through
// extensions but this is not always possible.
// the claimed identifier is typically your safest bet
// and it's a big URL which uniquely identifies the guest
// as a specific user, however, you know very little about this user
// which is a good thing becuase you don't have to give out personal or
// sensitive information to start using a service.
break;
default:
// Something went wrong, check Status property
break;
}
}
While I was figuring this out, I got the impression from every spec. out there that I was supposed to host my own "OpenID provider" that made it sound like I was supposed to handle accounts or some part of the process. In reality all I had to do was this.
Request that URL, or if you recieve a OpenID request in response. Check to see if that request contains valid login information.
It sounds like you really want to investigate RPX - it's a solution that makes it easy for developers (and users) to use their preferred authentication mechanisms, including OpenID.
Working as a proxy between third party identity providers and your website, RPX helps you effortlessly authenticate users with their existing account on Facebook, Google, Yahoo!, Twitter, MySpace, AOL, Windows Live/MSN/Hotmail, or any other OpenID provider.
发布评论
评论（4）
为了真正回答你的问题（即忽略所有争论点），我使用 DotNetOpenAuth 来实现我的网站之一的 OpenID 授权；这非常微不足道。
它只是一个 .NET 控件，您可以将其删除，配置少量内容，然后让它链接到 Forms 身份验证。相当不错。
To actually answer you question (i.e. disregarding all argumentative points) I'm as-we-speak using DotNetOpenAuth to implement OpenID authorisation for one of my sites; and it's been quite trivial.
It's just a .NET control you drop it, configure a tiny amount of things, and then let it link to Forms authentication. Quite nice.
好的，您在一个标题下有很多问题。让我看看是否可以打破它。
XRD 和 Yadis：
“Yadis”是 OpenID 的服务发现块的名称 - 使您从“我的 OpenID 是 example.com”到“我的 OpenID 的权威服务器位于openid.example.com/server 并且它支持带有 AX 扩展的 v2。” XRDS 是保存该信息的 XML 模式。
（事实上，OpenID（我们通过未经认可的标准机构开发的标准）依赖于 XRD（来自 一个完全不同的标准机构）也许令人遗憾。我只能说这在当时似乎是个好主意。）
“做什么我需要做什么来部署？”
请参阅 Joseph Smarr 的A Recipe for OpenID-Enabling Your Site< /a>.天哪，已经2岁多了？然而，它仍然具有相关性。
OpenID 提供商如何识别您的网站（依赖方）：
这个小文本（例如“stackoverflow.com”）是 OpenID“领域”，它是您传递给提供商的参数，并且是用于处理其响应的端点 URL 的严格子集。 （因此，如果您告诉服务器将 OpenID 响应发送到 server2.example.com/foobar，您的领域可以是 example.com、server2.example.com 或 server2.example.com/foobar，但不能是 server99.example .）
API 秘密密钥：
一般情况下，无需获取带外 API 秘密密钥。对于通用 OpenID 提供商，密钥仅通过标准 OpenID 关联机制颁发。
现在，您已经发现了 OpenID 提供商肯定会认为有价值的一些功能，例如“如何以一种更用户友好的方式告诉用户他们正在登录哪个网站，而不是向他们显示 URL 摘录”或“我如何识别该请求确实来自与我有某种合同关系的 RP”，但此类功能不属于 OpenID 2.0 标准。
Okay, you've got a lot of questions under one header there. Let me see if I can break it down.
XRD and Yadis:
"Yadis" was the name for the service discovery chunk of OpenID -- the bit that gets you from "my OpenID is example.com" to "the authoritative server for my OpenID is at openid.example.com/server and it supports v2 with AX extensions." XRDS is the XML schema that holds that information.
(The fact that OpenID (a standard we developed through no recognized standards body) depends on XRD (from another work-in-progress standard in an entirely different standards body) is perhaps regrettable. All I can say is that it seemed like a good idea at the time.)
"What do I need to do to deploy?"
See Joseph Smarr's A Recipe for OpenID-Enabling Your Site. Holy cow, that's 2+ years old already? It's still relevant, however.
How the OpenID provider identifies your site (the relying party):
That little text (e.g. "stackoverflow.com") is the OpenID "realm", which is a parameter you pass to the provider and is a strict subset of the endpoint URL you use to process their response. (So if you tell the server to send the OpenID response to server2.example.com/foobar, your realm can be example.com, or server2.example.com, or server2.example.com/foobar, but not server99.example.com.)
Secret API keys:
In general, there is no out-of-band secret API key to obtain. For general-purpose OpenID providers, keys are just issued through the standard OpenID association mechanism.
Now you've hit upon some features here which an OpenID provider might certainly consider valuable -- like "how can I tell the user in a more user-friendly way what site they're logging in to than showing them a URL excerpt" or "how can I identify this request is really coming from an RP I have some sort of contractual relationship with", but such features are not anything that's in the OpenID 2.0 standard.
我实际上找到了解决问题的方法，令人惊讶的是，它非常简单。我仍然不理解 XRDS 和 Yadis，但我可以像这样轻松地利用它。
您想要并且正在寻找的是执行 OpenID“中继方”功能的代码。这就是“您”作为 OpenID 提供商的消费者。您输入一个 OpenID 端点，瞧，您的站点已启用 OpenID，此代码在实践中说明了这一点。
当我弄清楚这一点时，我从每个规格中得到了印象。在那里，我应该托管我自己的“OpenID 提供商”，这听起来像是我应该处理帐户或流程的某些部分。事实上我所要做的就是这个。
请求该 URL，或者如果您收到 OpenID 请求作为响应。检查该请求是否包含有效的登录信息。
I've actually found a solution to my problem, and surpsingly so, it was very simple. I still don't understand XRDS and Yadis but I'm leveraging it quite easily like so.
What you want, and what you're looking for is code for doing the OpenID "relaying party" stuff. That's "you" as a consumer of OpenID providers. You enter an OpenID endpoint and voila, you've OpenID enabled your site, this code illustrates that in practice.
While I was figuring this out, I got the impression from every spec. out there that I was supposed to host my own "OpenID provider" that made it sound like I was supposed to handle accounts or some part of the process. In reality all I had to do was this.
Request that URL, or if you recieve a OpenID request in response. Check to see if that request contains valid login information.
听起来您真的很想研究 RPX - 这是一个让开发人员（和用户）可以轻松使用的解决方案他们首选的身份验证机制，包括 OpenID。
It sounds like you really want to investigate RPX - it's a solution that makes it easy for developers (and users) to use their preferred authentication mechanisms, including OpenID.