| 编辑推荐: |
| 本文来自于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）
拍拍贷架构师杨波给了一个流程图来帮助判断什么样的场景下需要采用哪种OAuth2的workflow：
Spring Cloud Security
Spring Cloud Security提供了一组用于构建安全应用程序和服务的简单框架。基于Spring
Boot和Spring Security OAuth2，我们可以快速创建实现常见模式的系统，如单点登录、令牌刷新和令牌交换。
Spring Security VS Spring Cloud Security
Spring Security解决的是单体服务的授权认证问题，Spring Cloud Security解决的是分布式架构系统间授权问题。在使用Spring
Cloud Security OAuth2.0的微服务体系内部，依然需要使用Spring Security实现资源服务内的访问权限控制。
|
