4A系统

过去每个业务网系统常常各自维护一套用户信息数据，使得管理复杂且难以统一。且孤立地以日志形式审计操作者在系统内的操作行为，也使得审计过程变得繁琐和低效。因此，4A统一安全管理平台解决方案应运而生。它将不同应用、业务过程、后端系统、服务和信息、知识等内容集成到一个软件系统平台内，从而实现了账号管理、认证管理、授权管理和安全审计的集中化、统一化管理。提高了企业网络安全性、降低管理成本并强化系统安全性和政策符合性。

定义：

4A统一安全管理平台是一个以身份为中心，实现账号、认证、授权和审计统一管控的安全访问平台。它可为企业IT系统提供综合安全防护，其核心目的是提高系统的安全性、管理效率和用户访问的便捷性。其核心包括账号（Account）管理、认证（Authentication）管理、授权（Authorization）管理和安全审计（Audit）。通过集中的账号管理、身份认证、授权管理和安全审计等功能，为企业提供基于统一策略的解决方案，解决企业内控问题，降低管理成本，提高系统安全性和政策符合性。

其核心功能：

1. 统一账号: 提供统一的账号管理功能，支持主流的操作系统、网络设备和应用系统。包括帐号的全生命周期管理，如创建、删除及同步等，以及帐号密码策略、密码强度、生存周期的设定。
2. 统一认证: 根据用户应用的实际需要，提供不同强度的认证方式，如静态口令、双因子认证（一次性口令、数字证书、动态口令）等，且能够集成现有其他新型认证方式，如生物特征等。还可以实现用户认证的统一管理，提供统一的认证门户，实现信息资源访问的单点登录。
3. 统一授权: 集中管理系统资源和应用资源的权限，实现权限的统一、收集、变更、回收。
4. 统一审计: 全面记录用户的登录和操作行为，基于场景的异常行为分析，实现对大量日志的有效审计。

工作原理：

4A系统的工作原理主要围绕账号（Account）、认证（Authentication）、授权（Authorization）和审计（Audit）四个核心组件展开。首先，4A系统负责账号的全生命周期管理，包括账号创建、修改、删除等，及密码策略的制定和执行。这一环节确保了用户账号的规范性和安全性。其次，在认证阶段，4A系统通过采用多种认证方式（如静态口令、动态令牌、生物特征识别等），对用户身份进行验证，确保只有合法的用户才能访问系统。授权环节是4A系统的核心功能之一。它根据用户的角色和权限，为用户分配相应的访问和操作权限。通过细粒度的权限管理，4A系统能够实现对关键资源和敏感数据的保护，防止未经授权的访问和操作。最后，在审计环节，4A系统记录并分析用户的登录、操作等行为，为安全事件溯源和责任追究提供有力支持。同时，通过对审计数据的分析，企业可以及时发现潜在的安全风险，并采取相应的措施进行防范。此外，4A系统通常还具备与其他安全设备和系统的集成能力，如与防火墙、入侵检测系统（IDS）、安全事件管理系统（SIEM）等进行联动。

4A系统与堡垒机的区别与关系：

4A系统提供了一种集中统一的管理方式，侧重于身份管理，确保只有经过授权的用户才能访问系统资源。堡垒机，也被称为“跳板机”或“跳板服务器”，是一种网络安全设备。其主要功能是管理和监控访问计算机网络的用户，尤其是那些需要对关键系统进行管理或维护的人员。堡垒机具有访问控制、会话监控、远程管理和权限管理等功能，能够防止未经授权的访问和潜在的网络入侵，确保用户只能访问其工作需要的资源。堡垒机起源于旁路审计产品，通过接管终端对资源的访问，在审计的同时还能对操作命令进行细粒度管控，提供了资源运维统一入口，其本质是提供资源运维统一入口，侧重于运维和审计。从核心能力来看，4A对外输出的是身份和访问管理能力，堡垒机对外输出的是运维管控能力。在企业的网络安全架构中，4A系统主要负责对身份和访问进行统一管理，而堡垒机则作为能力组件，接收并执行4A系统制定的策略。

4A系统整体逻辑关系

单点登录

定义：

单点登录，又名：Single Sign On 简称SSO。简言之，单点登录就是在多个系统中，用户只需一次登录，各个系统即可感知该用户已经登录。例如当你成功登录淘宝后，你再登录天猫时就不需要再进行一次用户登录就能成功访问天猫的资源。

原理：

