Web APi之认证(Authentication)两种实现方式【二】(十三)

前言

上一节我们详细讲解了认证及其基本信息,这一节我们通过两种不同方式来实现认证,并且分析如何合理的利用这两种方式,文中涉及到的基础知识,请参看上一篇文中,就不再叙述废话。

序言

对于所谓的认证说到底就是安全问题,在Web API中有多种方式来实现安全,【accepted】方式来处理基于IIS的安全(通过上节提到的WindowsIdentity依赖于HttpContext和IIS认证)或者在Web API里通过使用Web API中的消息处理机制,但是如果我们想应用程序运行在IIS之外此时Windows Idenitity这一方式似乎就不太可能了,同时在Web API中本身就未提供如何处理认证的直接方式,我们不得不自定义来实现认证功能,同时这也是我们所推荐的方式,自己动手,丰衣足食。

温馨提示:下面实现方法皆基于基础认证,若不熟悉Http协议中的Basic基础认证,请先参看此篇文章【园友海鸟-介绍Basic基础认证和Digest摘要认证】。

 

无论何种方式,对于我们的应用程序我们都需要在业务层使用基于凭证的用户认证,因为是客户端一方的需求,所以客户端需要明确基础验证,基础认证(Basic)非常简单并且支持任何Web客户端,但是基础验证的缺点是不安全,通过使用SSL则可以进行加密就可以在一定程度上保证了安全,如果是对于一般的应用程序通过基础认证只是进行编码而未加密也可以说是安全的。我们还是看看上一节所给图片

通过上述图片的粗略信息我们可以看出在请求到Action方法之间要经过Web API消息处理管道,在请求到目标元素之前要经过HttpMessageHandler和认证过滤器,所以我们可以通过这两者来自定义实现认证。下面我们一一来看。

基于Web API的认证过滤器(AuthorizationFilterAttribute)实现认证

第一步

我们自定义一个认证身份(用户名和密码)的类,那么此类必须也就要继承于 GenericIdentity ,既然是基于基础验证,那么类型当然也就是Basic了。

    public class BasicAuthenticationIdentity : GenericIdentity
    {
        public string Password { get; set; }
        public BasicAuthenticationIdentity(string name, string password)
            : base(name, "Basic")
        {
            this.Password = password;
        }
    }

第二步

我们要自定义一个认证过滤器特性,并继承 AuthorizationFilterAttribute ,此时会变成如下:

    public class BasicAuthenticationFilter : AuthorizationFilterAttribute
    {
        public override void OnAuthorization(HttpActionContext actionContext)
        {}
    }

那么在这个重写的方法我们应该写什么呢?我们慢慢来分析!请往下看。

  • 解析请求报文头

首先对于客户端发送过来的请求我们肯定是需要获得请求报头,然后解析请求报头中的Authorization,若此时其参数为空,我们将返回到客户端,并发起质询。

            string authParameter = null;

            var authValue = actionContext.Request.Headers.Authorization;  //actionContext:Action方法请求上下文
            if (authValue != null && authValue.Scheme == "Basic")
                authParameter = authValue.Parameter;  //authparameter:获取请求中经过Base64编码的(用户:密码)

            if (string.IsNullOrEmpty(authParameter))

                return null;

次之,若此时认证中的参数不为空并开始对其进行解码,并返回一个BasicAuthenticationIdentity对象,若此时对象为空,则同样返回到客户端,并发起质询

           authParameter = Encoding.Default.GetString(Convert.FromBase64String(authParameter)); //对编码的参数进行解码

            var authToken = authParameter.Split(':');  //解码后的参数格式为(用户名:密码)将其进行分割
            if (authToken.Length < 2)
                return null;

            return new BasicAuthenticationIdentity(authToken[0], authToken[1]); //将分割的用户名和密码传递给此类构造函数进行初始化

