集成底座统一认证配置说明

Posted 2022-05-17 数通畅联

企业的信息化建设是一个循序渐进、不断延展的过程，在这过程中企业对于体系架构、集成整合、数据治理、安全管控的要求也会不断提升，而集成底座方案的诞生就是为了解决信息化建设时缺乏整体规划、集成整合难度大、安全管控不到位等问题。

集成底座主要包括IDM统一认证平台、MDM基础数据平台、ESB企业服务总线三个产品，本文主要是基于IDM平台对各个系统和IDM进行统一认证的配置过程进行说明，为后续集成底座项目的交付提供借鉴。

1总体说明

集成底座主要包括三个产品：IDM统一认证平台、MDM基础数据平台、ESB企业服务总线，其中IDM平台基于5A管控体系实现账号管理、统一认证、授权管理、统一审计、应用管控等安全管控，MDM主要支持组织、岗位、人员等基础数据的同步分发，ESB作为集成通道，满足IDM、MDM以及上下游系统的集成流程管理以及API管理等。

1.1集成架构

集成底座方案的集成主要是基于IDM和MDM作为数据的集中维护平台，通过ESB进行服务API的管理，构建集成通道，从而实现IDM、MDM以及上下游系统的打通。由业务系统作为基础数据的源头，这些基础数据通过ESB同步至MDM平台进行统一管理，保证基础数据的准确性、唯一性；MDM再将组织、人员等基础数据分发至IDM生成对应认证账号信息，用于支持统一认证等业务；整个集成过程中，ESB作为服务总线负责对各个系统的接口和服务进行注册和管理，同时构建系统数据对接的集成流程。

1.2业务场景 

集成的业务场景集成主要是基于IDM和MDM的数据同步分发，其中包括业务系统到MDM的主数据同步，主数据到下游系统的下发（包括下发IDM），以及IDM下发账号到下游系统等。 

1.主数据同步： 

1)源头推送数据（或者推送查询标识）至ESB的集成流程； 

2)ESB的集成获取源头数据（或者通过查询标识从源头查询数据）后，在集成流程内部调用MDM的接口； 

3)生成主数据编码，并将数据写入MDM，同时生成任务和同步日志； 

4)ESB集成流程调用MDM的自动提交接口将任务提交至MDM的BPM工作流中，BPM工作流通过调用ESB的分发流程实现数据向下游系统的分发。 

2.主数据分发： 

1)通过ESB开发主数据分发的集成流程，提供给MDM的BPM工作流进行调用； 

2)集成流程的入参为MDM任务的taskId，通过taskId查询MDM的任务数据，并根据业务要求进行数据处理； 

3)处理后调用下游系统的数据接收接口将数据写入到下游系统中； 

4)下游系统完后数据写入后调用MDM的日志回写接口进行数据回写操作。 

3.账号分发： 

1)账号分发主要是通过IDM将登录用户信息分发至下游系统，实现各系统的统一认证和单点登录； 

2)IDM账号分发主要是将IDM的账号信息通过任务的形式分发下游系统，和MDM的分发方式类似； 

3)在账号信息进入IDM平台，可以手动或自动的方式生成分发任务，再通过IDM内置的BPM工作流进行自动提交； 

4)在BPM工作流内调用ESB的IDM分发集成流程实现向下游系统的数据分发； 

5)IDM分发集成流程的入参为IDM任务的taskId，通过taskId查询IDM的任务数据，并根据业务要求进行数据处理； 

6)处理后调用下游系统的账号接收接口将数据写入到下游系统中； 

7)下游系统完后数据写入后调用IDM的日志回写接口进行数据回写操作。 

1.3统一认证 

统一认证是IDM平台5A管控的重要一个内容，也是集成底座项目中必做的一个内容，通过统一认证打通各个业务系统访问的限制，实现一次登录，多处访问，避免访问不同的业务系统时频繁进行登录操作，也不需要同时维护多个系统的账号和密码。 

IDM主要支持统一认证方式有三种：CAS认证、OAuth认证和接口认证，根据业务系统和使用场景的不同，可以灵活选择认证实现的方式。 

2CAS认证 

CAS认证是比较传统的一种认证方式，在IDM系统中对于CAS也是做了一定的延展，IDM的CAS认证目前是可以满足绝大多数系统的对接需求的。而CAS认证主要是基于拦截器机制实现的，通过配置拦截实现客户端与CAS服务端的交互，从而完成统一认证的实现。 

