加载中…
DWS开发档案解密：Web的验证方法与权限控制
(2007-04-01 22:28:08)| 分类： Web 3.0 |
基于的 Web
应用在授权认证方面，有多种安全验证方法，最早的方法是通过 Web
服务器支持的 WWW-Authenticate 标准所实现的，支持 Base64 和 MD5
等编码。一般浏览器允许3次重试的机会，验证失败时返回401错误提示，验证成功则多出一个
REMOTE_USER 环境变量。
在 IIS 上除了支持标准的 WWW-Authenticate 还支持 WindowsNT 的 NTLM 验证方式，但这个方法在其它浏览器和其他 eb 服务器下并不兼容，通常只应用于局域网。
WWW-Authenticate 是以目录为对象的，如将 /users 目录加上访问控制，则 /users 目录下的内容，必须通过验证的用户才能访问。
这种方法的问题是界面不够友好，将验证放在 Web 服务器这一层会有所局限，账号权限也不在 Web 服务器这层区分，Web 服务器只做用户认证工作。通常 Web 服务器只根据本机的配置信息进行验证，在做分布式处理时显得比较吃力，虽然像 Apache 也有 MySQL 的验证模组，但都不是默认配置，并且部署起来非常困难。
另一种则是基于 HTTPS 的安全连接，需要证书、公钥、私钥等，使用复杂，需要专门申请证书并安装等，通常只见于和银行有关的网站服务。
比较常见的方法是采用 Cookies 或 Session 记录用户认证的登录信息，每次通过 Session 提交到服务器进行对比。该方法则只利用 Web 服务器最基本的 Cookies 支持，一般需要自己编写专门的 Session 及 Authe 程序用于账号注册、管理、登录等程序。
上面这种方法兼容性相对来说还不错，但并不是最好的，更旧的或某些特殊的浏览器，甚至连 Cookies 都不支持，又或者是用户为了安全考虑，将 Cookies 功能禁止了，此时利用这种方法则会失效。还有一种情况Cookies解决不了，那就当跨域操作时，由于安全原因，Cookies 是无法继承过去的。
为了解决这些问题，有一种方法可以解决，就是在 CGI 程序的 QUERY_STRING 环境变量增加 Session 值，如 abc.cgi?a=a1&b=b1&session=898e82c94d7703e96f7ea83b31e0ac2b，不过一般为了更好的兼容性，甚至将
Session 值赋给 PATH_INFO 环境变量，如 /cgi-bin/abc.cgi
是真实相对路径，登录后的 PATH_INFO 环境变量为
/cgi-bin/898e82c94d7703e96f7ea83b31e0ac2b/abc.cgi，每次通过中间的
Session 值与服务器记录的进行对比效果相同。
权限控制方面，复杂程度将根据业务逻辑去设计，一般会有管理、普通、访客等三种角色，进一步的则用组去划分权限。
最复杂，也是目前我最欣赏的是 Yahoo! ID 及 Microsoft Passport，他们的兼容性从一开始到扩展 N 多的业务，都能一脉相承。特别是 Yahoo! ID 收购了数十个公司，依然能做到这一点，在中国到目前为止尚没有一家公司能做到。
Yahoo! ID 的方法不算复杂，有个中心验证服务器。各种应用服务器遇到需要验证的情况时，将应用服务器的信息附在 URI 上，先重定向到中心验证服务器，验证通过后再重定向回应用服务器。
中心验证服务器是用 LDAP 实现的，只保留有最简单及核心的隐私资料，各种应用服务器需要的信息，在首次使用时，会进行一次初始化，补充一些个人信息和功能设置等。
我们 DWS 的验证问题虽然没有和 Yahoo! ID 要求的那么复杂，但是他是最值得我们借鉴的对象，Web 服务器的验证为了是控制远程用户的认证，内部的认证则可以理解为 Passport 的验证，一个账号登录后，在各个子域（或应用）间跳转时，无需再次登录，继承账号登录信息，但是并不继承权限，各有各的权限管理。
在 IIS 上除了支持标准的 WWW-Authenticate 还支持 WindowsNT 的 NTLM 验证方式，但这个方法在其它浏览器和其他 eb 服务器下并不兼容，通常只应用于局域网。
WWW-Authenticate 是以目录为对象的，如将 /users 目录加上访问控制，则 /users 目录下的内容，必须通过验证的用户才能访问。
这种方法的问题是界面不够友好，将验证放在 Web 服务器这一层会有所局限，账号权限也不在 Web 服务器这层区分，Web 服务器只做用户认证工作。通常 Web 服务器只根据本机的配置信息进行验证，在做分布式处理时显得比较吃力，虽然像 Apache 也有 MySQL 的验证模组，但都不是默认配置，并且部署起来非常困难。
另一种则是基于 HTTPS 的安全连接，需要证书、公钥、私钥等，使用复杂，需要专门申请证书并安装等，通常只见于和银行有关的网站服务。
比较常见的方法是采用 Cookies 或 Session 记录用户认证的登录信息，每次通过 Session 提交到服务器进行对比。该方法则只利用 Web 服务器最基本的 Cookies 支持，一般需要自己编写专门的 Session 及 Authe 程序用于账号注册、管理、登录等程序。
上面这种方法兼容性相对来说还不错，但并不是最好的，更旧的或某些特殊的浏览器，甚至连 Cookies 都不支持，又或者是用户为了安全考虑，将 Cookies 功能禁止了，此时利用这种方法则会失效。还有一种情况Cookies解决不了，那就当跨域操作时，由于安全原因，Cookies 是无法继承过去的。
为了解决这些问题，有一种方法可以解决，就是在 CGI 程序的 QUERY_STRING 环境变量增加 Session 值，如 abc.cgi?a=a1&b=b1&session=898e82c94d7703e96f7ea83b
权限控制方面，复杂程度将根据业务逻辑去设计，一般会有管理、普通、访客等三种角色，进一步的则用组去划分权限。
最复杂，也是目前我最欣赏的是 Yahoo! ID 及 Microsoft Passport，他们的兼容性从一开始到扩展 N 多的业务，都能一脉相承。特别是 Yahoo! ID 收购了数十个公司，依然能做到这一点，在中国到目前为止尚没有一家公司能做到。
Yahoo! ID 的方法不算复杂，有个中心验证服务器。各种应用服务器遇到需要验证的情况时，将应用服务器的信息附在 URI 上，先重定向到中心验证服务器，验证通过后再重定向回应用服务器。
中心验证服务器是用 LDAP 实现的，只保留有最简单及核心的隐私资料，各种应用服务器需要的信息，在首次使用时，会进行一次初始化，补充一些个人信息和功能设置等。
我们 DWS 的验证问题虽然没有和 Yahoo! ID 要求的那么复杂，但是他是最值得我们借鉴的对象，Web 服务器的验证为了是控制远程用户的认证，内部的认证则可以理解为 Passport 的验证，一个账号登录后，在各个子域（或应用）间跳转时，无需再次登录，继承账号登录信息，但是并不继承权限，各有各的权限管理。
（注：本文于2005年12月27日发布在 W3G 内部开发 BLOG
中）
喜欢
0
赠金笔
前一篇：愚人节引起的悲剧