asp.net Windows Authentication

一、Windows Authentication

1.1 概述

  • authentication——认证
    • 作用是识别用户身份
  • Windows Authentication
    • 用户提供windows账户信息进行身份验证
    • 包括basic、digest以及集成windows认证
    • 主要用于局域网内部

1.2 basic

  • 采用“质询-应答”的方式
  • 认证过程
    • 客户端向服务器请求资源
    • 服务端向客户端索要身份凭证,并在响应报头的WWW-Authenticate中标识认证方式为basic
    • 浏览器识别到该报头,自动弹出对话框,要求输入Windows账号密码
    • 输入完毕后,浏览器将账号密码以“{用户名}:{密码}”的形式发送给服务器,发送时采用Base64进行编码,并存储在请求报头中的Authorization
    • 服务器从请求报头中提取信息并进行校验
  • 账号密码只进行Base64编码,没有进行加密,相当于明文传输

1.3 digest

  • 针对basic方案账号密码明文传输的问题进行了改进
  • 改进方式
    • 在服务端向客户端索要身份凭证的时候,除了在响应报头的WWW-Authenticate中标识认证方式为digest,还下发一个服务器支持的哈希算法类型以及服务端生成的一个唯一标识nonce
      • 哈希算法
        • 将任意数据通过一个函数转换成长度固定的字符串
        • 例如MD5
        • 不可逆
    • 客户端在输入账号密码之后,浏览器自动采用服务端提供的哈希算法以及唯一标识nonce,将密码转化为hashcode,即digest
    • 服务端在收到账号密码信息后,将该账号的真实密码,采用同样的哈希算法及唯一标识生成hashcode,并与客户端提供的digest进行对比,以判断用户身份

1.4 集成windows

  • digest的缺陷

    • 需要弹出框提示输入账号密码
    • 密码的hashcode以及用于生成hashcode的唯一标识nonce会在网络中传输,仍然具有一定风险
  • 分类

    • NTLM

      • 会默认将客户端电脑当前登录的windows账户作为凭证,密码的hashcode在登录客户端电脑时会缓存在客户端电脑,之后访问服务器时不需要再手动输入账号、密码
      • 客户端在第一次请求服务端资源时,会携带用户名
      • 在服务端向客户端索要身份凭证的时候,会携带质询(随机数),并在服务端缓存
      • 客户端收到质询后,用密码hashcode对质询进行加密
      • 服务端收到加密质询,将用户名、加密质询、缓存的原始质询发送给域控制器
        • 域控制器保存所有客户信息
      • 域控制器收到用户名,查询出真实密码,并用真实密码的hashcode对缓存的原始质询进行加密,将加密结果与加密质询进行对比以验证用户身份,并反馈给应用服务器
        在这里插入图片描述
    • Kerberos

      • NTLM只能帮助服务端认证客户端身份
      • Kerberos可以进行双向认证
      • 认证过程
        • 获取认购权证
          • 认购权证
            • 需要服务器认可的票据才能访问服务器资源
            • 获取该票据需要认购权证
            • 票据与认购权证都是由KDC(key distribution center)进行发放
          • 获取方式
            • KAS(Kerberos Authentication Service)运行在客户端主机
            • 当用户登录客户端主机时,KAS自动将用户名以及经过密码派生的密钥加密的authenticator(证明用户身份,是一个联络暗号)发送给KDC
            • KDC收到请求后,根据用户名查询获得真实密码,生成密钥对authenticator进行解密,对比联络暗号是否匹配,以此证明用户身份
            • 验证通过后,KDC返回以下信息
              • 通过用户密码派生的密钥加密的登录会话密钥
              • KDC自己的密钥加密的认购权证
                • 认购权证中又包括登录会话密钥和用户信息
            • 客户端可以利用用户密码派生的密钥解密登录会话密钥
              • 登录会话密钥
                • 替代用户密码
                • 生命周期短,安全性更高
        • 获取服务票据(ST)
          • 在客户端请求资源之前,向KDC上的TGS(Ticket Granting Service)发送以下信息
            • 客户端用户名
            • 通过登录会话密钥加密的authenticator
            • 认购权证
          • TGS解密认购权证,得到登录会话密钥,再利用该密钥解密authenticator,以此判断客户端身份
          • TGS验证通过后,返回以下信息
            • 由登录会话密钥加密的服务会话密钥
            • 由应用服务器密码派生的密钥加密的服务票据(ST)
              • 服务票据包括
                • 服务会话密钥
                • 用户信息
          • 客户端利用登录会话密钥解密得到服务会话密钥
        • 获取服务
          • 在客户端请求资源,向应用服务器发送以下信息
            • 服务会话密钥加密的authenticator
            • 服务票据(经过应用服务器密码加密)
            • 请求内容
            • 客户端设置的authenticator,用于客户端对服务端的验证
          • 应用服务器在收到请求后,从服务票据中提取出服务会话密钥,并验证authenticator,以此验证客户端身份
          • 应用服务器在返回数据的同时,需要携带由客户端设置的authenticator,且经过服务会话密钥加密
          • 客户端利用服务会话密钥解密authenticator,以实现客户端对服务端的认证
            在这里插入图片描述
  • 总结

    • NTLM
      • 为了解决弹出框提示输入账号密码的问题,NTLM采用客户端登陆电脑的windows账户作为身份认证
      • 为了解决密码在网络中传输的问题,NTLM通过发送一个质询,客户端用密码对质询加密的方式来反向验证密码,且能避免直接传输密码
    • Kerberos解决这两种问题的方式与NTLM类似
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值