2.1认证原理 

  

CAS认证过程： 

1.业务系统的web.xml主要配置AuthenticationFilter、
Cas20ProxyReceivingTicketValidationFilter、HttpServletRequestWrapperFilter、XXXUserCasFilter； 

2.首先AuthenticationFilter进行拦截判断，获取Assertion和ticket，如果Assertion和ticket都不存在，则拼接登录的URL（CAS认证地址 + 来源系统地址），并跳转CAS登录页；如果认证通过，则根据来源地址跳转到业务系统； 

3.如果跳转登录页，输入用户名、密码、验证码等信息进行登录认证； 

4.登录认证时Cas20ProxyReceivingTicketValidationFilter对ticket进行校验，校验成功后根据用户名从数据库或缓存中获取用户信息；  

5.通过解析Response的XML获取用户信息，通过Map存储到Assertion中； 

6.HttpServletRequestWrapperFilter拦截器通过Assertion获取Principal中存储的用户信息； 

7.XXXUserCasFilter：平台扩展的拦截器，用于从Principal获取用户编码等信息，并对用户权限进行初始化。 

2.2配置方式 

CAS认证在配置时业务系统主要配置两个内容，一是web.xml中配置拦截器，通过拦截器和CAS服务端进行交互，二是需要在系统扩展一个拦截器，该拦截器的主要作用是完成系统登录，由于CAS认证返回的是IDM的用户信息，业务系统需要基于这个信息进行系统内部的登录判断以及权限初始化等。 

1.web.xml： 

登录页面 

注：黄色标记的内容均为需要修改的内容，其中CAS的地址（带有/cas）修改为IDM系统的CAS认证地址，serverName地址修改为业务系统自己的访问地址，GeneralCasFilter为扩展的拦截的类路径。 

2.XXXUserCasFilter： 

注：黄色标记的内容为需要手动调整的内容，业务系统根据实际情况进行系统内部登录、权限初始化等操作。 

2.3注意事项 

1.不同语言、不同架构的系统可能对于拦截器的配置方式不同，业务系统根据系统的语言、架构情况进行调整； 

2.扩展拦截器的命名可以自行定义，但是注意保证拦截器类名和web.xml配置的类路径保持一致； 

3.业务系统要调用CAS相关接口，需要引入CAS相关jar包，该包由IDM系统提供，业务系统直接引入系统即可； 

4.CAS认证时，如果Cas20ProxyReceivingTicketValidationFilter报错，主要有两个问题： 

1)web.xml配置的参数不对，导致HttpClient请求时出现网络不通； 

2)ticket校验失败，超时（10s）或ticket错误。 

3OAuth认证 

IDM的OAuth认证主要采用OAuth2.0的方式，业务系统通过OAuth认证时不需要修改配置文件，只需要调用IDM提供认证接口，通过认证接口完成认证。 

3.1认证原理 

1.用户访问业务系统时通过URL跳转，跳转至CAS的登录页面，CAS登录成功之后会根据来源系统跳转至业务系统的访问地址； 

2.业务系统接收到访问CAS认证过来的请求后，先调用请求认证接口，传入client_id、redirect_uri、response_type、state，IDM根据参数返回code及state； 

3.业务系统获取code后，再调用获取accessToken接口，传入client_id、client_secret、redirect_uri、grant_type及code获取accessToken； 

4.业务系统第三步再调用获取用户接口，传入accessToken，获取json格式的用户信息Profile，业务系统根据Profile进行内部登录判断，实现系统登录。 

3.2配置方式 

OAuth认证主要是业务系统扩展三步接口的调用： 

1.http://IP:PORT/cas/oauth2.0/authorize 

2.http://IP:PORT/cas/oauth2.0/accessToken 

3.http://IP:PORT/cas/oauth2.0/profile 

对于OAuth认证，需要在IDM平台的应用管理中配置系统信息，配置内容如下： 

1.在应用管理中注册一个业务系统信息，编码、名称、密码可以自行定义，访问URL为业务系统的访问地址； 

2.配置应用域名，为业务系统的访问地址； 

3.3注意事项 

1.OAuth认证的三步接口调用是在用户登录之后进行的操作，即用户在CAS登录页登录后会先在CAS端进行认证，认证成功后才会根据访问的地址跳转到业务系统中； 

2.OAuth认证和CAS认证一样，在三步接口获取到用户信息后，业务系统也要基于用户信息进行内部登录和权限初始化等操作。 

