门户平台身份认证 - 逻辑改造方案

前提说明

1、为什么要支持机构、身份、角色切换?

在系统实际的运行中,我们发现存在以下多身份,多角色,多机构的情况:

鉴于以上情况的出现,对系统的权限设计提出了较难的挑战。为了让系统能井然有序的运行,我们在权限设计的时候,选择了 机构 + 身份 + 角色 作为 用户在系统内可确定的权限划分主体进行逻辑判断

在系统的这个权限设计下,用户登录时,将会默认发生以下的一些情况:

说明:目前系统支持的身份类型(1:教师、2:学生、3:家长、4:开发者、5:普通用户、6:管理员)

综合系统实际运行中存在的情况以及系统以 机构 + 身份 + 角色 作为 用户在系统内可确定的权限划分主体进行逻辑判断, 就决定了在用户门户首页,系统需要实现 机构、身份、角色 的切换功能

2、支持机构、身份、角色切换后统一身份认证面临的困境?

在系统实际的运行中,我们发现以 机构 + 身份 + 角色 作为 用户在系统内可确定的权限划分主体进行逻辑判断, 结合 机构、身份、角色 的切换功能,在与三方系统的对接过程中,依然会存在 机构 + 身份 + 角色 不一致的情况,从而引起系统的功能权限控制异常,也给用户带来了不好的体验。

引发这种情况的原因有:

系统中家长角色的用户,登录系统的目的实际上目的是为了操作自己孩子的功能,如:填写报告单、完成任务。因为当前子系统(如:报告单、过程评价)的逻辑是使用学生自己的账号进行功能操作,这将导致单点登录时,因为账号主体是家长,而无法使用孩子的账号进行单点登录。

3、门户统一身份认证流程

解决方案

为解决当前多身份,多角色,多机构下的统一身份认证面临的困境,需要对个人门户CAS统一身份认平台进行一些功能改造以解决当前所面临的问题。

1、个人门户 需要进行的改造:1天(开发与测试)

2、CAS统一身份认平台 需要进行的改造:2天开发、1天测试

3、业务中台 需要进行的改造:1天(开发与测试)

4、三方系统 需要进行的改造:1天(开发与测试)

改造后的流程示意图