随着IT应用的不断深化与拓展，应用系统及APP逐渐增多，用户对应用系统及APP的依赖程度越来越高，用户因业务需要而使用多个应用系统及APP的情况也越来越多；联合认证平台以卫生健康基础资源共享链为依托，以统一身份认证为切入点，以数据共享治理为根本任务，实现医护人员身份、医疗机构可信认证、开放共享、防止造假；有效解决当前普遍存在的应用繁多、数据孤立、重复劳动、效率低下等信息化痛点。
集中身份管理
- 建立统一用户身份视图，作为单位的统一身份信息源，实现信息系统用户身份信息的集中管理，提供统一的用户身份生命周期管理，完整的管理审批工作流、委派管理和用户自助服务（如口令重置、用户属性修改、各应用帐号密码同步等）等功能；
- 身份信息同步，借助同步机制与单位的AD系统实现无缝对接同步权威用户信息、组织信息、岗位信息。
- 应用帐号信息同步，将各信息系统中原有的用户信息、角色信息通过数据同步机制与IDM管理平台上的数据信息进行同步，形成通过集中管理平台上管理整个单位用户的身份信息（主帐号）及对应IT资源系统的访问权限（从帐号）视图。
统一身份存储
- 身份信息存储，统一存储用户身份信息，鉴别信息，承载集中身份管理子系统；
- 帐号口令管理，为所有信息系统用户分配一个唯一的用户 ID，在统一管理平台上统一管理这些用户的帐号信息， 及其所对应的登录系统统方式，口令策略，如口令长度策略、口令复杂度策略、口令更换策略等。
统一认证管理
- 用户的多样化，使得用户的安全级别不同，统一身份管理与单点登录系统支持多种身份强认证方式，如静态口令、动态口令牌、AD域认证、二维码扫描认证、桌面集成认证、数字证书、USB Key、生物特征识别认证等来适应单位对多种安全级别的需求。
统一授权管理
- 系统提供统一的界面，对单位用户与资源系统应用帐号、应用角色进行关联授权，以达到对资源应用系统权限的细粒度分配。在集中访问授权里强调的“集中”是逻辑上的集中，而不是物理上的集中。即管理员在平台上可以对各自管理的应用对象进行授权， 而不需要进入每一个被管理对象才能授权。授权的对象包括应用帐号、应用角色。
统一密码管理
- 系统通过主从同步机制，确保用户主帐号密码与各应用系统从帐号的密码一致，解决用户记录多个应用系统的帐号、密码问题，简化单位应用的密码管理。
流程审批管理
- 针对单位安全管理规范，对指定的信息变更、权限开通，如用户部门变更、岗位变更、职工返聘（用户状态）、应用系统权限开通等需要通过多层级审批后生效。
- 系统提供层级审批机制，主要实现可视化、集中化的审批流程引擎，实现多种审批方式，包括平台审批、邮件审批、短信验证码审批。
统一单点登录
- 产品具有完善的单点登录体系，可安全地在应用系统之间传递或共享用户身份认证凭证，用户不必重复输入凭证来确定身份。
- 用户首先访问统一认证产品的认证页面，经过身份鉴别后，按照指定的权限单点登录到各个应用系统。此种应用场景可以充分发挥统一认证单点登录完善的优势，通过客户端Agent插件技术手段整合B/S架构、C/S架构应用系统，方便用户使用。
集中审计管理
- 审计日志功能：支持对集中身份管理与认证各种操作的日志记录，特别是对审批行为、异常行为的记录和跟踪， 符合国内信息安全标准，以及SOX法案；
- 报表功能：支持从日志记录汇总生成报表，能够从不同用户角色智能展现。
集成接口
- 用户管理接口：实现与其他信息系统用户身份信息的获取和同步；
- 授权接口：为其他信息系统提供统一的授权服务；
- PKI集成接口：实现与PKI系统的集成；
- 应用认证SDK：提供标准的Oauth、SAML、Formbase、CAS等认证协议SDK包。
平台的逻辑结构包括三个层面，即展示层、服务层和目标应用层，分别说明如下：
展示层
- 提供用户操作的界面，又分为最终用户操作界面（用户界面）、管理员操作界面（管理界面）和开发设计界面（设计界面）。
- 用户界面为客户用户帐号提供用户自服务的一些操作接口，包括密码修改接口、密码重置接口、个人资料查看接口、个人资料修改接口和管理员的委托管理界面等。相关接口将与统一访问管理平台集成，由认证门户作为统一操作入口。
- 管理界面为用户身份帐号管理员提供管理类的操作界面，包括用户帐号管理、用户组管理、应用资源管理、应用授权管理、审批流程和调度任务管理等。用户可以通过此界面创建、修改、禁止和删除用户帐号、管理哪些人可以访问哪些应用、属于哪个用户组等等。该界面通过浏览器访问。
- 设计界面是为开发人员提供的设计界面，包括设计工作流、开发连接器、资源类型定义、管理规则设计、过程管理和适配器设计等等。如当有新增应用或者变更管理流程时，需要通过此界面开发和设计相关处理接口和流程。该界面为一个Java客户端程序提供，将安装并配置于身份管理控制台PC服务器上。
服务层
- 联合认证平台的核心层面，是用户帐号数据处理的中央枢纽，包括身份管理应用服务和数据仓库。
目标应用层
- 指最终的应用系统和应用身份库， 联合认证平台可将身份数据同步至目标应用系统。
针对平台应用使用的服务器数量，主要从整体用户数、集成应用的总数及未来的可扩展性、当前的稳定性等方面综合考虑给出的建议：
- 统一身份管理和统一访问管理均采用集群的方式，确保高可用；
- 针对数据库可考虑采用RAC，主要是考虑其高可用性、稳定性；
- 网络层面可考虑采用网络负载均衡设备，对用户的访问进行分流，同时满足Internet认证访问的业务需求。
身份管理服务除提供身份管理事务处理外，还为最终用户提供日常操作和管理界面，如：自服务、密码修改等，身份管理服务采用三层构架，即接入层、数据层和应用层。
统一身份管理平台数据架构分为数据采集、处理、存储和数据供应等主要部分，其中数据采集采用SDK或API方式与单位权威数据源进行数据的拉取或推送；数据处理针对用户数据与认证数据进行新增和更新操作，其中认证库采取读写分离的方式实现认证性能的高可用；数据存储支持数据库和LDAP等多种方式；数据供应采用SDK或API方式为下游应用系统提供数据服务，同时考虑采取缓冲机制提升数据服务。
集中的身份认证、单点登录由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.3.1认证场景
多因素融合认证提供丰富的API和SDK，满足应用、系统和设备的快速接入，基于OTP，内置支持数字令牌、二维码认证，可与第三方认证数字证书、RSA、短信及生物识别认证集成，提供专属手机APP，方便用户下载安装。
1.2.3.2认证特点
平台功能主要包括身份管理、权限分配、风险配置及认证调度等，其特点主要包括：
- 安全性高，成熟算法不依赖网络
- 安全在手机上，无需额外其它硬件
- 与认证中心集成，提供不同应用与用户角色强认证
- 快速部署，周期短，风险低
- 提供标准API接口，灵活集成各类应用
- 软认证调用方式，成本低，使用方便
1.2.3.3认证等级
对于认证等级的管理可以帮忙单位实现多级别认证方式效果，可以对用户设定不同等级的认证方式，也可以对应用设定不同等级的认证方式。
1.2.3.4认证方式
提供统一的强认证管理，为单位提供各种各样的多因素强认证方式，包括AD认证、LDAP认证、互联网认证（微信、QQ、微博、支付宝、淘宝、单位微信、钉钉、单位公众号）、互联网认证、移动端认证、生物识别（人脸、声纹）、其他认证方式（滑块等）
支持主流的强认证方式集成，包含但不限于以下方式：
- 动态口令OTP/RSA
- 二维码扫描（微信、钉钉、支付宝、QQ）
- 数字证书CA/USB-Key集成
- 指纹认证集成
- 短信验证码
- LDAP/AD域
- 人脸识别
- 指纹认证
我们基本把系统分为三大类：
第一类：支持标准的认证协议（OAuth2.0、SAML、CAS、OIDC、Redius）
第二类：不支持认证协议单可以改造的（建议改造成OAuth2.0）
第三类：既不支持也不能改造的
支持标准认证协议
基于OAuth验证模块，主要分为授权码、程序脚本、凭证及API集中形式，常见采用授权码进行认证集成，其集成的步骤如下：
- 在第三方登录服务提供者申请网站，获得clientID和秘钥；
- 配置应用集成身份管理平台；
- 在身份管理平台配置第三方登录验证模块。
2)SAML认证集成
该场景主要针对跨区域的情况下进行联邦认证，通常以IDP和SP方式实现认证互信。
3)CAS认证集成
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协议集成交互时序如下图：
4)LTPA认证集成
部分商业软件（如金蝶、蓝凌），提供基于Cookie的轻量级第三方认证机制（LTPA），可以通过发布在Web Server上的联合认证平台 SSO服务提供给支持LTPA的应用系统，为客户机提供单点登录功能。当用户登录联合认证平台 SSO认证时，系统自动通过Web Server资源的LTPA认证。用户认证成功后，WebServer代表用户生成LTPA Cookie。作为WebServer认证标记服务的LTPA Cookie中包含用户标识、密钥和标记数据、缓冲区长度以及到期信息等，这些信息使用金蝶或蓝凌厂商提供的相关支持LTPA认证的产品之间传输的信息受密码保护的密钥加密。在访问各产品时，浏览器发出的请求通过连接自动将LTPA Cookie信息发送至服务器，服务器接收请求、解密Cookie并基于Cookie中提供的标识信息来认证用户。
5)OIDC认证集成
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示例：
http://10.0.10.8/esc-sso/oauth2.0/authorize?client_id=XXXX&response_type=code&redirect_uri=http%3A%2F%2FXXX.XXXX.XXXX.XXX%3A8080%2FXXXX%2FXXXX&oauth_timestamp=1489739502583
| 属性名称 | 说明 | 是否必须 |
| 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.6.3授权合规审计
- 系统级审计。系统级审计的内容主要包括登录（成功和失败）、登录识别号、每次登录尝试的日期和时间、每次退出的日期和时间、所使用的设备、登录后运行的内容（如用户启动应用的尝试，无论成功或失败）。典型的系统级日志还包括和安全无关的信息，如系统操作、费用记账和网络性能。
- 应用级审计。系统级审计可能无法跟踪和记录应用中的事件，也可能无法提供应用和数据拥有者需要的足够的细节信息。通常，应用级审计的内容包括打开和关闭数据文件，读取、编辑和删除记录或字段的特定操作以及打印报告之类的用户活动。
- 用户级审计。用户级审计的内容通常包括：用户直接启动的所有命令、用户所有的鉴别和认证尝试、用户所访问的文件和资源等方面。
- 权限合规安全审计。是通过对所关心的事件进行记录和分析来实现的，因此审计过程包括审计发生器、日志记录器、日志分析器和报告机制几部分，如图所示:
平台在现有安全认证的账号体系中，基于第三方平台消息推送解决方案的基础上，为用户提供一种更安全、私密、快捷的登录方式，推出我们自己的“一键免密登录”。相对于主流短信验证码的注册登录方式，用户手机端的一键登录方式能降低短信验证码被劫持的风险。用户通过手机端APP进行确认，能够保障用户的唯一性，降低账号使用安全风险。
1、用户在 PC 端登录页面，点击 “一键快捷登录” 按钮，触发手机一键登录；
2、此时用户在已经安装了App的手机会收到一条登录验证请求，用户只需要按照 PC 端提示打开App；
3、开启App，会弹出手机安全登录页面，点击“确认登录”按钮，执行一键登录；
4、此时用户可以看到 PC 端已经登录成功啦。
通过实现用户PC端登录与手机APP的协同配合，从而提高用户对密码的无感体验，提升用户登录操作的便捷性，最终实现用户身份确认与无密码认证的安全性保障。