最后,我们将上述两者封装为一个ParseHeader方法以便进行调用 

        public virtual BasicAuthenticationIdentity ParseHeader(HttpActionContext actionContext)
        {
            string authParameter = null;

            var authValue = actionContext.Request.Headers.Authorization;
            if (authValue != null && authValue.Scheme == "Basic")
                authParameter = authValue.Parameter;

            if (string.IsNullOrEmpty(authParameter))

                return null;

            authParameter = Encoding.Default.GetString(Convert.FromBase64String(authParameter));

            var authToken = authParameter.Split(':');
            if (authToken.Length < 2)
                return null;

            return new BasicAuthenticationIdentity(authToken[0], authToken[1]);
        }
  • 接下来我们将认证未通过而需要发起认证质询,我们将其封装为一个方法Challenge

        void Challenge(HttpActionContext actionContext)
        {
            var host = actionContext.Request.RequestUri.DnsSafeHost;
            actionContext.Response = actionContext.Request.CreateResponse(HttpStatusCode.Unauthorized);
            actionContext.Response.Headers.Add("WWW-Authenticate", string.Format("Basic realm=\"{0}\"", host));

        } 
  • 定义一个方法便于对用户名和密码进行校验,并将其修饰为虚方法,以免后续要添加其他有关用户数据

        public virtual bool OnAuthorize(string userName, string userPassword, HttpActionContext actionContext)
        {
            if (string.IsNullOrEmpty(userName) || string.IsNullOrEmpty(userPassword))

                return false;
            else
                return true;

        }
  •  在认证成功后将认证身份设置给当前线程中Principal属性

           var principal = new GenericPrincipal(identity, null);

            Thread.CurrentPrincipal = principal;

            //下面是针对ASP.NET而设置
            //if (HttpContext.Current != null)
            //    HttpContext.Current.User = principal;

第三步