众所周知，HTTP是无状态的协议（HTTP 协议在设计上不记录客户端与服务器之间的交互状态），这意味着服务器无法确认用户的信息。例如：用户在网页 A 点击链接跳转到网页 B，服务器处理网页 B 的请求时，无法自动关联用户之前在网页 A 的操作。于是乎，W3C就提出了：给每一个用户都发一个通行证，无论谁访问的时候都需要携带通行证，这样服务器就可以从通行证上确认用户的信息。通行证就是Cookie。如果说Cookie是检查用户身上的”通行证“来确认用户的身份，那么Session就是通过检查服务器上的”客户明细表“来确认用户的身份的。Session相当于在服务器中建立了一份“客户明细表”。HTTP协议是无状态的，Session不能依据HTTP连接来判断是否为同一个用户。于是乎：服务器向用户浏览器发送了一个名为JESSIONID的Cookie，它的值是Session的id值。其实Session是依据Cookie来识别是否是同一个用户。

所以一般单点登录的做法就是：在登陆的时候，将用户信息保存在Session对象中，如果在Session对象中能查到，说明已经登录，如果在Session对象中查不到，说明没登录，在退出登陆的时候，从Session中删除用户的信息。以下面这段代码为例:

/** 用户登陆 **/
@PostMapping(value = "/user/session", produces = {"application/json;charset=UTF-8"})
public Result login(String mobileNo, String password, String inputCaptcha, HttpSession session, HttpServletResponse response) {
    //判断验证码是否正确
    if (WebUtils.validateCaptcha(inputCaptcha, "captcha", session)) {
        //判断有没有该用户
        User user = userService.userLogin(mobileNo, password);
        if (user != null) {
            /*设置自动登陆，一个星期.  将token保存在数据库中*/
            String loginToken = WebUtils.md5(new Date().toString() + session.getId());
            user.setLoginToken(loginToken);
            User user1 = userService.userUpload(user);
            session.setAttribute("user", user1);
            CookieUtil.addCookie(response,"loginToken",loginToken,604800);
            return ResultUtil.success(user1);
        } else {
            return ResultUtil.error(ResultEnum.LOGIN_ERROR);
        }
    } else {
        return ResultUtil.error(ResultEnum.CAPTCHA_ERROR);
    }
}
/**用户退出 **/
@DeleteMapping(value = "/session", produces = {"application/json;charset=UTF-8"})
public Result logout(HttpSession session,HttpServletRequest request,HttpServletResponse response ) {
    //删除session和cookie
    session.removeAttribute("user");
    CookieUtil.clearCookie(request, response, "loginToken");
    return ResultUtil.success();
}
/**
* @author ozc
* @version 1.0
* <p>
* 拦截器；实现自动登陆功能
*/
public class UserInterceptor implements HandlerInterceptor {
@Autowired
private UserService userService;
public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object o) throws Exception {
    User sessionUser = (User) request.getSession().getAttribute("user");
    // 已经登陆了，放行
    if (sessionUser != null) {
        return true;
    } else {
        //得到带过来cookie是否存在
        String loginToken = CookieUtil.findCookieByName(request, "loginToken");
        if (StringUtils.isNotBlank(loginToken)) {
            //到数据库查询有没有该Cookie
            User user = userService.findUserByLoginToken(loginToken);
            if (user != null) {
                request.getSession().setAttribute("user", user);
                return true;
            } else {
                //没有该Cookie与之对应的用户(Cookie不匹配)
                CookieUtil.clearCookie(request, response, "loginToken");
                return false;
            }
        } else {
            //没有cookie、也没有登陆。是index请求获取用户信息，可以放行
            if (request.getRequestURI().contains("session")) {
                return true;
            }
            //没有cookie凭证
            response.sendRedirect("/login.html");
            return false;
        }
    }
}
}

其代码逻辑为：用户登录时，验证用户的账户和密码；生成一个Token保存在数据库中，将Token写到Cookie中；将用户数据保存在Session中；请求时都会带上Cookie，检查有没有登录，如果已经登录则放行。

Cookie详解可看：介绍会话技术、Cookie的API、详解、应用

Session详解可看：Session介绍、API、生命周期、应用、与Cookie区别

HTTP详解可看：HTTP就是这么简单

由于单系统登录功能主要是用Session保存用户信息来实现的，但我们知道多系统即可能有多个Tomcat，而Session是依赖当前系统的Tomcat，所以系统A的Session和系统B的Session是不共享的。于是就有了单点登录，即把登录功能单独抽取出来，做成一个子系统。（单点登录系统SSO），当其他子系统登录时，请求SSO（登录系统）进行登录，将返回的token写到Cookie中，下次访问时则把Cookie带上。总结来说就是：

1. SSO系统生成一个token，并将用户信息存到Redis中，并设置过期时间；
2. 其他系统请求SSO系统进行登录，得到SSO返回的token，写到Cookie中；
3. 每次请求时，Cookie都会带上，拦截器得到token，判断是否已经登录。

这样就解决了session不能跨域的问题。

