转载【http://www.cnblogs.com/think8848/archive/2011/03/06/1972195.html】
听到DotNetOpenAuth是去年某一天的事了，当时在读《RESTful Web Service》时突然好像灵光一闪，觉得Authorization这个问题似乎应该在构建服务之前就先考虑清楚，否则服务化似乎就无从谈起了。为什么这么说呢，举例来说，Google Canlendar是一个服务，你现在使用Google Canlendar又构建了另一个服务，并幸运的拥有了一些用户，但这些用户怎么才能放心的把Google的帐户信息交给你，让你拿去Google验证呢；另一点，我们公司现在项目比较多，每个新项目建立后，都要往里复制一份诸如Organization，UserManager之内的公共文件(主要集中在UI层)，增加工作量不说，这些不同拷贝的版本更新就是一个严峻的挑战，更不要说如果一个客户同时使用了我们两个产品，就会发现居然同一个人要维护和软件产品数量相同的用户...这一切，使得将Organization之类的组件成为服务的要求变得非常强烈，即把Organization业务本身做为一个应用程序存在，发布在IIS后其他项目使用其提供的数据服务即可，这样就不存在每次都要复制UI，以及多个产品间多套数据的问题了。到这里，使用SSO似乎已经不可避免了，但是有个问题还没有考虑到，在使用Web Service时不会总是直接使用页面去调用吧，大多数时候得提供一个服务客户端组件，否则有谁会每次调用你一个数据，还在业务层里添加一堆有关Authorization和Cookie的代码？所以看起来使用简单的SSO实现方式，很难高效，体面的解决问题。
于是我就发现居然有DotNetOpenAuth(真不明白为什么被墙了，想看的FQ吧，源码托管地址)这么个东西了，看介绍似乎就涵盖了我想要的一切功能！
文档可能是最让人又爱又恨的东西了，自已不愿意写文档，但都希望使用别人的东西时有完备的文档。
前两天在学习jqGrid，没有一个像样的文档就灰常痛苦，一天下来，浏览历史里就只有Google的搜索记录了。当时下载DotNetOpenAuth下来也是一样，除了一个API Documents之外，没有任何有点价值的资料，虽然他们提供了好几个样例，但是对于一个比较复杂的技术来说，这些远远不够，最起码得有个Quick Start或是How to吧，可惜官网上几乎啥也没有。也不知到底是啥原因我后来也没有再去看这个组件。
一直到前两天，我还是觉得如果说要考虑无论是Web Service，抑或SOA实践，乃至现在火热的云计算，如果Authorization问题不解决掉，似乎就无从谈起。很多的书上使用大量的篇幅讲解如何设计，实现一个Service，但却很少提及SOA实践或云计算的实务讲解，结果大家一通倒腾之后，一个个所谓的Web Service拔地而起，但怎么看也不像是“云”。解决Authorization问题，还是从DotNetOpenAuth入手比较好，它功能强大，而且oauth和openid是成熟的产品，使用的公司很多，几乎成了事实标准，找一个和当前工作比较贴近的点，就学习下OpenIdSSOProvider吧。
（这篇文章呢，我想来想去不知该如何去写，为什么呢？主要是我认为SOA或是云计算是一个非常飘渺的东西，恶补一段时间后，我总会觉得对其概念还算清楚，但是时间一长就会又模糊不清，写自已都不太清楚的东西，遭人骂是小事，耽误人是大事。我本是个看贴不回贴的人，但是现在网上有关服务设计实务的东西少之有少，DotNetOpenAuth方面的东西也是凤毛麟角，我是不想回贴，但是看贴也没得看，因此权当抛砖引玉，希望能和我有共同想法的人探讨一二）
说了这么多废话后，进入正题...
DotNetOpenAuth本身提供了一SSOProvider示例，但是只有WebForm项目的，没有MVC的SSOProvider示例，本文提供MVC的SSOProvider实现方法，再顺便讲讲个人对于使用DotNetOpenAuth的一点点小体会。
一.SsoOP SSO的服务提供者
1.建立SsoOP项目，我使用了Razor视图引擎，添加DotNetOpenAuth.dll引用。下载地址见上面的源码托管地址.
2.设置web.config文件里面的配置信息，详情请见本文下方示例程序。
3.创建OpenIdController.cs
public class OpenIdController : Controller { internal static OpenIdProvider openIdProvider = new OpenIdProvider(); public ActionResult Identifier() { if (User.Identity.IsAuthenticated && ProviderEndpoint.PendingAuthenticationRequest != null) { Util.ProcessAuthenticationChallenge(ProviderEndpoint.PendingAuthenticationRequest); if (ProviderEndpoint.PendingAuthenticationRequest.IsAuthenticated.HasValue) { ProviderEndpoint.SendResponse(); } } if (Request.AcceptTypes.Contains("application/xrds+xml")) { return new TransferResult("~/OpenId/Xrds"); } return View(); } [ValidateInput(false)] public ActionResult Provider() { var request = openIdProvider.GetRequest(); if (request != null) { if (request.IsResponseReady) { return openIdProvider.PrepareResponse(request).AsActionResult(); } ProviderEndpoint.PendingRequest = (IHostProcessedRequest)request; var idrequest = request as IAuthenticationRequest; return Util.ProcessAuthenticationChallenge(idrequest); } return View(); } public ActionResult AskUser() { return View(); } public ActionResult Xrds() { return View(); } }
OpenIdController是SsoRP(SSO消费者)使用OP的入口点，其中Provider是提供登录服务的Action，这点需要在后面提到。
4.创建Xrds.cshtml视图
@{
Layout = null;
Response.ContentType = "application/xrds+xml";
var uri = new Uri(Request.Url, Response.ApplyAppPathModifier("~/OpenId/Provider")).ToString();
}<?xml version="1.0" encoding="UTF-8"?>
<xrds:XRDS
xmlns:xrds="xri://$xrds"
xmlns:openid="http://openid.net/xmlns/1.0"
xmlns="xri://$xrd*($v*2.0)">
<XRD>
<Service priority="10">
<Type>http://specs.openid.net/auth/2.0/server</Type>
<Type>http://openid.net/extensions/sreg/1.1</Type>
<URI>@uri</URI>
</Service>
</XRD>
</xrds:XRDS>
本视图的用法也将在以后提到。
5.创建AskUser.cshtml视图
@{
Layout = null;
Response.ContentType = "application/xrds+xml";
var uri1 = new Uri(Request.Url, Response.ApplyAppPathModifier("~/OpenId/Provider")).ToString();
var uri2 = new Uri(Request.Url, Response.ApplyAppPathModifier("~/OpenId/Provider")).ToString();
}<?xml version="1.0" encoding="UTF-8"?>
<xrds:XRDS
xmlns:xrds="xri://$xrds"
xmlns:openid="http://openid.net/xmlns/1.0"
xmlns="xri://$xrd*($v*2.0)">
<XRD>
<Service priority="10">
<Type>http://specs.openid.net/auth/2.0/signon</Type>
<Type>http://openid.net/extensions/sreg/1.1</Type>
<URI>@uri1</URI>
</Service>
<Service priority="20">
<Type>http://openid.net/signon/1.0</Type>
<Type>http://openid.net/extensions/sreg/1.1</Type>
<URI>@uri2</URI>
</Service>
</XRD>
</xrds:XRDS>
6.建立TransferResult类，什么作用呢，这里稍作解释：在ASP.NET WebForm页面中，有人可能用过Server.Transfer方法，该方法MSDN中的解释是：对于当前请求，终止当前页的执行，并使用指向一个新页的指定 URL 路径来开始执行此新页。一般情况下似乎和Redirect方法的作用很像，但是某些特殊场合中，区别是大大的，是什么呢？Redirect是执行客户端重定向，而Transfer是不用客户端重定向的，应该就是HTTP的302状态吧。在使用DotNetOpenAuth的过程中，很多时候也许是基于安全的考虑，OpenId是不允许使用重定向了的请求，不然就会出错。在MVC中有一个RedirectToAction方法很好用，却没有一个TransferToAction方法，甚至没有TransferResult类型，所以不得不自已弄一个。
public class TransferResult : RedirectResult
{
public TransferResult(string url)
: base(url)
{
}
public override void ExecuteResult(ControllerContext context)
{
var httpContext = HttpContext.Current;
httpContext.RewritePath(Url, false);
IHttpHandler httpHandler = new MvcHttpHandler();
httpHandler.ProcessRequest(HttpContext.Current);
}
}
7.其他的代码，限于篇幅，就不一一贴上来了，全放到示例程序里面，结构如下：
/Code/ReadOnlyXmlMembershipProvider.cs 作用：用户验证
/Code/Util.cs 作用：用于处理登录及权限请求，这个类里面的主要方法为：ProcessAuthenticationChallenge，在官方提供的样例中是一个void，用在MVC中，必须使用一个具有ActionResult返回值的方法了。
/AppData/Users.xml 作用：相当于存用户信息的数据库
8.在项目根目录下创建default.aspx，该文件为使用IIS架设程序时的入口
<%@ Page Language="C#" AutoEventWireup="true" %>
<script runat="server">
protected void Page_Load(object sender, EventArgs e) {
Response.Redirect("~/Home/Index");
}
</script>
OK,SsoOP主要结构就是上面这些，文档结构见下图(其中选中的文件是新增的，其他的都是项目模板自带的)：
二.SsoRP 这个RP和人品没有太大关系，作用为SSO的消费者
文档结构如下：
这个项目主要内容如下：
1.将AccountController类中的内容全部注释，添加以下代码：
public class AccountController : Controller
{
private const string RolesAttribute = "http://samples.dotnetopenauth.net/sso/roles";
private static OpenIdRelyingParty relyingParty = new OpenIdRelyingParty();
public ActionResult LogOn()
{
if (Array.IndexOf(Request.AcceptTypes, "application/xrds+xml") >= 0)
{
return View("Xrds");
}
UriBuilder returnToBuilder = new UriBuilder(Request.Url);
returnToBuilder.Path = "/Account/LogOn";
returnToBuilder.Query = null;
returnToBuilder.Fragment = null;
Uri returnTo = returnToBuilder.Uri;
returnToBuilder.Path = "/Account/LogOn";
Realm realm = returnToBuilder.Uri;
var response = relyingParty.GetResponse();
if (response == null)
{
if (Request.QueryString["ReturnUrl"] != null && User.Identity.IsAuthenticated)
{
// The user must have been directed here because he has insufficient
// permissions to access something.
this.ViewBag.Message = "1";
}
else
{
// Because this is a sample of a controlled SSO environment,
// we don't ask the user which Provider to use... we just send
// them straight off to the one Provider we trust.
var request = relyingParty.CreateRequest(
ConfigurationManager.AppSettings["SsoProviderOPIdentifier"],
realm,
returnTo);
var fetchRequest = new FetchRequest();
fetchRequest.Attributes.AddOptional(RolesAttribute);
request.AddExtension(fetchRequest);
request.RedirectToProvider();
}
}
else
{
switch (response.Status)
{
case AuthenticationStatus.Canceled:
this.ViewBag.Message = "Login canceled.";
break;
case AuthenticationStatus.Failed:
this.ViewBag.Message = HttpUtility.HtmlEncode(response.Exception.Message);
break;
case AuthenticationStatus.Authenticated:
IList<string> roles = null;
var fetchResponse = response.GetExtension<FetchResponse>();
if (fetchResponse != null)
{
if (fetchResponse.Attributes.Contains(RolesAttribute))
{
roles = fetchResponse.Attributes[RolesAttribute].Values;
}
}
if (roles == null)
{
roles = new List<string>(0);
}
// Apply the roles to this auth ticket
const int TimeoutInMinutes = 100; // TODO: look up the right value from the web.config file
var ticket = new FormsAuthenticationTicket(
2,
response.ClaimedIdentifier,
DateTime.Now,
DateTime.Now.AddMinutes(TimeoutInMinutes),
false, // non-persistent, since login is automatic and we wanted updated roles
string.Join(";", roles.ToArray()));
HttpCookie cookie = new HttpCookie(FormsAuthentication.FormsCookieName, FormsAuthentication.Encrypt(ticket));
Response.SetCookie(cookie);
Response.Redirect(Request.QueryString["ReturnUrl"] ?? FormsAuthentication.DefaultUrl);
break;
default:
break;
}
}
return RedirectToAction("Index", "Home");
}
public IFormsAuthenticationService FormsService { get; set; }
protected override void Initialize(RequestContext requestContext)
{
if (FormsService == null) { FormsService = new FormsAuthenticationService(); }
base.Initialize(requestContext);
}
public ActionResult LogOff()
{
FormsService.SignOut();
return RedirectToAction("Index", "Home");
}
｝
结合SsoOP,将个人的理解稍作解释：
因为在web.config里面使用下面的配置
<authentication mode="Forms">
<forms name="OpenIdWebRingSsoRelyingParty" loginUrl="~/Account/LogOn" protection="All"
path="/"
timeout="900" />
</authentication>
<authorization>
<deny users="?"/>
</authorization>
因为使用了Forms模式，在没有登录的情况下，无论访问任何资源，都会使请求转到Account的LogOn Action中，在LogOn中，程序会先向OP的Identifier验证是否存在ProviderEndpoint，OP通过OpenIdController的Xrds Action(既OP节中的Xrds.cshtml视图内容)告诉RP这个提供者是存在并合法的，然后RP向提供者请求认证，反过来，OP倒也要确认RP是否存在并合法（使用RP中的Xrds.cshtml），如果没有问题OP还要验证请求认证的RP是否在白名单中，这个白名单中必须要和returnToBuilder.Path = "/Account/LogOn";这个值完全一致，比如这里在LogOn后面没有"/"号，那么在白名单中，你就必须使用http://localhost:1220/Account/LogOn，而不能在后面加上“/”号，否则就会不通过。如果一切OK，没有问题页面将转向OP的登录页面，本例中为Account/LogOn，用户输入正确的用户和密码（本例User:bob;Password:test）。
登录完成后，根据LogOn中的代码return RedirectToAction("Identifier", "OpenId");，请求会转向OpenId/Identifier，程序会先去准备响应数据，这些数据中包含了登录用户信息，熟悉openid的人知道，openid总是使用一个url+用户名代表用户名，这个url其实就是另一个发现OP的地方，为什么是另一个？还有一个在哪里呢？就在OpenId/Identifier里面呀，（因为还没有对DotNetOpenAuth深入研究，因此，对于官方示例中“服务发现”这个机制还有点模糊，个人感觉应该就是相当于验证是否相任之类的吧，Identifier应该属于登录前和登录阶段的，当登录完成后使用用户名中地址里面的验证了？），接下来使用ProviderEndpoint.SendResponse();向客户端发送登录结果，并使用return_to里面的信息将请求转到了RP的LogOn中，（在这个过程，RP将使用OP中AskUser“发现”服务提供者。）在LogOn中，根据IAuthenticationResponse的状态信息，确定是登录成功还是登录失败（会携带失败原因信息）来确定请求转向，既然咱都有示例代码了，应该就不会失败吧，所以Home/Index会如期而至。
SsoRP示例有两个，一个是纯MVC模式的，一个是使用MVC + WebForms模式的。
DotNetOpenAuth的资料现在貌似很少，个人对其的研究现在还处于Step by Step的阶段，只能说跟着官方的示例能做出一个MVC实现，但是对于很多具体的原理还是相当不熟悉，这示例只能是解决有和没有的问题，本文中的谬误还望大家不吝赐教，希望有人能发更多有深度的资料。