一切已经就绪,此时在重写方法中进行相应的调用即可,如下:

    [AttributeUsage(AttributeTargets.Class | AttributeTargets.Method, AllowMultiple = false)]
    public class BasicAuthenticationFilter : AuthorizationFilterAttribute
    {
        public override void OnAuthorization(HttpActionContext actionContext)
        {
            var userIdentity = ParseHeader(actionContext);
            if (userIdentity == null)
            {
                Challenge(actionContext);
                return;
            }

            if (!OnAuthorize(userIdentity.Name, userIdentity.Password, actionContext))
            {
                Challenge(actionContext);
                return;
            }

            var principal = new GenericPrincipal(userIdentity, null);

            Thread.CurrentPrincipal = principal;

            base.OnAuthorization(actionContext);
        }

第四步 

自定义 CustomBasicAuthenticationFilter 并继承于 BasicAuthenticationFilter ,重写其虚方法。

    public class CustomBasicAuthenticationFilter : BasicAuthenticationFilter
    {
        public override bool OnAuthorize(string userName, string userPassword, HttpActionContext actionContext)
        {
            if (userName == "xpy0928" && userPassword == "cnblogs")

                return true;
            else
                return false;

        }
    }

最后一步

注册自定义认证特性并进行调用

    config.Filters.Add(new CustomBasicAuthenticationFilter());

    [CustomBasicAuthenticationFilter]
    public class ProductController : ApiController
    {....}

至此对于其认证方式就已经完全实现,接下来我们通过【搜狗浏览器】来验收我们的成果。

看到如下认证其用户名和密码的图片,我们知道我们成功了一半

我们点击取消,观察是否返回401并添加质询头即WWW-Authenticate,如我们所料

我们输入正确的用户名和密码再试试看,结果认证成功,如下:

基于Web API的消息处理管道(HttpMessageHandler)实现认证

我们知道HttpMessageHandler是Web API中请求-响应中的消息处理管道的重要角色,但是真正实现管道串联的是DelegatingHandler,若你不懂Web API消息管道,请参考前面系列文章,所以我们可以自定义管道来进行拦截通过继承DelegatingHandler。下面我们一步步来实现基于此管道的认证。

第一步

和第一种方法一致不再叙述。

第二步

这一步当然是自定义管道进行处理并继承DelegatingHandler,重载在此类中的SendAsync方法,通过获得其请求并处理从而进行响应,若不懂此类中的具体实现,请参看前面系列文章。

  • 同样是我们需要根据请求来解析请求报头,我们依然需要解析报头方法,但是需要稍作修改

        public virtual BasicAuthenticationIdentity ParseHeader(HttpRequestMessage requestMessage)
        {
            string authParameter = null;

            var authValue = requestMessage.Headers.Authorization;
            if (authValue != null && authValue.Scheme == "Basic")
                authParameter = authValue.Parameter;

            if (string.IsNullOrEmpty(authParameter))

                return null;

            authParameter = Encoding.Default.GetString(Convert.FromBase64String(authParameter));

            var authToken = authParameter.Split(':');
            if (authToken.Length < 2)
                return null;

            return new BasicAuthenticationIdentity(authToken[0], authToken[1]);
        }
  • 此时质询也得作相应的修改,因为此时不再是依赖于Action请求上下文,而是请求(HttpRequestMessage)和响应(HttpResponseMessage)

        void Challenge(HttpRequestMessage request,HttpResponseMessage response)
        {
            var host = request.RequestUri.DnsSafeHost;

            response.Headers.Add(authenticationHeader, string.Format("Basic realm=\"{0}\"", host));

        }
  • 最终继承自DelegatingHandler的代码如下

    public class BasicAuthenticationHandler : DelegatingHandler
    {
        private const string authenticationHeader = "WWW-Authenticate";
        protected override Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
        {
            var crendentials = ParseHeader(request);

            if (crendentials != null)
            {
                var identity = new BasicAuthenticationIdentity(crendentials.Name, crendentials.Password);

                var principal = new GenericPrincipal(identity, null);

                Thread.CurrentPrincipal = principal;

                //针对于ASP.NET设置
                //if (HttpContext.Current != null)
                //    HttpContext.Current.User = principal;
            }

            return base.SendAsync(request, cancellationToken).ContinueWith(task => {
                var response = task.Result;
                if (crendentials == null && response.StatusCode == HttpStatusCode.Unauthorized)
                {
                    Challenge(request, response);
                }

                return response;
            });

        }

        void Challenge(HttpRequestMessage request,HttpResponseMessage response)
        {
            var host = request.RequestUri.DnsSafeHost;

            response.Headers.Add(authenticationHeader, string.Format("Basic realm=\"{0}\"", host));

        }

        public virtual BasicAuthenticationIdentity ParseHeader(HttpRequestMessage requestMessage)
        {
            string authParameter = null;

            var authValue = requestMessage.Headers.Authorization;
            if (authValue != null && authValue.Scheme == "Basic")
                authParameter = authValue.Parameter;

            if (string.IsNullOrEmpty(authParameter))

                return null;

            authParameter = Encoding.Default.GetString(Convert.FromBase64String(authParameter));

            var authToken = authParameter.Split(':');
            if (authToken.Length < 2)
                return null;

            return new BasicAuthenticationIdentity(authToken[0], authToken[1]);
        }
    }

第三步 

上述我们自定义的BasicAuthenticationFilter此时就得继承 AuthorizeAttribute 该特性也是继承于上述的 AuthorizationFilterAttribute ,我们需要利用AuthorizeAttribute中的 IsAuthorized 方法来验证当前线程中的Principal是否已经被授权。

    public class BasicAuthenticationFilter : AuthorizeAttribute
    {
        protected override bool IsAuthorized(HttpActionContext actionContext)
        {

            var identity = Thread.CurrentPrincipal.Identity;
            if (identity != null && HttpContext.Current != null)
                identity = HttpContext.Current.User.Identity;

            if (identity != null && identity.IsAuthenticated)
            {

                var basicAuthIdentity = identity as BasicAuthenticationIdentity;
                  //可以添加其他需要的业务逻辑验证代码
                if (basicAuthIdentity.Name == "xpy0928" && basicAuthIdentity.Password == "cnblogs")
                {
                    return true;
                }
            }

            return false;

        }
  }

通过 IsAuthorized 方法返回值来看,若为false,则返回401状态码,此时会触发 BasicAuthenticationHandler  中的质询,并且此方法里面主要是我们需要添加认证用户的业务逻辑代码。同时我们也说过我们第一种方法自定义实现的过滤器特性是 AuthorizationFilterAttribute (如果我们有更多逻辑使用这个特性是个不错的选择),而在这里是 AuthorizeAttribute (对于验证用户并且返回bool值使用此过滤器特性是个不错的选择)。

第四步

注册自定义管道以及认证过滤器特性

            config.MessageHandlers.Add(new BasicAuthenticationHandler());
            config.Filters.Add(new BasicAuthenticationFilter());

最后一步

    [BasicAuthenticationFilter]
    public class ProductController : ApiController
    {.....}

下面我们通过【360极速浏览器】来验收成果。点击按钮直接请求控制器

接下来取消,是否返回401

至此完美结束。

总结 

用认证特性(AuthorizationFilterAttribute)还是HttpMessageHandler实现认证,这是一个问题? 

通过比较这二者的实现操作在实现方式上明显有极大的不同,个人觉得用AuthorizationFilterAttribute来实现认证是更加简单并且紧凑,因为实现的每一处都在每一个地方,在大多数实现自定义登陆的场景下,对于用过滤器如此紧凑的业务逻辑用这个更加高效, 用HttpMessageHandler的优点是全局应用且是Web API消息处理管道的一部分,如果对于不同的部分要用不同的认证那么用HttpMessageHandler效果更好,但是此时你需要自定义一个过滤器,尤其是当MessageHandler对于一个认证需要一个过滤器的时候。所以综上所述,根据不同的应用场景我们应该选择对应的方式来实现认证。

 

源代码链接

 WebAPi之认证.7z

时间: 2024-10-23 14:50:50

Web APi之认证(Authentication)两种实现方式【二】(十三)的相关文章

Web APi之认证(Authentication)两种实现方式后续【三】(十五)

前言 之前一直在找工作中,过程也是令人着实的心塞,最后还是稳定了下来,博客也停止更新快一个月了,学如逆水行舟,不进则退,之前学的东西没怎么用,也忘记了一点,不过至少由于是切身研究,本质以及原理上的脉络还是知其所以然,所以也无关紧要,停止学习以及分享是一件很痛苦的事情,心情很忐忑也很担忧,那么多牛逼的人都在无时无刻的学习更何况是略懂皮毛的我呢?好了,废话说了不少,我们接下来进入主题. 话题 看到博客也有对于我最近有关Web APi中认证这篇文章的评论和疑问,[其中就有一个是何时清除用户的信息呢],

将HTML的左右尖括号等转义成实体形式的两种实现方式

  这篇文章主要介绍了将HTML的左右尖括号等转义成实体形式的两种实现方式,需要的朋友可以参考下 前端开发工作中,经常需要将HTML的左右尖括号等转义成实体形式.我们不能把<,>,&等直接显示在最终看到的网页里.需要将其转义后才能在网页上显示. 转义字符(Escape Sequence)也称字符实体(Character Entity).定义转义字符串的主要原因是 "<"和">"等符号已经用来表示HTML TAG,因此不能直接当作文本中

android intent-intent 两种启动方式各有什么特点

问题描述 intent 两种启动方式各有什么特点 简述 intent. 两种启动方式 各有什么特点........................................................................... 解决方案 第一种:显示启动 在Mainfiest的配置: 以设置组件方式启动: Intent i=new Intent() i.setComponent(new ComponentName(""com.oo.intent"&quo

Silverlight实用窍门系列:37.Silverlight和ASP.NET相互传参的两种常用方式(QueryString,Cookie)【附带实例源码】

在本节中将讲述Silverlight和ASP.NET页面的相互传参的两种常用方式:Cookie和QueryString.首先我们新建一个名为SLConnectASP.NET的Silverlight应用程序,然后在SLConnectASP.NET.web项目中添加一个Index.aspx的页面. 一.Silverlight和ASPX页面的QueryString传参 实现思路:在Silverlight端跳转到页面到Index.aspx并且传递一个QueryString参数ID,在该Index.asp

Delphi中动态链接库两种调用方式的比较

一.动态链接库的概念 动态链接库(Dynamic Link Library,缩写为DLL)是一个可以被其它应用程序共享的程序模块,其中封装了一些可以被共享的例程和资源.动态链接库文件的扩展名一般是dll,也有可能是drv.sys和fon,它和可执行文件(exe)非常类似,区别在于DLL中虽然包含了可执行代码却不能单独执行,而应由Windows应用程序直接或间接调用. 动态链接是相对于静态链接而言的.所谓静态链接是指把要调用的函数或者过程链接到可执行文件中,成为可执行文件的一部分.换句话说,函数和

详解Android中Fragment的两种创建方式_Android

fragment是Activity中用户界面的一个行为或者是一部分.你可以在一个单独的Activity上把多个Fragment组合成为一个多区域的UI,并且可以在多个Activity中再使用.你可以认为fragment是activity的一个模块零件,它有自己的生命周期,接收它自己的输入事件,并且可以在Activity运行时添加或者删除. 两个概念:Fragment.宿主 fragment的生命周期直接受其宿主activity的生命周期的影响.例如,一旦activity被暂停,它里面所有的fra

Oracle优化器的两种优化方式

Oracle的优化器有两种优化方式: 基于规则的优化方式:Rule-Based Optimization(RBO) 基于成本或者统计信息的优化方式(Cost-Based Optimization:CBO) RBO方式:优化器在分析SQL语句时,所遵循的是Oracle内部预定的一些规则.比如我们常见的,当一个where子句中的一列有索引时去走索引. CBO方式:CBO是在ORACLE7 引入,但到ORACLE8i 中才成熟.ORACLE 已经声明在ORACLE9i之后的版本中,RBO将不再支持.它

javascript中createElement的两种创建方式

  本文实例讲述了javascript中createElement的两种创建方式.分享给大家供大家参考.具体实现方法如下: ? 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 <html xmlns="http://www.w3.org/1999/xhtml"> &l

Android Activity 的四种启动模式 lunchMode 和 Intent.setFlags();singleTask的两种启动方式。

原文:Android Activity 的四种启动模式 lunchMode 和 Intent.setFlags();singleTask的两种启动方式. Android Activity 的四种启动模式 lunchMode 和 Intent.setFlags(); 一.Android Activity 四种启动模式 lunchMode 在Manifest 配置文件中的属性如下: (1) android:launchMode="standard" (2)android:launchMod