Cookie跨域的问题：

Cookie是不能跨域的，比如说，我们请求<https://www.google.com/>时，浏览器会自动把google.com的Cookie带过去给google的服务器，而不会把<https://www.baidu.com/>的Cookie带过去给google的服务器。即由于域名不同，用户向系统A登录后，系统A返回给浏览器的Cookie，用户再请求系统B的时候不会将系统A的Cookie带过去。

解决方法：

• 服务端将Cookie写到客户端后，客户端对Cookie进行解析，将Token解析出来，此后请求都把这个Token带上就行了
• 多个域名共享Cookie，在写到客户端的时候设置Cookie的domain。
• 将Token保存在SessionStroage中（不依赖Cookie就没有跨域的问题了）

到这里，我们已经可以实现单点登录了。

CSA：中央认证服务：

CSA：说到单点登录，就肯定会见到这个名词：CAS 中央认证服务（Central Authentication Service）。下面以一个具体的例子来说明其原理。现在我们有两个系统，分别是系统A：www.java3y.com和系统B：www.java4y.com，一个SSO系统：www.sso.com 。

首先，用户想要访问系统A www.java3y.com受限的资源(比如说购物车功能，购物车功能需要登录后才能访问)，系统A www.java3y.com发现用户并没有登录，于是重定向到sso认证中心，并将自己的地址作为参数。请求的地址如下：www.sso.com?service=www.java3y.com

sso认证中心发现用户未登录，将用户引导至登录页面，用户进行输入用户名和密码进行登录，用户与认证中心会建立全局会话（生成一份Token，写到Cookie中，保存在浏览器上）。随后，认证中心重定向回系统A，并把Token（或者叫服务票据service ticket）携带过去给系统A，重定向的地址如下：www.java3y.com?token=xxxxxxx。接着，系统A去sso认证中心验证这个Token是否正确并且询问当前用户在我系统中的权限是什么样子的，如果正确，则系统A和用户建立局部会话（创建Session）。到此，系统A和用户已经是登录状态了。

此时，用户想要访问系统B www.java4y.com受限的资源(比如说订单功能，订单功能需要登录后才能访问)，系统B www.java4y.com发现用户并没有登录，于是重定向到sso认证中心，并将自己的地址作为参数。请求的地址如下：www.sso.com?service=www.java4y.com 。注意，因为之前用户与认证中心 www.sso.com 已经建立了全局会话（当时已经把Cookie保存到浏览器上了），所以这次系统B重定向到认证中心 www.sso.com 是可以带上Cookie的。

认证中心根据带过来的Cookie发现已经与用户建立了全局会话了，认证中心就会重定向回系统B，并把Token携带过去给系统B，重定向的地址如下：www.java4y.com?token=xxxxxxx （这个过程与第一次转到认证中心是一样的，唯一区别就是不再需要进行用户登录）

接着，系统B去sso认证中心验证这个Token是否正确，如果正确，则系统B和用户建立局部会话（创建Session）。到此，系统B和用户已经是登录状态了。这就是整个CSA的流程。

（补充）出口IP：

机房的网络设备（如防火墙）给内网主机生成的一个外网IP，用来保证内网主机能和其他公网主机进行来回通信，通常作为其他接入方的IP白名单使用。一般有几台内网主机就有几个出口IP，出口IP通常和入口IP不一样！

出口方一般通过POST接口请求第三方，第三方可以通过程序获取远程主机IP来判断。

（补充）入口IP：

就是我们主机提供给别人访问的公网，即绑定域名的IP地址，通过ping域名即可获得。

当需要与第三方合作时，如果需要访问对方的服务，则一般需要告知对方我们的出口ip，方便对方进行访问授权。

当需要与第三方合作时，如果需要对方访问到自己的服务，则需要告知对方一个可访问的入口地址。并且授权对方的网络设备ip（对方的出口ip）允许访问我们的服务。

OAuth2.0

参考：https://juejin.cn/post/7234322338824650809#heading-3

OAuth是Open Authority的缩写，与SSO流程类似，在业务系统中都没有账号和密码。账号密码都存储在登录中心，在需要使用受限服务时使用令牌的方式来代替用户密码访问应用。OAuth2.0原理可能比较陌生，但平时应用的却很多，比如访问某网站想留言又不想注册时使用了微信授权。

OAuth 2.0授权框架支持第三方支持访问有限的HTTP服务，通过在资源所有者和HTTP服务之间进行一个批准交互来代表资源者去访问这些资源，或者通过允许第三方应用程序以自己的名义获取访问权限。以一个微信授权网页获取用户信息的例子：