4接口认证 

接口认证的使用场景和CAS、OAuth有所区别，接口认证主要是满足于桌面端、APP端等有独立的登陆页面，同时也无法集成CAS登录页的情况，这种情况由于只能使用业务系统自己的登录页，所以IDM平台提供的认证接口用于满足统一认证的需求。 

4.1认证原理 

1.用户访问时直接进入业务系统的登录页面，输入用户名、密码、验证码等信息进行登录； 

2.登录时业务系统将code、pwd、appCode、clientIp、serviceUrl等参数发送到IDM的认证接口； 

3.IDM认证成功后将用户信息以JSON的格式返回； 

4.业务系统拿到用户信息后进行系统内部的认证、授权等操作，完成登录认证。 

4.2配置方式 

接口认证的配置比较简单，业务系统在登录时直接调用IDM的认证接口，可以前端调用，也可以后端调用，调用成功后根据用户信息认证即可。 

认证接口： 

http://IP:PORT/MDMIntegration/http/IdmUserAuth

4.3注意事项 

1.认证接口的调用支持前端调用和后端调用两种方式，前端建议采用ajax的方式调用，后端建议采用HttpClient的方式； 

2.调用接口进行密码传输时推荐采用密文传输，提高安全性，加密方式为AES加密，加密规则有IDM系统提供； 

3.由于认证接口是直接传输账号和密码到IDM平台，所以接口认证登录时依然需要使用IDM平台的密码，而由于登录页面是业务系统自己的登录页面，为了避免混淆，业务系统需要进行密码同步，保证和IDM平台的密码一致。 

5.总结说明 

本次总结是基于集成底座平台的统一认证的总结，主要是以IDM为基础的统一认证的实现过程的梳理，由于在实际项目中，统一用户、统一认证是集成底座必做的内容，所以对这部分内容再一次进行整理。 

5.1应用场景 

统一认证的实现主要是基于IDM平台，目前IDM平台预置了CAS、OAuth、接口三种认证方式，后续集成底座项目中的统一认证都是采用这些方式，所以对这些方式的使用场景一定要熟悉。 

1.CAS认证：客户端传入用户名、密码，CAS服务端只进行认证判断，认证成功后返回登录票据和用户标识，客户端再进行登录判断。由于CAS认证需要配置web.xml、拦截器等内容，对后端依赖较重，对于传统单体的B/S架构应用较为友好； 

2.OAuth认证：通过接口的方式进行认证，相对于CAS应用比较灵活，没有繁琐的配置，只需要完成三步接口调用，对于前后端分离、微服务等架构系统比较推荐。由于CAS和OAuth都是基于CAS登录页实现的登录操作，所以二者的使用场景交叉比较大，大部分是重合的； 

3.接口认证：不同于以上两种，接口认证更为简单，只需要调用一次认证接口，但由于需要在系统间进行密码传输，存在安全隐患，所以建议采用密文传输降低风险。接口认证由于直接采用业务系统自己的登录页，所以比较适合桌面端、独立APP等，不需要引入CAS登录页的情况，但是为了保证使用效果，往往需要进行密码同步的操作。 

5.2工作总结 

最近一直在负责集成底座的项目，也参与了多个集成底座项目的实施交付，在实施交付过程中，对于集成底座、IDM也在不断地熟悉了解，在实际项目中IDM5A的内容具体要如何落地，如何融入到企业的信息化体系中是非常关键的点，5A的实现需要基于大量的集成，需要和上下游系统频繁交互，这些内容都需要不断总结梳理。 

5.3个人总结 

通过最近参与集成底座的项目，感觉个人对于集成底座的产品使用、应用场景等还存在不足，对于5A管控的内容掌握得还不够全面，特别是在实际项目中面对大量定制化需求，特殊业务场景的情况下，如何能够将这些场景通过标准化的规程来实现，有哪些内容可以直接纳入产品或方案中来，无论是作为项目经理还是方案负责人这些都是需要考虑的问题。 

基于项目上的实际情况，最近也在对这部分内容进行梳理，包括如何制定更为标准的同步分发流程，制定数据集成规范，统一认证的标准化、规范化、批量化等，只有保证这些标准的有效落地，才能保证集成底座项目能够快速实施、快速交付，最终形成伙伴交付、技术支持的模式，让集成底座如标准化产品一样，拿来即用、用之即成、敏捷交付。