自适应 MFA
GenAuth CAMFA 概述
什么是持续自适应 MFA？
持续自适应 MFA（Continuous Adaptive Multi-Factor Authentication，CAMFA） 是一种安全身份验证方法，它结合了多个身份验证因素（如密码、生物识别、硬件令牌等），并在用户的访问生命周期过程中，使用行为风险评估技术对用户的关键行为进行持续地实时动态评估，当触发风险时会通过调用 MFA 认证对用户当前状态进行确认，从而提高账号的安全性，更好地保护业务系统内的数据与资源安全。
持续自适应 MFA 的典型应用场景
- 你希望用户在他们经常登录的地理位置（国家/城市）无需触发 MFA，正常完成认证即可。但是当他们的账号在非常用地进行登录时，需要额外完成一次 MFA 才可以登录。
- 你希望企业成员在内网环境访问你的应用时，无需触发 MFA，正常完成认证即可。但是当他们在外网环境访问应用时需要额外完成一次 MFA 才可以登录。
- 你希望企业内用户在登录企业内部的应用时，可以根据组织、角色等不同属性触发不同的 MFA，例如财务部门的成员登录时需要进行手机号短信验证，人事部门的成员登录时需要进行 OTP 验证。
- 你希望用户在访问你的应用时，如果某个 IP 在短时间内连续登录多个应用或者连续登录失败，那么这个 IP 需要做一次 MFA 验证才能继续登录
总之，持续自适应 MFA 适用于你的应用希望能够通过持续监测用户行为，根据用户行为风险有针对性的进行 MFA 验证的相关场景。
GenAuth 持续自适应 MFA 的核心特点
GenAuth 持续自适应 MFA，依托于 GenAuth 身份自动化的编排能力，基于事件驱动的方式，能够基于用户属性、用户实行行为特征灵活编排安全策略，持续监测用户访问过程中的风险，设置触发多种 MFA。在确保用户体验的同时，有效提升认证与资源访问场景的安全性。
GenAuth 持续自适应 MFA 具备以下特性：
- 多种接入使用方式：你可以通过多种方式为你的应用接入 GenAuth 持续自适应认证的能力。目前支持通过 GenAuth Guard/GenAuth 应用网关/GenAuth MFA 组件的方式为你的应用提供持续自适应 MFA 能力
- 多源行为数据上报：持续自适应 MFA 可以接入多种场景和多个应用系统的用户行为数据，包括设备特征、网络环境、行为类型等等，如果你是基于 GenAuth MFA 组件接入还可以完全自定义用户行为数据
- 可视化编排安全策略：你可以通过工作流可视化地灵活编排不同应用的 MFA 安全策略，策略可以基于多种用户属性、行为特征、风控指标进行编排，支持多个策略分支，不同策略触发不同的 MFA
- 多种 MFA 验证方式：GenAuth 持续自适应认证支持多种认证方式，包括手机号短信验证/电子邮箱验证/OTP 验证/人脸识别验证
- 开发者友好：提供 SDK 与开放接口，助力开发者快速调用相关能力。
如何接入 GenAuth CAMFA？
目前 GenAuth CAMFA 功能仅面向内测客户开放，如需获取内测资格可以联系你的商务顾问或者在线联系我们
更多功能了解请参考
- 基于 GenAuth Guard 登录组件接入 MFA
- 改造已有的 IAM/IDaaS/认证系统接入 GenAuth 自适应 MFA 能力
- 进阶 MFA：Continuous Adaptive Multi-Factor Authentication (CAMFA) 指南
基于 GenAuth Guard 接入 GenAuth 持续自适应 MFA
我们将默认以下情况是您当前的目标和现状，我们将为您提供最佳的解决方案
目标：在自研应用或者有代码修改权限的应用中，快速上线 MFA 与安全策略防护能力、提升业务访问安全、提高用户体验、支持多元化业务场景、降低企业管理成本
现状：当前系统 MFA 能力较弱
解决方案：接入 GenAuth Guard 认证组件，快速接入登录及安全策略能力
什么是 GenAuth Guard？
GenAuth Guard 是一种由 GenAuth 提供的安全可靠的身份验证和授权服务，可以帮助企业和开发人员快速构建安全可靠的应用程序和服务，提高用户体验和保护用户的身份和信息安全。 GenAuth Guard 使用行业最佳实践安全性设计，仅需要几行 JavaScript 代码就可以集成到你开发的项目中。它可以直接从 CDN 或 NPM 加载，也可以从源代码构建。GenAuth Guard 同时提供 Javascript 原生、React、Vue 和 Angular 的多种集成模式，在你的任何项目中都可以无缝集成并享有高度自定义灵活性。 更加详细的介绍请见 接入 GenAuth Guard。
通过 GenAuth Guard 登录组件接入 MFA 的整体流程
Step 1. 创建 GenAuth 应用
你需要先在 GenAuth 创建一个应用。进入控制台 > 应用，点击右上角的「创建自建应用」。 
认证地址填写一个域名，必须为合法的域名格式，例如 my-awesome-app，作为这个应用在 GenAuth 的唯一标识。 
详细配置可参考：https://docs.authing.cn/v2/guides/app-new/
Step 2. 基于 GenAuth 应用配置自适应 MFA
- 进入控制台 (opens new window) >点击应用详情 >点击高级配置，开启自定义本应用的安全规则。
- 在应用详情中点击安全管理，找到多因素认证模块，点击高级模式，可以看到 MFA 安全策略编排的工作流。
- 你可以在工作流节点中配置触发 MFA 的相关策略以及触发的 MFA 方式。目前支持基于用户的角色、用户组属性，用户的最近一次访问城市、常用访问城市的属性进行策略配置。
- 除了针对每个应用配置你也可以针对用户池的所有应用配置全局的持续自适应 MFA 安全策略。你可以点击控制台的安全设置 >点击多因素认证，再点击高级模式，即可看到并配置用户池全局的 MFA 安全策略编排的工作流。所有没有开启安全设置的应用都将继承全局的策略配置。
Step 3. 接入 GenAuth Guard SDK 实现 MFA
GenAuth Guard 是一种轻便的认证组件，你可以把它嵌入在你任何的通过浏览器进行用户交互的应用中，一站式处理复杂的用户认证流程。MFA 是 Guard 组件中的模块，在您的项目中接入 GenAuth Guard 即可使用 MFA 能力。
第一步：安装并初始化 Guard（浏览器加载）
首先，在你的 HTML 文件中使用 script 和 link 标签直接引入文件，并使用全局变量 GuardFactory
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8" />
<meta http-equiv="X-UA-Compatible" content="IE=edge" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<title>Authing Guard Demo</title>
<script src="https://cdn.authing.co/packages/guard/5.1.5/guard.min.js"></script>
<link rel="stylesheet" href="https://cdn.authing.co/packages/guard/5.1.5/guard.min.css" />
</head>
<body>
<div id="authing-guard-container"></div>
<!-- 引入 Guard -->
</body>
</html>第二步：获取 Guard 实例（CDN）
// 代码示例：https://github.com/Authing/Guard/blob/master/examples/guard/normal/embed.html
const guard = new GuardFactory.Guard({
// 你可以前往 Authing 控制台的本应用详情页查看你的 App ID
appId: "AUTHING_APP_ID",
// 如果你使用的是私有化部署的 Authing 服务，需要传入自定义 host，如:
// host: 'https://my-authing-app.example.com',
// 默认情况下，会使用你在 Authing 控制台中配置的第一个回调地址为此次认证使用的回调地址。
// 如果你配置了多个回调地址，也可以手动指定（此地址也需要加入到应用的「登录回调 URL」中）：
// redirectUri: "YOUR_REDIRECT_URI"
});
console.log("guard instance: ", guard);如需了解更多安装方法请 Web Guard
更多功能了解请参考
- GenAuth Adaptive MFA 概述
- 改造已有的 IAM/IDaaS/认证系统接入 GenAuth 自适应 MFA 能力
- 进阶 MFA：Continuous Adaptive Multi-Factor Authentication (CAMFA) 指南
改造已有的 IAM/IDaaS/认证系统接入 GenAuth 自适应 MFA 能力
我们将默认以下情况是您当前的目标和现状，我们将为您提供最佳的解决方案
目标：增强现有系统的登录认证安全性、保护企业的敏感数据和应用程序、同时提高用户体验 现状：已有的 IAM/IDaaS/ 认证系统主要是自研或第三方开发，安全能力较弱或 MFA 不具备动态自适应感知能力（例如办公设备切换、办公网络变更能自动唤起 MFA）。它们通常支持多种身份验证方式，例如用户名 / 密码、社交账号登录、手机验证码等。然而，这些系统仍然存在一些问题，例如密码泄露、社交账号被盗等。 解决方案：接入 GenAuth 安全策略引擎及 MFA 组件，快速提升安全感知能力
改造已有的 IAM/IDaaS/认证系统接入 GenAuth 自适应 MFA 能力的整体流程
Step 1. 创建 GenAuth MFA 应用
你需要先在 GenAuth 创建一个 MFA 应用。进入控制台 (opens new window)> 应用，点击右上角的「添加应用」。
Step 2. 基于 GenAuth 应用配置自适应 MFA
进入控制台 > 应用 >点击应用详情 >点击安全管理，找到多因素认证因子配置界面如下（点击对应开关即可启用认证因子）： 
自适应 MFA 认证策略底层基于 GenAuth UEBA，可以针对用户行为和用户画像进行深度梳理分析，从而自动选择与当前行为相匹配的 MFA 策略。 在自适应 MFA 认证策略中，GenAuth UEBA 引擎会根据用户的行为和画像进行分析和判断，例如用户的登录历史、设备信息、IP 地址、地理位置、活动模式等等，从而确定当前用户的身份和风险级别，并选择与之相匹配的 MFA 策略。
Step 3. 改造已有的 IAM/IDaaS/认证系统接入 GenAuth 自适应 MFA 能力
假定您的系统具有一个相对简单的登录认证流程，我们会据此为您展示如何一步一步为简单的登录认证流程添加 GenAuth 自适应 MFA 安全策略认证能力
我们为您推荐的改造已有系统接入 GenAuth 自适应 MFA 方案
以下是交互时序图 
客户端改造方案
- 在代码中安装 GenAuth MFA SDK, GenAuth SDK 并引入 AuthinMFA, MetadataClient
- 使用 MetadataClient 获取当前系统中的用户行为数据，如 IP、浏览器等信息
- 改造原有登录认证接口，传输用户行为数据到系统后台
- 判断当前是否需要 MFA 认证
- 如果需要进行 MFA，使用后端接口返回的 MFA trigger data 和 AuthinMFA 拉起 MFA 认证流程，进行 MFA 认证
- 根据 MFA 认证结果，决定是否认证通过。如果认证通过，记录用户登录状态，跳转到业务系统；如果认证不通过，显示错误提示，返回登录页面 服务端改造方案
- 在代码中安装 GenAuth SDK，引入 AuthenticationClient、MetadataManagementClient，并进行初始化
- 改造登录接口接收并携带认证状态上报用户行为数据到 GenAuth 系统
- 用户行为数据上报后，如果用户一次认证通过后，调用 GenAuth 安全策略引擎计算本次认证是否触发 MFA
- 如果触发 MFA，将本次进行 MFA 的 trigger data 返回给客户端；如果不进行 MFA，则验证通过
服务端改造方案
- 在代码中安装 GenAuth SDK，引入 AuthenticationClient、MetadataManagementClient，并进行初始化
- 改造登录接口接收并携带认证状态上报用户行为数据到 GenAuth 系统
- 用户行为数据上报后，如果用户一次认证通过后，调用 GenAuth 安全策略引擎计算本次认证是否触发 MFA
- 如果触发 MFA，将本次进行 MFA 的 trigger data 返回给客户端；如果不进行 MFA，则验证通过
- 客户端收到 MFA 认证结果后，获取到 MFA 认证 Token，使用 MFA 认证 Token 请求 GenAuth 接口获取到 MFA 认证结果，如果认证通过，则记录用户登录状态，跳转到业务系统；如果认证不通过，则显示错误提示
以一个简单的应用系统登录代码示例，帮助您来理解如何进行对系统的逐步改造
我们假定您登录系统的客户端、服务端代码如下所示，它足够简单易于理解
客户端代码：
// 客户端代码示例
// 获取当前用户的用户名及密码
const username = form.username
const password = form.password
// 携带用户名及密码向服务端发起认证请求
const loginResult = clientLogin(username, password)
// 根据登录结果判断是否进行后续操作
if(loginResult.status) {
// 1. 记录登录状态
// 2. 跳转到业务系统
} else {
// 1. 界面提示认证失败
// 2. 返回登录界面
}服务端代码：
// 服务端代码示例
// 服务端登录认证方法
function login(username, password) {
// 查询当前认证用户
const user = db.findByUsername(username)
// 判断用户密码是否正确
if(user.password === md5(password)) {
return {
status: true,
token: jwt(user)
}
} else {
return {
status: false,
message: '账号或密码错误'
}
}
}Step 3.1 客户端代码改造示例
Step 3.1.1 安装并在代码中引入 GenAuth MFA SDK（用于拉起 MFA 前端界面）, GenAuth SDK（用于上报用户行为数据）
$ npm install authing-js-sdk
$ npm install @authing/mfaimport { MetadataClient } from 'authing-js-sdk'
import { AuthingMFA } from '@authing/mfa'
const appId = 'AUHTING_APP_ID'
const appSecret = 'AUHTING_APP_SECRET'
const authingMetadataClient = new MetadataClient()Step 3.1.2 使用 Metadata Client 获取当前系统中的用户行为数据，如 IP、浏览器等信息
Metadata Client 是 GenAuth 为客户提供的开箱即用的元数据快速生成工具包，帮助客户快速接入 GenAuth 元数据平台，它内置了 GenAuth 平台几十种内置元数据类型，关于 Metadata Client 的使用方法可以参考：元数据 SDK 使用文档,在本示例中主要用于上报用户行为数据
// load 方法采集客户端所在环境信息，以 json 存储，比如 IP、DeviceType(当前请求设备类型)、SystemType(当前操作系统类型)、BrowserType(当前请求浏览器类型) 等
const metadata = authingMetadataClient.authingUEBA.load()Step 3.1.3 改造原有登录认证接口，传输用户行为数据到系统后台
// 通过 login 接口将用户行为数据传到服务端
const loginResult = clientLogin(username, password, metadata)Step 3.1.4 判断当前是否需要 MFA 认证，如果需要进行 MFA，使用后端接口返回的 MFA trigger data 和 GenAuth MFA SDK 拉起 MFA 认证流程，进行 MFA 认证
// 判断服务端返回的登录结果、
if(loginResult.status) {
// 1. 登录成功记录登录状态
// 2. 跳转到业务系统
} else if(loginResult.mfaTriggerData){
// 使用 AuthingMFA SDK 拉起 MFA 认证流程
AuthingMFA(loginResult.mfaTriggerData).start().then(mfaToken => {
// mfaToken 为用户 MFA 后生成的 jwt token
// 可以使用 mfaToken 作为用户登录成功凭据，也可以基于当前 token 进行二次签发
})
} else {
// 5. 界面提示认证失败
}Step 3.1.5 根据 MFA 认证结果，决定是否认证通过。如果认证通过，记录用户登录状态，跳转到业务系统；如果认证不通过，显示错误提示，返回登录页面
// 使用 AuthingMFA SDK 拉起 MFA 认证流程
AuthingMFA(loginResult.mfaTriggerData).start().then(mfaToken => {
// 可以使用 mfaToken 作为用户登录成功凭据，也可以基于当前 token 进行二次签发
// 下面示例就是使用 mfaToken 进行二次签发的流程
const myToken = clientReIssueToken(mfaToken)
if(myToken) {
// 1. 记录登录状态
// 2. 跳转到业务系统
} else {
// 界面提示认证失败
}
})如果您选择使用 GenAuth mfaToken 作为用户认证 token，可参加如下代码
// 使用 AuthingMFA SDK 拉起 MFA 认证流程
AuthingMFA(loginResult.mfaTriggerData).start().then(mfaToken => {
// TODO 验证 token 合法性
// 可以使用 mfaToken 作为用户登录成功凭据，也可以基于当前 token 进行二次签发
if(myToken) {
// 1. 使用 mfaToken 记录登录状态
// 2. 跳转到业务系统
} else {
// 界面提示认证失败
}
}客户端改造后代码整体如下所示
import { MetadataClient } from 'authing-js-sdk'
import { AuthingMFA } from '@authing/mfa'
const appId = 'AUHTING_APP_ID'
const appSecret = 'AUHTING_APP_SECRET'
const authingMetadataClient = new MetadataClient()
// load 方法采集客户端所在环境信息，以 json 存储，比如 IP、DeviceType(当前请求设备类型)、SystemType(当前操作系统类型)、BrowserType(当前请求浏览器类型) 等
const metadata = authingMetadataClient.authingUEBA.load()
// 通过 login 接口将用户行为数据传到服务端
const loginResult = clientLogin(username, password, metadata)
// 判断服务端返回的登录结果、
if(loginResult.status) {
// 1. 登录成功记录登录状态
// 2. 跳转到业务系统
} else if(loginResult.mfaTriggerData){
// 使用 AuthingMFA SDK 拉起 MFA 认证流程
AuthingMFA(loginResult.mfaTriggerData).start().then(mfaToken => {
// 可以使用 mfaToken 作为用户登录成功凭据，也可以基于当前 token 进行二次签发
// 下面示例就是使用 mfaToken 进行二次签发的流程
// TODO SDK verify
const myToken = clientReIssueToken(mfaToken)
if(myToken) {
// 1. 记录登录状态
// 2. 跳转到业务系统
} else {
// 界面提示认证失败
}
})
} else {
// 5. 界面提示认证失败
}Step 3.2 服务端代码改造示例
Step 3.2.1 在代码中安装 GenAuth SDK，引入 AuthenticationClient、MetadataManagementClient，并进行初始化
$ npm install authing-js-sdkimport { MetadataManagementClient, AuthenticationClient } from 'authing-js-sdk'
const appId = 'AUHTING_APP_ID'
const appSecret = 'AUHTING_APP_SECRET'
const authingMetadataManagementClient = new MetadataManagementClient({appId, appSecret})
const authingAuthenticationClient = new AuthenticationClient({appId})Step 3.2.2 改造登录接口，接收并携带认证状态，上报用户行为数据到 GenAuth 系统
const authingUEBA = authingMetadataManagementClient.authingUEBA
// 用户登录接口
function login(username, password, metadata) {
// 查询当前认证用户
const user = db.findByUsername(username)
const loginStatus = user.password === md5(password)
// 携带认证状态上报用户行为数据到 Authing 系统
const clientUEBAMetadata = metadata
const UEBAMetadata = await authingUEBA.capture({
...clientUEBAMetadata,
loginStatus
})
// 如果认证失败，直接返回错误即可
if(!loginStatus) {
return {
status: false,
message: '账号或密码错误'
}
}
}为什么要通过业务系统服务端转发用户行为数据
数据传到服务器是为了让数据更加安全、避免数据泄露、滥用和随意修改，同时也方便对数据持久化、确保数据不会丢失，同时也方便对数据进行处理、更好的挖掘数据的价值，以及支持数据共享、给其他应用程序或者设备使用。Step 3.2.3 调用 GenAuth 安全策略引擎计算本次认证是否触发 MFA
// 元数据上传成功后，调用认证侧 MFA 工作流（规定每个应用特定的 MFA 工作策略 Id 和 采集的元数据信息，得到元数据分析结果
const mfaTriggerData = authingAuthenticationClient.triggerWorkflow({
'workflowId': 'xxx',
'metadata': clientUEBAMetadata,// 用户所绑定 UEBA 元数据格式的数据
})Step 3.2.4 如果触发 MFA，将本次进行 MFA 的 trigger data 返回给客户端；如果不进行 MFA，则验证通过
const mfaTriggerData = authingAuthenticationClient.MFA.triggerWorkflow({
'workflowId': 'xxx',
'metadata': clientUEBAMetadata,// 用户所绑定 UEBA 元数据格式的数据
})
if(mfaTriggerData) {
return {
status: false,
mfaTriggerData: mfaTriggerData
}
} else {
return {
status: true,
token: jwt(user)
}
}Step 3.2.5 添加全新接口，校验 MFA token 有效性，根据校验结果重新签发用户 Token
// MFA verify 接口
function clientReissueToken(mfaToken) {
const mfaRes = authingAuthenticationClient.verify(userId,mfaToken)
// 如果 mfaToken 校验成功
if(mfaRes.status) {
return {
status: true,
}
} else {
// 如果 mfaToken 校验失败，则返回失败信息
return {
status: false,
message: mfaRes.message
}
}
}服务端改造后代码整体如下所示
import { MetadataManagementClient, AuthenticationClient } from 'authing-js-sdk'
const appId = 'AUHTING_APP_ID'
const appSecret = 'AUHTING_APP_SECRET'
const authingMetadataManagementClient = new MetadataManagementClient({appId, appSecret})
const authingAuthenticationClient = new AuthenticationClient({appId})
const authingUEBA = authingMetadataManagementClient.authingUEBA
// 用户登录接口
function login(username, password, metadata) {
// 查询当前认证用户
const user = db.findByUsername(username)
const loginStatus = user.password === md5(password)
// 携带认证状态上报用户行为数据到 Authing 系统
const clientUEBAMetadata = metadata
const UEBAMetadata = await authingUEBA.capture({
...clientUEBAMetadata,
loginStatus
})
// 如果认证失败，直接返回错误即可
if(!loginStatus) {
return {
status: false,
message: '账号或密码错误'
}
}
// 元数据上传成功后，调用认证侧 MFA 工作流（规定每个应用特定的 MFA 工作策略 Id 和 采集的元数据信息，得到元数据分析结果
const mfaTriggerData = authingAuthenticationClient.triggerWorkflow({
'workflowId': 'xxx',
'metadata': clientUEBAMetadata,// 用户所绑定 UEBA 元数据格式的数据
})
if(mfaTriggerData) {
return {
status: false,
mfaTriggerData: mfaTriggerData
}
} else {
return {
status: true,
token: jwt(user)
}
}
}
// MFA verify 接口
function verifyMFA(mfaToken) {
const mfaRes = authingAuthenticationClient.verify(mfaToken)
// 如果 mfaToken 校验成功
if(mfaRes.status) {
// 取出 mfaToken 包含的 Id 信息
const { originalIdentity } = mfaRes.data
// 根据 Id 查询所包含的用户，如果用户存在则返回 Token 封装
const user = db.findByUsername(originalIdentity)
return {
status: true,
token: jwt(user)
}
} else {
// 如果 mfaToken 校验失败，则返回失败信息
return {
status: false,
message: mfaRes.message
}
}
}更多功能了解请参考
- GenAuth Adaptive MFA 概述
- 基于 GenAuth Guard 登录组件接入 MFA
- 进阶 MFA：Continuous Adaptive Multi-Factor Authentication (CAMFA) 指南
进阶 MFA：Continuous Adaptive Multi-Factor Authentication (CAMFA) 指南
目标：提高用户体验和安全性、通过智能化降低企业成本 现状：自研系统无 MFA 或者 MFA 功能较弱且急需多场景（例如资源访问、设备新增、信息变更）调用 MFA 解决方案：接入 GenAuth 进阶 MFA 组件，快速实现多场景调用
什么是持续自适应多因素认证
持续自适应多因素认证（Continuous Adaptive Multi-Factor Authentication，CAMFA）是一种安全身份验证方法，它结合了多个身份验证因素（如密码、生物识别、硬件令牌等），并使用实时风险评估技术对用户进行动态评估，从而提高安全性。
如何配置持续自适应多因素认证
Step 1. 创建 GenAuth MFA 应用
你需要先在 GenAuth 创建一个 MFA 应用。进入控制台 (opens new window)> 应用，点击右上角的「添加应用」。
Step 2. 基于 GenAuth 应用配置自适应 MFA
进入控制台 > 应用 >点击应用详情 >点击安全管理，找到多因素认证因子配置界面如下（点击对应开关即可启用认证因子）：
自适应 MFA 认证策略底层基于 GenAuth UEBA，可以针对用户行为和用户画像进行深度梳理分析，从而自动选择与当前行为相匹配的 MFA 策略。 在自适应 MFA 认证策略中，GenAuth UEBA 引擎会根据用户的行为和画像进行分析和判断，例如用户的登录历史、设备信息、IP 地址、地理位置、活动模式等等，从而确定当前用户的身份和风险级别，并选择与之相匹配的 MFA 策略。
Step 3. 从业务系统后端上报 UEBA 数据到 GenAuth 系统
您需要在您的服务端系统中引入 GenAuth SDK，并使用 MetadataManagementClient 将用户行为数据上报到 GenAuth 系统，具体操作流程如下：
Step 3.1 安装 GenAuth SDK
npm install authing-js-sdkStep 3.2 初始化 MetadataManagementClient
import { MetadataManagementClient } from 'authing-js-sdk'
const appId = 'AUHTING_APP_ID'
const appSecret = 'AUHTING_APP_SECRET'
const authingMetadataManagementClient = new MetadataManagementClient({appId, appSecret})Step 3.3 获取用户行为数据，并将用户行为数据上报到 GenAuth 系统
// 获取用户行为数据信息
const userUEBAData = getUserUEBAFromRequest(req)
// 将用户行为数据上报到 Authing 系统
const UEBAMetadata = authingMetadataManagementClient.authingUEBA.capture(userUEBAData)GenAuth 提供更多友好方式获取用户行为信息，请参考 「MetadataClient」GenAuth MFA Quick Start
为什么要通过业务系统服务端转发用户行为数据
数据传到服务器是为了让数据更加安全、避免数据泄露、滥用和随意修改，同时也方便对数据持久化、确保数据不会丢失，同时也方便对数据进行处理、更好的挖掘数据的价值，以及支持数据共享、给其他应用程序或者设备使用。Step 4. 配置持续自适应 MFA 安全策略流并发布安全事件
Step 5. 订阅安全策略流发布的事件
持续自适应安全策略需要您的客户端对 MFA 事件进行持续监听，当接收到 MFA 事件后，进行实时的响应，具体流程如下所示
Step 5.1 在服务端安装 GenAuth SDK
$ npm install authing-js-sdk
$ npm install @authing/mfaStep 5.2 初始化 AuthenticationClient
import { AuthenticationClient } from 'authing-js-sdk'
import { AuthingMFA } from '@authing/mfa'
const appId = 'YOUR_APP_ID'
const authingAuthenticationClient = new AuthenticationClient({appId})Step 5.3 订阅 MFA 事件，使用 MFA trigger data 和 AuthingMFA 拉起 MFA 认证流程，进行 MFA 认证
// 订阅 MFA 事件，通过 Authing 会自动添加当前用户 MFA 状态 check logic
authingAuthenticationClient
.MFA
.subscribe('authing.security.mfa?originalIdentity=originalIdentityexternalid',
mfaTriggerData => {
// 使用 AuthingMFA SDK 拉起 MFA 认证流程
AuthingMFA(mfaTriggerData).start().then(mfaToken => {
// mfaToken 为用户 MFA 后生成的 jwt token
// 可以使用 mfaToken 作为用户登录成功凭据，也可以基于当前 token 进行二次签发
})
})Step 5.4 根据 MFA 认证结果，决定是否认证通过。如果认证通过，记录用户登录状态，跳转到业务系统；如果认证不通过，显示错误提示，返回登录页面
// 使用 AuthingMFA SDK 拉起 MFA 认证流程
AuthingMFA(mfaTriggerData).then(mfaToken => {
// 可以使用 mfaToken 作为用户登录成功凭据，也可以基于当前 token 进行二次签发
// 下面示例就是使用 mfaToken 进行二次签发的流程
const myToken = clientReIssueToken(mfaToken)
if(myToken) {
// 1. 记录登录状态
// 2. 跳转到业务系统
} else {
// 界面提示认证失败
}
})如果您选择使用 GenAuth mfaToken 作为用户认证 token，可参加如下代码
// 使用 AuthingMFA SDK 拉起 MFA 认证流程
AuthingMFA(mfaTriggerData).start().then(mfaToken => {
// 可以使用 mfaToken 作为用户登录成功凭据，也可以基于当前 token 进行二次签发
if(myToken) {
// 1. 使用 mfaToken 记录登录状态
// 2. 跳转到业务系统
} else {
// 界面提示认证失败
}
})Step 6. 锁死当前用户后续所有业务操作，并拉起 MFA 验证
在发生 MFA 风险事件后，需要你改造你的后台系统针对存在 MFA 风险的用户进行限制操作，禁止后续请求
首先以一个简单的 express 后台系统代码进行示例，帮助您来理解如何修改您业务系统的代码
Step 6.1 初始化元数据管理端
import { MetadataManagementClient } from 'authing-js-sdk'
const appId = 'YOUR_APP_ID'
const authingMetadataManagementClient = new MetadataManagementClient({appId})Step 6.2 添加校验用户 MFA 状态的 express 中间件到服务端系统中
import express from 'express'
import { MetadataManagementClient } from 'authing-js-sdk'
const appId = 'YOUR_APP_ID'
const authingMetadataManagementClient = new MetadataManagementClient({appId})
const authingUEBA = authingMetadataManagementClient.authingUEBA
const mfaAuthMiddleware = (req, res, next) => {
// 获取 token 里面的用户 Id
const { myUserId } = utils.getUser(req.header.token)
// 检查用户 MFA 状态，需要传入用户 Id
const { mfaVerified } = await authingUEBA.checkUserStatus({ originalId: myUserId })
// 根据 MFA 状态来进行流程扭转
if(mfaVerified) {
// 客户进行下一步业务操作
next()
} else {
throw new UnauthorizedClientError()
}
}
const app = new express()
app.use(mfaAuthMiddleware)Step 7 设计容灾验证机制
Step 7.1 在刷新页面的场景下，保持 MFA 验证状态的持续存在
用户刷新页面后 GenAuth 会在安全策略订阅方法中自动查询当前用户 MFA 是否验证成功的状态，如果该状态为验证失败，自动执行当前订阅函数，建议开发者在订阅函数中实现 trigger MFA 方法，以下是具体代码示例：
Step 7.1.1 在服务端安装 GenAuth SDK
$ npm install authing-js-sdk
$ npm install @authing/mfaStep 7.1.2 初始化 AuthenticationClient
import { AuthenticationClient } from 'authing-js-sdk'
import { AuthingMFA } from '@authing/mfa'
const appId = 'YOUR_APP_ID'
const authingAuthenticationClient = new AuthenticationClient({appId})Step 7.1.3 订阅 MFA 事件，使用 MFA trigger data 和 AuthingMFA 拉起 MFA 认证流程，进行 MFA 认证
// 订阅 MFA 事件，通过 Authing 会自动添加当前用户 MFA 状态 check logic
authingAuthenticationClient
.MFA
.subscribe('authing.security.mfa?user=xxx',
mfaTriggerrData => {
// 使用 AuthingMFA SDK 拉起 MFA 认证流程
AuthingMFA(mfaTriggerData).start().then(mfaToken => {
// mfaToken 为用户 MFA 后生成的 jwt token
// 可以使用 mfaToken 作为用户登录成功凭据，也可以基于当前 token 进行二次签发
})
})Step 7.1.4 根据 MFA 认证结果，决定是否认证通过。如果认证通过，记录用户登录状态，跳转到业务系统；如果认证不通过，显示错误提示，返回系统登录页面
// 使用 AuthingMFA SDK 拉起 MFA 认证流程
AuthingMFA(mfaTriggerData).start().then(mfaToken => {
// 可以使用 mfaToken 作为用户登录成功凭据，也可以基于当前 token 进行二次签发
// 下面示例就是使用 mfaToken 进行二次签发的流程
const myToken = clientReIssueToken(mfaToken)
if(myToken) {
// 1. 记录登录状态
// 2. 跳转到业务系统
} else {
// 界面提示认证失败
}
})如果您选择使用 GenAuth mfaToken 作为用户认证 token，可参加如下代码
// 使用 AuthingMFA SDK 拉起 MFA 认证流程
AuthingMFA(mfaTriggerData).start().then(mfaToken => {
// 可以使用 mfaToken 作为用户登录成功凭据，也可以基于当前 token 进行二次签发
if(myToken) {
// 1. 使用 mfaToken 记录登录状态
// 2. 跳转到业务系统
} else {
// 界面提示认证失败
}
})Step 7.2 GenAuth 自动在 MFA 服务宕机时，实现对当用户放行的容灾机制
在 authingUEBA.checkUserStatus 方法中，GenAuth 会内置 MFA 服务监控流程，在 MFA 服务返回的结果异常时，总是针对当前用户 MFA 进行放行处理
更多功能了解请参考
自适应 MFA 编排/策略配置说明
通过模版创建自适应 MFA 安全编排
在身份自动化模块，点击新建工作流，找到“自适应 MFA 安全策略”模块，即可通过模板创建自适应 MFA 安全编排工作流。模版有两种模式：
- API 模式：适用于自适应 MFA 场景
- 事件流模式：使用于持续自适应 MFA 场景
通过模板创建后进入 MFA 安全编排-API 模式
MFA 安全策略-API 模式，是一个由 HTTP 请求、配置策略、执行策略引擎、返回触发 MFA 数据组成的安全编排流，用于自适应 MFA 场景，能够通过 HTTP 请求触发安全编排工作流，根据配置策略计算用户风险，并根据计算结果返回触发 MFA 数据
HTTP 请求
HTTP 请求作为 MFA 安全策略流的触发器，每当有新的 HTTP 请求产生时，就会触发该工作流
配置策略
在配置策略节点中，你可以引用 GenAuth 预置的策略编排函数，也可以创建新的自定义策略编排函数，然后引用它。策略编排函数能够接收前序节点 UEBA 变更事件的输入数据，灵活定义算法策略，并输出配置的相应返回值，给到后续节点执行策略引擎使用
执行策略引擎
在执行策略引擎节点中，你可以装配配置策略中引用的自适应 MFA 安全策略的返回值，例如策略判定结果，然后配置条件表达式（或条件表达式的组合），实行策略判定的计算
返回触发 MFA 数据
当满足执行策略引擎节点的条件（组）时，就会进入返回触发 MFA 数据节点，在返回触发 MFA 数据节点中可以配置选择需要触发何种 MFA 认证方式，以及可以灵活配置自定义返回值
通过模板创建后进入 MFA 安全编排-事件流模式
MFA 安全策略-事件流模式，是一个由 UEBA 变更事件、配置策略、执行策略引擎、发布 MFA 事件组成的安全编排流，用于持续自适应 MFA 场景，能够持续订阅 UEBA 事件，根据配置策略计算用户风险，并根据计算结果发布特定 MFA 事件
UEBA 变更事件
UEBA 变更事件作为 MFA 安全策略流的触发器，每当有新的 UEBA 事件产生时，就会触发该工作流
配置策略
在配置策略节点中，你可以引用 GenAuth 预置的策略编排函数，也可以创建新的自定义策略编排函数，然后引用它。策略编排函数能够接收前序节点 UEBA 变更事件的输入数据，灵活定义算法策略，并输出配置的相应返回值，给到后续节点执行策略引擎使用
执行策略引擎
在执行策略引擎节点中，你可以装配配置策略中引用的自适应 MFA 安全策略的返回值，例如策略判定结果，然后配置条件表达式（或条件表达式的组合），实行策略判定的计算
发布 MFA 事件
当满足执行策略引擎节点的条件（组）时，就会进入发布 MFA 事件节点，在发布 MFA 事件节点中可以配置选择需要触发何种 MFA 认证方式，以及可以灵活配置自定义返回值
UEBA 数据对象模块配置
在使用 MFA 安全编排-事件流模式时，还需要在设置-数据对象管理中，创建 UEBA 的的数据对象模块 
具体的用户数据字段列表如下 
具体字段列表参考：
| 名称 | 对外标识符 | 解释 | 生成方式 |
|---|---|---|---|
| appId | 应用 ID | ||
| requestDate | 请求日期 | ||
| ip | ip | ||
| city | 请求城市 | 根据 IP 解析生成 | |
| province | 请求省份 | 根据 IP 解析生成 | |
| country | 请求国家 | 根据 IP 解析生成 | |
| ua | 用户代理 | ||
| deviceType | 设备类型 | 根据 UA 解析生成 | |
| systemType | 设备系统 | 根据 UA 解析生成 | |
| browserType | 浏览器 | 根据 UA 解析生成 | |
| originalIdentity | 用户唯一标识 | 用户在业务系统中的唯一标识 ID | 业务系统必传 |
| behaviorType | 行为类型 | 业务系统选传（推荐） | |
| behaviorResult | 行为结果 | 业务系统选传（推荐） | |
| resourcesType | 资源类型 | 用户操作的资源类型 | 业务系统选传（推荐） |
| actionType | 操作类型 | 用户对资源的操作类型 | 业务系统选传（推荐） |
| loginType | 认证方式 | 业务系统选传（推荐） | |
| someKey | 自定义字段 | 自定义字段 | 业务系统选传（推荐） |
配置自适应 MFA 安全策略
自适应 MFA 安全策略是一个由配置入参、数据过滤、数据统计、策略判定、配置返回值组成的安全策略流，用于自适应/持续自使用 MFA 场景，能够定义计算输入的参数，过滤数据、统计数据、进行策略判定，最终输出策略计算结果。自适应 MFA 安全策略可以被自适应 MFA 安全编排工作流引用，得到行为数据的策略计算结果，从而实现 MFA 的灵活编排
配置入参
配置入参节点可以灵活定义自适应 MFA 安全策略接收的参数与数据类型
数据过滤
数据过滤节点可以基于前序输入的数据，配置过滤条件，将符合条件的数据往后传递
数据统计
数据统计节点可以接受前序节点的数据后，配置数据统计条件，可以设置统计周期、统计字段和统计类型，并基于统计条件的配置输出统计结果
策略判定
策略判定节点可以基于前序节点输入的数据和数据统计的结果，可以配置策略判定条件，并基于策略判定的条件输出策略命中结果
配置返回值
配置返回值节点可以装配前序节点的输出结果，包括配置入参的数据字段、数据统计的统计结果、策略判定的策略结果，以及能够自定义任意返回值