在平台应用中可以集成及接入第三方应用，以下分两种方式分别说明
以简单链接方式接入第三方应用APP，还需在原有APP上进行登录操作。
1.1.1.1创建需要集成的应用
首先需要在平台后台管理端添加接入应用的企业及应用相关信息，如下图所示：
1.1.1.2应用审核
管理员可以在后端对新加入的应用进行审核，并可以对应用启动、停止、删除操作，如下图所示:
1.1.13APP端应用展示
用户登录并打开平台APP端，在应用里面就能看到该新加入的应用，并把该应用添加到首页应用中，然后在APP首页就能看到该应用
1.1.14打开APP链接
点击医生APP时，系统会判断当前APP是否被安装，如果没有被安装，则系统会自动寻找并安装，安装完成后，系统会根据注册时填写的链接直接打开，输入用户名和密码即可。
随着信息化建设的逐步深入，支撑业务的各种应用系统越来越多，每个应用系统对应特定的用户群体，因此每个应用系统都存储了自身的用户信息，包括登录信息、授权信息和用户基本信息。每个应用系统也都具有帐号管理、认证、授权功能。而这些应用系统的建立没有遵循统一的数据标准，数据格式和身份认证方式也各不相同。采用此认证方式，有效解决当前存在的应用繁多、重复操作、效率低下等信息化痛点；但是此种方式需采用第三方统一认证管理平台，会产生相应费用。
集中的身份认证、单点登录由SSO模块实现，通过构建集中用户认证中心，提供统一访问控制与安全管理，提供多种安全认证方式和功能，满足应用安全访问需求
- 统一入口进行认证
- 应用中不保存用户密码，认证集中在服务端
- 应用与联合认证通过API或协议进行认证协商
- Token完全由应用管理，可以避开同源策略
- Token 可以避免 CSRF 攻击，Token可以是无状态，可在多个服务间共享
- 客户端通过公钥加密token，服务端私钥解密，客户端登录成功后，服务端分配Session ID，客户端cookie中存放Token和Session ID
- 支持异构系统的单点登录集成，做到平台无关、语言无关。
- 能够同时支持B/S、C/S结构应用的单点登录集成。
- 与应用集成，不改变应用原有的架构，不在应用服务器上安装插件。
- 应用接入支持，满足现有应用集成的同时，为新应用的接入提供快速的接入集成方式。
- 支持端到端安全认证。用户在访问应用系统时，经过单点登录服务器的认证后，再到应用服务器端的整个链路都有认证和加密措施保障安全。但同时需要支持从加密通讯到非加密通讯的动态切换以保证应用的访问性能。
- 支持与强认证方式的集成，如主流的CA、RSA、Ukey、OAuth等方式。
- 对于同一个用户在不同系统中会使用不同ID的情况，也可以实现单点登录的功能。
- 支持对社交网络用户身份的联邦认证，如使用微信号、QQ号、微博帐号等可以登录对外开放的应用，采用主流的标准的认证协议如OpenID、SAML等。
- 支持基于windows AD域的桌面单点集成。
- 支持多种认证方式并存，依照预置的优先级进行处理。
- 支持移动设备的访问控制。
- 支持帐号密码复杂性规则的校验。
1.2.1.3.1认证场景
多因素融合认证提供丰富的API和SDK，满足应用、系统和设备的快速接入，基于OTP，内置支持数字令牌、二维码认证，可与第三方认证数字证书、RSA、短信及生物识别认证集成，提供专属手机APP，方便用户下载安装。
1.2.1.3.2认证特点
平台功能主要包括身份管理、权限分配、风险配置及认证调度等，其特点主要包括：
- 安全性高，成熟算法不依赖网络
- 安全在手机上，无需额外其它硬件
- 与认证中心集成，提供不同应用与用户角色强认证
- 快速部署，周期短，风险低
- 提供标准API接口，灵活集成各类应用
- 软认证调用方式，成本低，使用方便
1.2.1.3.3认证等级
对于认证等级的管理可以帮忙单位实现多级别认证方式效果，可以对用户设定不同等级的认证方式，也可以对应用设定不同等级的认证方式。
1.2.1.3.4认证方式
提供统一的强认证管理，为单位提供各种各样的多因素强认证方式，包括AD认证、LDAP认证、互联网认证（微信、QQ、微博、支付宝、淘宝、单位微信、钉钉、单位公众号）、互联网认证、移动端认证、生物识别（人脸、声纹）、其他认证方式（滑块等）
支持主流的强认证方式集成，包含但不限于以下方式：
- 动态口令OTP/RSA
- 二维码扫描（微信、钉钉、支付宝、QQ）
- 数字证书CA/USB-Key集成
- 指纹认证集成
- 短信验证码
- LDAP/AD域
- 人脸识别
- 指纹认证
我们基本把系统分为三大类：
第一类：支持标准的认证协议（OAuth2.0、SAML、CAS、OIDC、Redius）
第二类：不支持认证协议单可以改造的（建议改造成OAuth2.0）
第三类：既不支持也不能改造的
支持标准认证协议
基于OAuth验证模块，主要分为授权码、程序脚本、凭证及API集中形式，常见采用授权码进行认证集成，其集成的步骤如下：
- 在第三方登录服务提供者申请网站，获得clientID和秘钥；
- 配置应用集成身份管理平台；
- 在身份管理平台配置第三方登录验证模块。
该场景主要针对跨区域的情况下进行联邦认证，通常以IDP和SP方式实现认证互信。
CAS是Central Authentication Service的缩写，中央认证服务，一种独立开始指令协议。CAS 是 Yale 大学发起的一个开源项目，旨在为 Web 应用系统提供一种可靠的单点登录方法，CAS 在 2004 年 12 月正式成为 JA-SIG 的一个项目。CAS是开源的单位级单点登录解决方案。共包含两部分：CAS Server 和 CAS Client。CAS Server 需要独立部署，主要负责对用户的认证工作；CAS Client 负责处理对客户端受保护资源的访问请求，需要登录时，重定向到 CAS Server。所有与 CAS 的交互均采用 SSL 协议，确保，ST 和 TGC 的安全性。
CAS 包含两个部分： CAS Server 和 CAS Client。CAS Server 需要独立部署，主要负责对用户的认证工作；CAS Client 负责处理对客户端受保护资源的访问请求，需要登录时，重定向到 CAS Server。
CAS协议集成交互时序如下图：
部分商业软件（如金蝶、蓝凌），提供基于Cookie的轻量级第三方认证机制（LTPA），可以通过发布在Web Server上的联合认证平台 SSO服务提供给支持LTPA的应用系统，为客户机提供单点登录功能。当用户登录联合认证平台 SSO认证时，系统自动通过Web Server资源的LTPA认证。用户认证成功后，WebServer代表用户生成LTPA Cookie。作为WebServer认证标记服务的LTPA Cookie中包含用户标识、密钥和标记数据、缓冲区长度以及到期信息等，这些信息使用金蝶或蓝凌厂商提供的相关支持LTPA认证的产品之间传输的信息受密码保护的密钥加密。在访问各产品时，浏览器发出的请求通过连接自动将LTPA Cookie信息发送至服务器，服务器接收请求、解密Cookie并基于Cookie中提供的标识信息来认证用户。
OpenID Connect是一个套的轻量级规范，提供通过RESTful APIs进行身份交互的框架。OpenID Connect简单的部署，允许所有类型的客户端，包括基于浏览器、移动设备、JavaScript客户端，请求和接收有关身份的信息、当前已验证的会话。这套规范的可扩展性，允许参与者选择，同样也支持加密的身份数据，发现OpenID提供者，和高级的会话管理，包括注销。
- OIDC协议特点
简单：登录一个支持 OpenID 的网站非常简单（即便你是第一次访问这个网站也是一样）。只需要输入你注册号的 OpenID 用户名，然后你登录的网站会跳转到你的 OpenID 服务网站，在你的 OpenID 服务网站输入密码（或者其它需要填写的信息）验证通过后，你会回到登录的网站并且已经成功登录。
安全：没有涉及到用户密钥等信息，更安全更灵活；
开放：OpenID 按照最大自由方式授权，使用它不需要任何费用任何注册或者许可证。
- OIDC协议集成交互时序图：
可改造为标准认证协议（建议OAuth2.0）
提供OAuth2.0改造API接口或SDK给到第三方，便于第三方进行快速改造。
1)应用集成SSO系统准备
应用系统(需要接入oauth认证的应用)准备认证成功回调地址：
| 属性名 | 说明 |
| redirect_uri | http://XXX.XXX.XXX.XXX/XX/XX |
2)向SSO系统申请注册应用系统并且提供跳转地址给SSO系统
SSO系统准备
环境配置
| 属性名 | 说明 |
| client_id | 1001 应用注册ID |
| client_secret | 1001 应用注册密码 |
| authorizeRequestUrl | http://10.0.10.8/esc-sso/oauth2.0/authorize 请求登陆认证地址 |
| tokenRequestUrl | http://10.0.10.8/esc-sso/oauth2.0/accessToken code交互token地址 |
| userinfoRequestUrl | http://10.0.10.8/esc-sso/oauth2.0/profile Token交互用户信息地址 |
应用需要在Demo环境地址注册（请问sso项目组索要client_id，client_secret）
OAuth2.0认证过程
下图为OAuth2.0认证交互过程图：
用户访问应用系统地址浏览器重定向请求到SSO的认证地址，并且提供相应的参.
OAuth完成用户认证，并为app提供token code。
浏览器跳转到app并提供code参数。
在获取code后，应用通过oauth2.0/accessToken用code换取访问token。
用户在获取访问token后，通过调用接口获取认证用户信息。
应用获取用户信息，认证完成，用户正常访问app。
URL示例：
| 属性名称 | 说明 | 是否必须 |
| client_id | 应用注册ID | 必须 |
| response_type=code | 属性常量 | 必须 |
| redirect_uri | 应用回调地址，需要http格式化 | 必须 |
| oauth_timestamp | 当前时间格式(1489739502583) | 必须 |
SSO系统通过redirect_uri浏览器重定向请求反馈code给应用：
URL示例
http://XXXX.XXXX.XXXX.XXXX/XXX/XXX?code=123456abcdef
获取参数：
| 属性名称 | 说明 | 是否必须 |
| Code | 交互token验证码 | 必须 |
注意：一次性消耗，交互一次token，code就失效，需要认证中心重新产生。
应用获取的code，跟认证中心交互获取token，使用http方式请求token接口
URL示例
http://10.0.10.8/esc-sso/oauth2.0/accessToken?grant_type=authorization_code&oauth_timestamp=1489739169232&client_id=1001&client_secret=1001&code=b87576e1-fd14-47e5-a835-0d601b18387a&redirect_uri=http%3A%2F%2FXX.XXX.XXX.XXX%3A8080%2FXXX%2FXXXX
请求参数：
请求方式：post或者get
请求协议：http协议
| 属性名称 | 说明 | 是否必须 |
| grant_type=authorization_code | 属性常量 | 必须 |
| oauth_timestamp | 当前时间格式(1489739502583) | 必须 |
| client_id | 应用注册ID | 必须 |
| client_secret | 应用注册密码 | 必须 |
| code | 接受到的code值 | 必须 |
| redirect_uri | 应用回调地址,需要http格式化 | 必须 |
返回参数：
| 属性名称 | 说明 | 是否必须 |
| token | 返回的值（a855d95f1974） | 必须 |
解析返回数据的到token，例如：a855d95f1974
URL示例：
http://10.0.10.8/esc-sso/oauth2.0/profile?access_token=b1d508f3-32e7-4d6d-ac62-87836406704c
请求参数：
请求方式：post或者get
请求协议：http协议
| 属性名称 | 说明 | 是否必须 |
| access_token | 获取的token的值 | 必须 |
返回参数：
| 属性名称 | 说明 | 是否必须 |
| id | 用户登录的主账号 | 必须 |
| attributes->username | 从账号 |
解析返回数据得到用户信息,应用系统根据这个字段匹配自身平台的账号数据，让用户通过认证。
返回样例
{
"attributes": {
"token_expired": "7200",
"token_gtime": 1576654766940,
"username": "sysadmin"
},
"id": "sysadmin"
}
根据token，向认证中心校验是否有效
如果应用系统需要做统一注销，每次请求接口时，都需要跟sso平台校验token是否有效。具体接口如下：
URL示例：
http://10.0.10.8/esc-sso/api/v1/loginLog/checkAccessToken
请求参数：
请求方式：get
请求协议：http协议
| Headers属性名称 | 说明 | 是否必须 |
| accesstoken | 需要校验的token | 必须 |
返回参数：
成功
{
"errorCode":"0",
"errorMsg":"OK",
"version":"RSA1.0",
"timestamp":0,
"data":"sysadmin"
}
失败
{
"errorCode":"110",
"errorMsg":"access token invalid",
"version":"RSA1.0",
"timestamp":0
}
既不支持认证协议也不支持改造类系统
对此类系统采用Form Base方式进行单点，无需其他系统改造，方式如下：
基于表单的单点登录功能，允许ParaSecure ESC SSO将已认证的用户，透明地登录到需要通过HTML表单认证的后台系统中，具体的登录步骤可以参看下图：
Formbase单点登录访问时序说明图
利用这种实现单点登录的方式，ParaSecure ESC SSO需要把用户名和密码提交给后台的应用系统来完成认证工作，因此需要在ParaSecure ESC IdM中，维护一套SSO用户和后台应用系统中用户名/密码的对应关系表，
例如：
| SSO用户：zhangsan | ||
| 应用系统名 | 用户名 | 密码 |
| 应用系统A | Zhangsan | qwe123 |
| 应用系统B | Zhangs | qwe125 |
| 应用系统C | zhang_san | OAuth Token |
对于一些无法修改认证代码的应用，建议采用这种单点登录集成方式。
对于能够改造的应用，为保证安全性，采用表单代填的应用实现单点登录时，同样可基于OAuth标准，通过代填Token的方式实现单点登录，Token为一次性具有时效性，更加安全。
提供准入授权模式，即在联合认证平台中创建或者维护的用户，拥有自己能够访问的应用列表，这个应用访问是根据用户是否具备某个角色或者属于某个组织来决定，即用户只拥有能否访问应用系统的权限，至于在应用系统内部拥有的权限，需要应用管理员进行调整维护。此授权模式是目前使用最多的一种方式，具有维护简单、效果明显、易实现、支持全自动化管控，完全解放IT管理员在此处的工作量。得到了大多数单位用户的认可和选择。一般会在项目建设的第一阶段采用。
分级分权的授权管理
按照用户、组织、应用三个维度组合，设置分权分域管理员权限控制
授权管理控制主要通过逐级授权，分级的权限管理
1.2.1.6.3授权合规审计
- 系统级审计。系统级审计的内容主要包括登录（成功和失败）、登录识别号、每次登录尝试的日期和时间、每次退出的日期和时间、所使用的设备、登录后运行的内容（如用户启动应用的尝试，无论成功或失败）。典型的系统级日志还包括和安全无关的信息，如系统操作、费用记账和网络性能。
- 应用级审计。系统级审计可能无法跟踪和记录应用中的事件，也可能无法提供应用和数据拥有者需要的足够的细节信息。通常，应用级审计的内容包括打开和关闭数据文件，读取、编辑和删除记录或字段的特定操作以及打印报告之类的用户活动。
- 用户级审计。用户级审计的内容通常包括：用户直接启动的所有命令、用户所有的鉴别和认证尝试、用户所访问的文件和资源等方面。
- 权限合规安全审计。是通过对所关心的事件进行记录和分析来实现的，因此审计过程包括审计发生器、日志记录器、日志分析器和报告机制几部分，如图所示:
平台在现有安全认证的账号体系中，基于第三方平台消息推送解决方案的基础上，为用户提供一种更安全、私密、快捷的登录方式，推出我们自己的“一键免密登录”。相对于主流短信验证码的注册登录方式，用户手机端的一键登录方式能降低短信验证码被劫持的风险。用户通过手机端APP进行确认，能够保障用户的唯一性，降低账号使用安全风险。
1、用户在 PC 端登录页面，点击 “一键快捷登录” 按钮，触发手机一键登录；
2、此时用户在已经安装了App的手机会收到一条登录验证请求，用户只需要按照 PC 端提示打开App；
3、开启App，会弹出手机安全登录页面，点击“确认登录”按钮，执行一键登录；
4、此时用户可以看到 PC 端已经登录成功啦。
通过实现用户PC端登录与手机APP的协同配合，从而提高用户对密码的无感体验，提升用户登录操作的便捷性，最终实现用户身份确认与无密码认证的安全性保障。