转载

互联网系统应用安全控制

编辑推荐:

本文来自于csdn，互联网安全一直是个重要问题，怎么做好安全是也相信大家在不断的努力中，文章简单的介绍，希望让大家有个新的认识。

在 Web 应用开发中，安全一直是非常重要的一个方面。面向互联网公网的接口服务，如果不加防护会导致数据泄露和商业风险。应用的安全性包括用户认证（Authentication）和用户授权（Authorization）两个部分。用户认证指的是验证某个用户是否为系统中的合法主体，也就是说用户能否访问该系统。用户认证一般要求用户提供用户名和密码。系统通过校验用户名和密码来完成认证过程。用户授权指的是验证某个用户是否有权限执行某个操作。简单来说，认证是指系统需要确认你是谁？而授权是指在通过认证之后，你能干什么？

核心概念

用户认证关键对象

Subject：主体，可以是用户，也可能是程序，都要去访问系统的资源，系统需要对subject进行身份认证。

Principal：身份信息，通常是唯一的，一个主题还有多个身份信息，但都有一个主身份信息（Primary Principal）。

Credential：凭证信息，可以是密码、证书、指纹。

用户授权关键对象

who：主题，即上文的subject

what：资源，resource，subject必须具备资源的访问权限才可访问资源。

how：权限/许可permission，针对资源的权限或许可，subject具有permission访问资源，如何访问需要定义permission。

常见的实现标准

Http常用认证方式

Http Basic认证：用户名密码按照格式“用户名:密码”通过Base-64编码，通过Authorization header传递到服务端，服务端解码成为“用户名:密码”格式进行认证。

Http Digest认证：当客户端第一次请求服务端资源时，服务端会返回一个随机数(nonce), 然后客户端会通过多次MD5加密来计算出来response的值 (response=MD5(HA1:nonce:HA2)), 其中HA1=MD5(username:realm:password), HA2=MD5(method:digestURI). 当服务端拿到这个response，那么它会从DB取出用户名密码来做同样的操作来看计算出来的response是否一致，如果一致，则表明认证通过。

Cookies & Session：在第一次登陆请求中传递用户名密码，服务端在校验结束后生成一个session-id，并将这个session-id和用户关联，然后通过http response的cookie header返回给客户端，客户端只需要存储这个cookie并在后续的请求都带上这个cookie就可以。

JWT（Json web token）：一种安全标准(RFC 7519)。服务器认证以后，生成一个 JSON 对象，发回给用户，用户与服务端通信的时候，都要发回这个 JSON 对象。服务器完全只靠这个合法签名的对象认定用户身份。

互联网常用授权理论

ACL: 控制访问列表(Access Control List) 。ACL是面向"资源"的访问控制模型，机制是围绕"资源"展开的。在ACL中，包含用户(User)、资源(Resource)、资源操作(Operation)三个关键要素。每一项资源，都配有一个列表，记录哪些用户可以对这项资源执行哪些操作。当系统试图访问这项资源时，会检查这个列表中是否有关于当前用户的操作权限。

RBAC: 基于角色的访问控制(Role-BasedAccess Control)。RBAC认为授权实际就是 who，what，how 三者之间的关系，即 who 对 what 进行 how 的操作。

OAuth2：OAuth是一个关于授权（authorization）的开放网络标准，目前的版本是2.0版。

基于角色的访问控制

RBAC认为权限的过程可以抽象概括为：判断“Who是否可以对What进行How的访问操作（Operator）”这个逻辑表达式的值是否为True的求解过程。即将权限问题转换为Who、What、How的问题。who、what、how构成了访问权限三元组。

RBAC的核心模型图如下：

互联网系统应用安全控制

RBAC的关注点在于 Role 和 User, Permission 的关系。称为 User assignment(UA) 和 Permission assignment(PA)。关系的左右两边都是 Many-to-Many 关系。就是 user 可以有多个 role，role 可以包括多个 user。User 通过成为 Role 而得到这些 Role 的 Permission，Role 隔离了 User 和 Permission 的逻辑关系。

实体关系图如下：

互联网系统应用安全控制

用户（user）：人、机器、网络等，进行资源或服务访问的实施主体

角色（role）：一个工作职能，被授予角色的用户将具有相应的权威和责任

会话（session）：从用户到其激活的角色集合的一个映射

权限（permission）：对受RBAC保护的一个或多个对象执行某个操作的许可

操作（operation）：一个程序可执行的映像，被调用时为用户执行某些功能

客体（object）：需要进行访问控制的系统资源，例如：文件、打印机、数据库记录等

某个主体（subject）对某个客体（object）需要实施某种操作（operation），系统对这种操作的限制就是权限控制。在一个安全的系统中，通过认证来确认主体的身份。客体是一种资源，是主体发起请求的对象。主体所能做什么，就是权限，权限可以细分为不同的能力，例如：在Linux文件系统中，将权限分为读、写、执行三种能力。

适用于RBAC模型的开源框架

Apache Shiro

Shiro是一个强大而灵活的开源安全框架，能够非常清晰的处理认证、授权、管理会话以及密码加密。Shiro在保持强大功能的同时，还在简单性和灵活性方面拥有巨大优势。Shiro对角色的简单的签权（访问控制），支持细粒度的签权；不跟任何的框架或者容器捆绑，可以独立运行。

互联网系统应用安全控制

Spring Security

Spring Security提供了一套 Web 应用安全性的完整解决方案。在用户认证方面，Spring Security 框架支持主流的认证方式，包括 HTTP 基本认证、HTTP 表单验证、HTTP 摘要认证、OpenID 和 LDAP 等。在用户授权方面，Spring Security 提供了基于角色的访问控制和访问控制列表（Access Control List，ACL），可以对应用中的领域对象进行细粒度的控制。

Apache Shiro VS Spring Security

除了不能脱离Spring，shiro的功能Spring Security都有。而且Spring Security对Oauth、OpenID也有支持,Shiro则需要自己手动实现。但Apache Shiro的学习难度要底很多，如果对Apache Shiro 和 Spring Security都不熟的团队，建议直接上手shiro。

OAuth2.0

OAuth 是一个在不提供用户名和密码的情况下，授权第三方应用访问 Web 资源的安全协议。例如一个 OAuth 场景：用户将照片存储在Google，然后在"云冲印"的网站，将照片冲印出来。那么，"云冲印"网站需要获得用户的授权来读取Google上的用户照片。

OAuth在"客户端"与"服务提供商"之间，设置了一个授权层（authorization layer）。“客户端"不能直接登录"服务提供商”，只能登录授权层，以此将用户与客户端区分开来。"客户端"登录授权层所用的令牌（token），与用户的密码不同。用户可以在登录的时候，指定授权层令牌的权限范围和有效期。

OAuth 的一些名词：

Third-party application：第三方应用程序，又称 “Client” 客户端

HTTP Service：HTTP服务提供商，上例中的Google

Resource Owner：资源所有者，就是用户

User Agent：用户代理，就是浏览器

Authorization server：认证服务器，即服务商提供商专门处理认证的服务器

Resource server：资源服务器，即服务提供商存放用户生成的资源的服务器

客户端必须得到用户的授权（authorization grant），才能获得令牌（access token）。OAuth 2.0定义了四种授权方式。

授权码模式（authorization code）

简化模式（implicit）

密码模式（resource owner password credentials）

客户端模式（client credentials）