• 用户在某网站上点击使用微信授权，这里的某网站就类似业务系统，微信授权服务器就类似单点登录系统
• 之后微信授权服务器返回一个确认授权页面，类似登录界面，这个页面当然是微信的而不是业务系统的
• 用户确认授权，类似填写了账号和密码，提交后微信鉴权并返回一个ticket，并重定向业务系统。
• 业务系统带上ticket访问微信服务器，微信服务器返回正式的token，业务系统就可以使用token获取用户信息了

OAuth 2.0实现的4种方式：授权码模式、隐藏式模式、密码式模式、客户端凭证模式。

1、授权码模式：用户访问第三方应用时，第三方应用前端会引导用户重定向到授权服务器，并提供自己的client id。当用户在授权服务器的身份验证成功后，会提示用户将颁发读权限给应用程序，再颁发一个授权码并引导用户重定向用户回到应用程序，应用程序把授权码和自己的client id返回程序后端，并由后端向认证服务器申请访问令牌/刷新令牌（access token/refresh token）。随后当后端获得token后，再使用token向资源服务器申请资源访问，而资源服务器拿到token后会对令牌进行解析校验，并向授权服务器校验其合法性，若合法则允许访问资源。

在整个过程中应用程序没有接触到用户的密码。访问令牌对于应用程序来说是透明的，但是资源服务器需要知道访问令牌的组成和加密方式，资源服务器需要解析或解密这个访问令牌，查看并校验里面的信息。且授权码与访问令牌不同，授权码只能用一次，而且会很快超时失效, 使得被截获后难以运用。所以这种方式是最常用的流程，安全性也最高，它适用于那些有后端的 Web 应用。授权码通过前端传送，令牌则是储存在后端，这种方式是最常用的流程，安全性也最高，它适用于那些有后端的 Web 应用。授权码通过前端传送，令牌则是储存在后端。而且所有与资源服务器的通信都在后端完成。这样的前后端分离，可以避免令牌泄漏。

2、隐藏式模式（简化模式）：有些 Web 应用是纯前端应用，没有后端。譬如说JavaScript应用。此时应用程序的运行完全暴露在用户的控制之中，在这种场景下，应用程序是无法隐藏自己的一些敏感数据，比如client secret和授权码，在这个方式下，再向授权服务器获取授权码是多此一举。于是这种模式在用户完成身份认证之后由授权服务器直接颁发一个访问令牌并重定向用户回到应用程序。（跳过了授权码这一步骤）这种方式把令牌直接传给前端，是很不安全的。因此，只能用于一些安全要求不高的场景，并且令牌的有效期必须非常短，通常就是会话期间（session）有效，浏览器关掉，令牌就失效了。

3、客户端凭证模式（应用授信模式）：这种授信模式特点是：应用程序角色本身就是资源所有者 （应用程序和资源服务器之间是完全可信的）。相当于就是第三方软件访问不需要资源拥有者授权的资源和数据，换句话说在这里客户端也可以看作是资源拥有者。举个例子来说就是第三方软件访问一些公共的服务，譬如说一些地图信息，logo图标等。应用程序直接向授权服务器申请访问令牌，告知申请资源的读权限，并提供自己的授信凭证（client id/secret），再由授权服务器返回token用于资源服务器的访问。

4、密码式模式（用户授信模式）：这个模式就是把用户名和密码直接交给应用程序，让应用程序去申请访问令牌。在这场景里面就不存在第三方软件这概念，相当于就是访问系统中的一个子系统，他们之间互相信任。举个例子来说就是，腾讯有许多的游戏，你只需要用qq账号密码就可以登录游戏玩，不需要进行腾讯授权。因为该游戏是腾讯旗下的，他们相互信任的，所以不存在第三方的说法。用户先在应用程序上输入用户名和密码，应用程序拿到资源所有者的用户名和密码，加上自己的client id/secret一同向认证服务器申请访问令牌/刷新令牌，应用程序拿到令牌后向资源服务器申请用户的资源信息，资源服务器在获取到访问令牌后，对令牌进行解析（解密）并校验，并向授权服务器校验其合法性

总结一下就是：(应用授信凭据指client id和secret，用户授信凭据则默认是用户名和密码。)

• 授权码模式：授权码+应用的授信凭据。它需要有四个角色同时在场才能完成授权：资源所有者、应用程序、授权服务器、资源服务器。
• 简化模式：应用client id + 用户的授信凭据。应用程序运行在公开开放的环境。即：无需应用程序的认证。
• 应用授信模式：应用的授信凭据。应用程序即为资源所有者，或资源所有者不参与授权交互。即：无资源所有者的认证。
• 用户授信模式：应用的授信凭据+用户的授信凭据。无授权码的颁发过程，直接通过用户名和密码换取授权。

具体各类访问示例参考：https://www.cnblogs.com/Chary/p/17940925