精华内容
下载资源
问答
  • 统一身份管理中的权限管理设计
    2019-04-01 15:49:27

    关注嘉为科技,获取运维新知

     

    权限集中管理是统一身份管理关注的主要内容之一,由于企业应用建设的自身历程不同,权限设计与实现也必然存在差异,针对集中权限管理的设计和实现带来了不小的挑战,本文根据多年的实践经验,就统一身份管理的集中权限管理的设计与实现给予设计建议。

     

    一   问题背景

     

    随着信息技术和网络技术的迅猛发展,企业内部的应用系统越来越多,为此,为减少用户访问的麻烦,提升访问的便利性和体验,众多企业采用了统一身份管理的方案来解决该问题。

     

    就企业的统一身份管理,业界提出了相应的标准,即4A标准,分别是集中帐号(account)管理集中认证(authentication)管理集中权限(authorization)管理集中审计(audit)管理 。

     

    然而众多企业在实施过程中仅做到集中账号管理、集中认证管理、集中审计管理。

     

    究其原因,一是集中权限管理对应用系统各方的改造工作量较大、成本高,二是由于各应用系统的权限设计模型不尽相同,在集中权限管理的设计上有一定的难度。

     

    针对统一身份管理中的集中权限管理的需求与现状,总结我们多年统一身份管理项目实施的经验,我们梳理了一种复合的权限模型,以满足不同层次的权限集中管理需要。

     

    二   权限管理需求的三种模式

     

    首先,我们看一下在统一身份管理过程中的权限管理需求,经过梳理,我们认为权限管理可以分为3个层级需求,其分别如下:

     

    1、账号级权限管理需求

    账号管理是统一身份管理的基础与核心。账号级权限管理是账号管理的一部分,其需求的定位即为为用户提供应用的账号,通过控制用户的应用账号,从而控制用户对于某一应用的权限。

     

    该种需求对权限管理的粒度较粗,但改造的成本最低,改造工作可以在应用系统与统一身份管理平台的账号对接中同步完成,不涉及额外单独的改造成本;

     

    但该种方式需要应用管理员配合进行用户的授权,如需做到功能和数据细粒度的授权,用户权限管理的维护成本较高。

     

    2、角色级权限管理需求

    角色级的权限管理是指采用基于角色的权限管理,统一身份管理平台与应用系统共用一套或多套角色。

     

    应用系统就各角色预设细粒度的功能与数据权限,统一身份管理平台通过对账号应用系统角色的管控,从而实现对用户在应用系统中权限的控制。

     

    3、功能按钮与数据维度级的权限管理需求

    功能按钮与数据维度级的权限管理,则是需要在统一身份管理平台可以直接配置每一个账号在每一个应用中的细粒度权限。

     

    其可以监督便利性与控制粒度要求,整个过程中无需应用管理员参与,但对应用系统的配合改造要求较大。

     

    三  权限管理设计

     

    不同的权限管理需求模式,适用于不同的业务场景和应用系统。

    由于应用系建设自身历程发展的原因,在企业的集中权限管理过程中,往往是多种模式并存,由应用系统是否可以改造和可改造的深度确定。

    因此,针对权限集中管理的设计,我们构想方案如下:

     

    1、  账号级权限管理

    账号级权限管理通过用户账号生命周期管理同步实现,通过控制用户应用系统中账号的开通、启动、停用等从而实现对用户访问应用系统权限的控制,实现“大门级”的权限管控。

     

    2、  角色级及细粒度功能权限级

    针对角色级和细粒度功能权限级的控制,可以统一考虑,在统一身份管理平台上构建基于RBAC模型的权限管理功能,将各应用的数据权限、功能权限注册到统一身份管理平台,并通过角色进行权限集的管理,而用户则分配到角色,其整体的模型图示如下:

     

     

    但对于不同权限管理层次的应用,应用的改造深度不同,对于角色同步的改造,较为简单,只需在用户同步的时候增加角色同步。

    但对于功能粒度级的改造,则需要针对鉴权模型进行调整,其实现逻辑可设计如下:

     

     

    通过细粒度的权限控制,不仅可以实现权限的集中控制,还可实现企业级的权限审计,有效降低企业应用越权使用风险。

     

    企业统一身份的建设过程中,究竟采用何种粒度的权限集中管理,要根据企业的应用的改造难度、应用数量以及应用的业务价值等方面综合评估,针对不同的应用,可根据实际需要采用不同粒度的管理方式,逐步推进集中权限管控。

     

    更多相关内容
  • 企业后台系统提供统一登陆鉴权,菜单管理,权限管理,组织架构管理,员工管理,配置中心,日志管理等。 支持企业微信,钉钉登陆和同步企业组织架构。 统一管理员工入离职,强化权限审批流程化。 打通开源软件,...
  • 值得一提的是,这套中台系统由于讲解了如何统一管理企业内部各大应用系统的“菜单资源列表”、“操作权限”,故而本门课程的“代码实战”是建立在之前debug录制的“企业权限管理平台”这套课程的基础之上的,故而在...
  • IDM统一权限功能修改心得

    千次阅读 2021-12-08 11:33:55
    IDM统一权限是对各个业务系统的功能资源进行管控,现将本次开发完善统一权限模块的功能经验、心得体会进行梳理总结。

    IDM身份管理系统是为解决企业内部多系统间用户信息不一致而开发的,主要定位于解决企业在5A功能上的需求,即:Account账号管理、Authentication认证管理、Authorization授权管理、Audit审计管理、App Control应用管控5个方面的实际需求,进而规范用户身份信息,保证系统安全,提高工作效率。

    统一权限是对各个业务系统的功能资源进行管控,权限资源授权体系包括组织、标准角色、实际角色、用户。目前可以通过标准角色管理用户、组织关联标准角色后会生成实际角色。但是目前缺少一个场景就是跨组织分配用户,所以需要进一步完善统一权限模块的功能,现将本次开发中的学习经验和心得体会总结如下。 

    1.整体介绍 

    IDM身份管理平台满足对企业信息系统的统一用户管理、统一身份认证、统一授权管理以及安全审计要求,能够实现各业务系统的统一登录和集中访问,实现用户身份和权限的统一认证、授权管理,为企业不同业务系统提供统一的用户管理和认证服务。 

    1.1功能架构 

    IDM主要对组织、角色、人员进行管理,并对其所有的状态进行记录,如:初始化、审批中、已启用、已禁用等,账户统一管理可以实现从HR系统中获取组织用户数据,也可直接在IDM系统中录入数据,用户信息中的部分属性信息根据同步策略由HR系统或其它指定系统同步更新到用户目录,其它用户信息可在应用系统中各自进行维护,通过IDM统一用户信息后,发送到各个业务系统。 

    1.2系统架构 

    IDM主要是实现统一认证、授权、审计管理,提高企业身份认证及访问安全,建立授权流程审批机制,使用户身份信息、授权信息、审批信息等操作更加规范化、标准化,提高整体IT架构的风险防范能力。

    消除企业系统间的信息孤岛,为各系统提供统一身份认证、用户身份管理服务,逐步实现系统身份系统的整合,构建面向用户的认证和授权服务,使业务操作更流畅。为简化IT运维提供强大的技术手段和标准,实现账户数据自动化同步操作,同时制定合规的安全服务规范,构建统一的、支撑企业级的认证授权安全服务基础设施。 

    1.3实现思路 

    1.“应用配置”模块添加两个策略: 

    (1)标准角色直接关联用户:控制“标准角色”模块关联人员标签页面是否显示。 

    (2)实际角色跨组织关联用户:控制该系统的实际角色是否可以跨组织关联用户。 

    2.“标准角色”模块改为左侧树形菜单右侧列表的形式,并添加关联组织的功能。 

    3.“授权管理”模块添加排除组织和排除人员的功能,可以排除标准角色和实际角色关联的组织或人员信息。 

    4.新增通过人员查询权限信息的接口,出参给出对应的人员信息、关联角色信息、关联的组织信息和权限资源信息。 

    2.功能说明 

    统一权限功能主要分为三个模块,分别为:角色管理、权限资源和授权管理,下面主要介绍一下各个模块的功能。 

    2.1角色管理 

    1.标准角色: 

    主要对各个应用系统的标准角色信息进行管理,页面左侧为标准角色树形菜单,右侧包含标准角色明细页面和关联用户信息列表,通过切换应用系统可以查看不同应用系统下的标准角色信息,支持接口导入和excel导入功能。 

    (1)列表页面: 

    (2)明细页面: 

    2.实际角色: 

    主要对各个应用系统的实际角色信息进行管理,建立组织与标准角色之间的关联关系,页面左侧为组织树形菜单,右侧为所选组织下实际角色信息列表。通过切换应用系统可以查看不同应用系统下的实际角色信息。 

    (1)列表页面: 

    (2)明细页面: 

    2.2权限资源 

    1.功能资源: 

    功能资源页面左侧为各个应用系统所对应的功能菜单,通过切换应用系统来控制左侧的功能树菜单,右侧包含“基本信息”和“控制器列表”两个标签,基本信息显示所选树节点的功能明细信息,控制器列表显示与所选树节点关联的控制器和相关操作信息。 

    2.数据资源: 

    数据资源主要对各个应用系统下的通用枚举类数据进行管理,页面左侧为数据分组树形菜单(可编辑),右侧为该分组下的数据列表信息,可以通过切换应用系统来显示不同应用系统下的数据信息。 

    3.接口资源: 

    接口资源主要是对各个应用系统下的接口信息进行管理,页面左侧为接口分组树形菜单(可编辑),右侧为该分组下的接口列表信息,可以通过切换应用系统来显示不同应用系统下的接口信息。 

    2.3授权管理 

    授权管理模块主要为各个应用系统的不同权限资源建立和标准角色、实际角色、人员、组织的关联关系。授权管理模块分为功能菜单、数据资源、API接口三个标签,分别为这三个权限资源赋予权限。 

    3.开发过程 

    本次开发需要扩展“应用配置”模块功能,添加配置业务系统组织的功能,统一权限模块根据应用系统的配置来获取对应的组织人员信息;还需要新增根据人员查询权限信息的接口。下面主要介绍一下在开发过程中需要修改、完善的功能。 

    3.1应用配置 

    1.添加“是否统一组织”策略,如果选否会让用户配置获取组织和组织人员关联信息的接口。 

    2.新增“标准角色直接关联用户”策略,用来控制标准角色是否关联用户。 

    3.新增“实际角色跨组织管理用户”策略,用来控制实际角色是否可以跨组织关联用户信息。 

    3.2统一权限 

    统一权限模块中的组织人员信息,改为通过应用系统配置来获取对应的业务组织或行政组织信息。 

    3.3新增接口 

    新增通过人员查询权限信息的接口,出参给出对应的人员信息、关联角色信息、关联的组织信息和权限资源信息。 

    1.接口地址: 

    http://localhost:3030/idm/openapi/DataProvide/rest/record/user-auth 

    2.接口入参: 

    3.出参样例: 

      

    4.心得总结 

    在本次开发过程中,自己的技术能力还有对IDM产品的理解能力都得到了很大的提升,并且有了很多感悟,现将我在本次工作中的收获,总结如下。 

    4.1能力提升 

    在本次开发过程中,无论在代码还是意识形态方面我都学到了很多,比如在开发过程中要考虑全面,不是实现功能就行,要考虑多方面的因素,如:页面美观、产品性能等因素,同时还要考虑代码的质量,只有这样开发出的功能才能满足客户需求。 

    4.2开发心得 

    不论在什么时候,权限都是一个很重要的事情,因为无论对于个人还是企业来说安全都是重中之重,所以权限管理是一个很重要的功能。本次开发的统一权限功能可以对各个应用系统的权限资源在IDM中进行统一管理、授权,使用户在查看数据时更加便捷。 

    4.3产品理解 

    IDM统一身份管理平台主要是实现5A功能,即Account账号管理、Authentication认证管理、Authorization授权管理、Audit审计管理、App Control应用管控。提高企业身份认证及访问安全,建立授权流程审批机制,使用户身份信息、授权信息、审批信息等操作更加规范化、标准化,提高整体IT架构的风险防范能力。 

    本次开发涉及的统一权限功能,完善了IDM在权限管理方面的功能,从而解决企业当前权限管理面临的开通难、查询难、回收难和管理难问题,加速企业权限管理建设,降低权限管理的维护成本。 

    展开全文
  • 对于Saas业内在用户统一身份认证及授权管理领域,主要关注 4 个方面(4A管理)): 集中账号管理(Account)、集中认证管理(Authentication)、集中授权管理(Authorization)和集中审计管理(Audit), 简称 4A ...

    对于 Saas业内在用户统一身份认证及授权管理领域,主要关注 4 个方面(4A管理)):
          集中账号管理(Account)、集中认证管理(Authentication)、集中授权管理(Authorization)和集中审计管理(Audit), 简称 4A 管理。
    后来发展了 IAM(Identity and Access Management,即身份识别与访问管理)的相关技术,在云计算等领域应用广泛。整体来说,不管是 4A 还是 IAM 还是未来可能的其他技术方案,都可以归纳为『统一身份治理』的范畴。本文基于『统一身份治理』的概念提出了统一身份管理系统(Unified Identity Management System)的设计思路。

    一、统一身份管理系统(Unified Identity Management System)

          统一身份管理系统(简称 UIMS)可以认是多租户软件架构的升级版,通常是整个平台帐号和权限管控的基础性系统,平台下所有系统的账户管理、身份认证、用户授权、权限控制等行为都必须经由该系统处理,提供帐号密码管理、基本资料管理、角色权限管理等功能。UIMS 基于『统一身份治理』的概念,可划分为两级账户体系、基础权限模块和基础信息模块三大模块。其中两级账户体系将账户分为组织实体帐号和个人实体账户两大类,个人实体从属于组织实体,也可以不从属任何组织实体,且个人实体可同时从属于多个组织实体;基础权限模块将各业务系统的资源权限进行统一管理和授权;基础信息模块用于描述组织实体和个人实体的基本信息,如组织实体名称、地址、法人,个人实体姓名、电话号码、性别等基础信息。UIMS 提供统一的 API 与各子系统连接。

    从整个平台的角度来看,UIMS 除了提供上述功能和服务,还应该满足以下需求:

    编号需求描述
    1软件授权云平台付费授权机制,可按时间、功能、数量等进行付费授权
    2组织入驻允许组织主动申请加入平台
    3实名认证个人实名认证、组织实名认证
    4资质审核个人和组织的资质审核,如对获得的证书或荣誉进行审核
    5组织绑定个人账户绑定组织,与组织建立关联关系
    6组织解绑个人账户与组织进行解绑
    7账户注销个人账户注销,并销毁所有个人资料和档案
    8统一登录即 SSO
    9统一注册提供统一的用户注册页面

    因此,从功能的角度可以将 UIMS 划分为以下模块:

    一)功能
    
        系统设置 System Configuration
          系统标识管理 System Identifiers Management
          服务账户管理 Service Accounts Management
        
        账户实体管理 Account Entities Management
          组织实体管理 Organization Entities Management
          组织架构管理 Organization Management
          个体账户管理 Individual Accounts Management
        
        账户权限管理 Account Permissions Management
          用户组管理 User Group Management
          角色管理 User Roles Management
          资源权限管理 Permission Resources Management
          权限策略组管理 Permission Group Management
        
        认证审核管理 Authentication Management
          个人认证管理 Individual Authentication Management
          组织认证管理 Organization Authentication Management
          资质审核管理 Qualification Management
        
        付费授权管理 Authorization Management
          组织授权管理 Organization Authorization Management
      
    二)页面
    
        统一注册页面 Unified Signup Page
        统一登录页面 Unified Signin Page
        组织入驻页面 Organization Signup Page
        个人实名认证页面 Individual Authentication Page
        组织实名认证页面 Organization Authentication Page
    
    三)API
    
        鉴权相关的APIs
        业务相关的APIs
    

    其中组织绑定和解绑的功能,可以放到『组织实体管理』 或『个体账户管理』的功能中。需要注意的是,组织绑定与解绑功能,是否与业务系统关联,下文将进行阐述。

    二、两级账户体系和基础权限模块

    基于『统一身份治理』的理念,采用两级账户体系(UIMS 提供接口)实现多系统融合的平台级 SAAS。两级账户体系将账户类别分为组织实体和个人实体两类(详见下文用户分类)。个人实体可以从属于组织实体(可以从属于多个组织实体),也可以不从属。个人账户体系和组织账户体系在云平台内享有的权限是不一样的,虽然大部分功能和服务两个体系的实体均可独立使用,互不干扰,但部分功能和服务有所不同。

    1. 基本原则

    平台级 SAAS 模式账户体系应遵循以下几个基本原则:

    • 个人账户统一原则:个人账户一次注册,全平台通用,类似于全网通行证和 SSO,注册和登录都在 UIMS 进行。
    • 业务权限独立原则:每个子系统的权限体系是独立管理的。『个人账户统一原则』明确了账户体系是统一的,但是对于每个子系统而言,每个账户所能使用的功能和服务,所能查看的数据权限是独立维护的,比如 XXX 公司(组织)-研发T3组(用户组)-张三(用户)-研发人员(角色),在 CRM 系统中,拥有的资源权限(详见下文),与其在 OA 系统中的所拥有的资源权限肯定是不一致的。
    • 组织实体隔离原则:不同的组织实体之间,是相互隔离,独立管理的。每个组织实体可以自行组织自己的组织体系、账户体系和权限体系。不同的组织实体资源权限也是隔离的。
    • 从属关系隔离原则:个体账户与组织实体的从属关系是基于单独的业务系统存在的,『个人账户统一原则』明确的仅是个人账户的全网统一,但组织实体、从属关系并没有统一,并且是隔离的。比如在 CRM 系统中,张三(用户)从属于 XXXX 公司(组织),但在 OA 系统中,张三(用户)默认是不从属于任何组织的,从属关系受到具体业务系统的影响。事实上,这个原则是非强制的,具体取决于各自的业务逻辑和业务场景。如果要简化从属关系的管理,那么可以不遵循此原则,即个体账户与组织实体的从属关系是全平台统一的,与业务系统无关,但这会为降低平台的灵活性和扩展性。灵活性和复杂度之间通常要做一个取舍。

    2. 权限原则

    类似于 RBAC 原则,平台的权限体系采用 OS-RBAC 的概念:

    • OS:O 代表 Organization 组织,S 代表 System 业务系统,即权限是受到组织实体和业务系统双重影响的。
    • RBAC:基于角色的访问控制。
    • OS-RBAC:组织实体-业务系统-用户-角色-权限标识。分为两种情况:一种是有从属组织的个人账户;另一种是无从属组织的个人账户,后者无组织,但同样遵守 RBAC 的权限限定,且其权限标识体系允许组织为空。
    • 资源标识:分为逻辑资源和实体资源。逻辑资源如菜单、页面、表单、按钮组、按钮、字段等功能型资源,或人员档案、考勤记录、任务记录、位置数据、积分、电子钱包等数据资源;实体资源如椅子、凳子、电脑、车辆等实物资产,另外有时候部分逻辑资源也可以归纳为实体资源,如电子照片、视频文件、音乐文件等。
    • 条件标识:权限的约束条件,主要有可见组织架构范围限定、时间限定、区域限定等。例如某权限仅财务部可见,有效期至11月2号,这里『财务部』属于可见组织架构范围限定,『至11月2号』则是时间限定。
    • 权限标识:用于标识账户实体在指定的条件下拥有访问某项功能、查看某些数据的权限。资源标识和条件标识与权限标识关联,权限标识与角色关联,角色与用户关联。例如张三(用户)-研发人员(角色)-拥有『研发部』所有人员档案的增上改查权限。
    • 业务系统标识符:受『业务权限独立原则』的约束,与传统的资源权限有所不同的是,所有权限标识都与具体的业务系统关联,例如企业CRM系统就是一个业务系统,具体的权限标识与业务系统有直接的关系,例如菜单、表单、页面、按钮、图片等资源。
    • 权限策略组:权限策略组是在 OS-RBAC 基础上设置的,为简化权限配置的一种辅助手段,在实际应用中可以不创建策略组。策略组分为平台级策略组和业务系统级别的策略组,两种策略组的作用域仅限于相同组织实体内部,但对于无从属组织的个人账户除外。策略组与角色类似,可以将资源权限绑定到策略组中,但不同之处是,平台级策略组可以横跨业务系统进行平台级的资源权限绑定。因为账户体系跨越多个子系统,在遵循『业务权限独立原则』的限定下,每个子系统都需要做一套权限配置,操作上较为繁琐,因此充分运用策略组可以大大简化权限配置工作。平台可以内置多套常用的策略组,终端用户可以直接选用策略组,也可以基于某个策略组为基础,进行修改。值得注意的是,策略组的作用域仅限于相同组织实体内部,即策略组可以横跨业务系统,但不能同时作用于多个组织实体。
    • 权限交集:与 RBAC2 的静态职责分离-角色互斥原则相反,平台采用多角色权限并集的设计。
    RBAC模型
    RBAC模型

    『权限标识』示例:在企业CRM系统[1]中,在2019年3月5号以前[2],对百度科技[3],研发中心[4],在广东区域[5]的所有人事档案[6]拥有只读权限[7]。

    1. [1]业务系统标识;
    2. [2]条件标识:时间限定;
    3. [3]组织实体标识;
    4. [4]条件标识:可见组织架构范围限定;
    5. [5]条件标识:区域范围限定;
    6. [6]资源标识;
    7. [7]权限类型。

    3. 从属关系梳理

    为简单起见,我们将不遵守『从属关系隔离原则』,即用户实体与组织实体的从属关系与业务系统无关。系统涉及的实体类型有:

    • 业务系统(系统标识)
    • 服务账户(客户端)
    • 个人账户实体
    • 组织账户实体
    • 组织架构
    • 用户组(非必选项)
    • 角色实体
    • 权限实体
    • 资源实体
    • 限定条件实体
    • 权限策略组(非必选项)

    3.1 与组织实体强关联的实体

    基于『组织实体隔离原则』,这类实体类型不能脱离组织实体独立存在。

    • 组织架构
    • 角色实体
    • 权限实体
    • 资源实体
    • 限定条件实体

    由于组织架构不能脱离组织实体单独存在,因此当用户实体绑定组织架构时,该用户实体必须隶属于该组织架构所从属的组织实体。同理可知以下从属关系遵从同样的约束——即每对关系的两个实体对象必须属于相同的组织实体:

    • 用户与角色
    • 角色与权限
    • 资源与权限
    • 限定条件与权限

    3.2 与业务系统强关联的实体

    基于『业务系统隔离原则』,这类实体类型不能脱离业务系统独立存在。

    • 权限实体
    • 资源实体
    • 限定条件实体

    4. 实体类型

    基于以上各项原则,实体类型又分为以下几种情况:

    • 组织实体(未认证):在组织实体的模式下,可以按照组织的管理要求,独立设置一套组织架构、账户和数据权限体系,比如设置下属企业、分公司、部门、岗位职务、角色权限,组织实体缺省分配一个管理员帐户,拥有全部权限,由管理员初始化配置信息。
    • 组织实体(已认证):拥有未认证组织实体的所有权利,但已认证的实体通常拥有更多的配额更少的功能限制,此外有些特定的业务功能和业务流程,必须是实名认证的实体才能使用,比如支付和交易。
    • 个人实体(未认证):在个人实体的模式下,享受的权利由具体的业务系统决定,原则上个人实体作为独立的账户类型,应该享有基本的功能权限和数据权限,如个人中心的各项功能等。
    • 个人实体(已认证):与组织实体(已认证)类似。
    • 个人实体(未从属于组织):未从属组织的个人实体账户,与上述个人实体类型一致。
    • 个人实体(从属单个组织):从属单个组织的个人实体账户,除了具备个人实体账户的原本权利外,还受到组织权限的约束,原本个人实体不享受的权利,可能现在可以享受,原本享受的权利,可能现在不可以享受了。
    • 个人实体(从属多个组织):当个人实体账户从属于多个组织时,除了个人账户原本拥有的权利外,所从属的组织所带来的权利须遵循『组织实体隔离原则』,且受到『从属关系隔离原则』的约束,具体的权利配置由各个业务系统独立管理。这里有两种情况:一是在用户登录时,必须选择所属的组织机构,类似于 LOL 游戏,在登录时须选择所属的区域和服务器;二是在用户登录后,可以自由选择组织实体,类似于阿里云或华为云的区域选择,在用户未选择所属组织时,应当按照未从属于组织的个人实体账户对待。
    • 组织管理员:组织管理员拥有该组织内部的全部资源权限,例如可以创建个人账户,在个人未完成首次登录前,可以删除(解雇),修改,在个人完成登录后,则权限移交给了个人;删除(解雇)时,只是个人脱离组织,个人不再拥有组织员工的权限,在组织内的个人工作经历仍然保留,组织清除离职员工,则这些在职经历将不为企业可管理,但个人自己可见,不可变更。

    5. 用户分类
     

    用户分类
    用户分类

     

    6. 组织分类

    组织分类
    组织分类

    三、基础信息模块

    基础信息,主要针对个人实体和组织实体,如企业工商信息、通用信息等要满足灵活扩展的需求,实体的类型种类繁多,随着业务场景的变化,信息结构的变化也可能比较频繁。在技术上建议采用以下两种方式应对:

    1. EAV 数据模型

    EAV 即 Entity(实体)-Attribute(属性)-Value(值)数据模型,将传统的 ORM 映射模型——即实体属性与数据库表字段一一对应的模型,变换为实体属性与数据表的行记录一一对应的模型。EAV 模型大大增加了数据映射和相关业务逻辑的复杂程度,但是具备高度的灵活性,能够满足随时变化的信息结构,满足动态变更的实体结构、满足字段级权限控制、满足字段级数据版本历史等功能。

    2. 采用松散型数据结构的数据库方案

    其中的代表便是 MongoDB:一个介于关系数据库和非关系数据库之间的分布式文件存储数据库产品,在 CAP 理论中属于 CP 范畴,支持松散数据结构,支持复杂的混合数据类型,支持 JSON 和文档存储。采用此方案的优势比较明显,除了能够满足 EAV 模型所具备的大部分功能外,还大大简化了技术复杂度,支持分布式部署,推荐采用此方案。

    3. 信息分类

    平台的信息主要分为基础信息和业务信息两大类。基础信息分为个人实体信息和组织实体信息,主要描述实体的基本信息、通用信息,与业务相关性不大,例如姓名、性别、身份证号码、手机号码、企业通用信息、企业工商信息等。业务信息由各业务系统自行管理和维护,UIMS 不涉及。

    实体类别信息类别信息范围备注
    个人信息基础信息昵称、性别默认公开
    个人信息基础信息身份证信息、籍贯、性别、出生日期、学历、工作履历、电话号码、通信地址、照片、银行卡号须用户授权收集和公开
    个人信息业务信息LBS数据须用户授权收集和公开
    个人信息业务信息用户移动终端的设备信息,包括IP地址、Mac地址、操作系统信息、设备型号、识别码等须用户授权收集和公开
    个人信息业务信息用户的行为信息,包括操作记录,cookies,通过平台编辑或传送的文字、图片、语音或视频信息等须用户授权收集和公开
    个人信息业务信息用户喜好、特长、手工标签、自动标签、社交互动信息等须用户授权收集和公开
    组织信息基础信息组织工商信息:名称、法人、营业范围、注册日期、注册资本、通信地址、工商注册号、公司类型、纳税人识别号默认公开,自动审核
    组织信息基础信息组织介绍、品牌介绍、微信公众号、企业官网、对外联络电话、客服电话默认公开,须人工审核
    组织信息基础信息企业资质、股权结构、对外投资、工商登记变更记录、企业年报、公司发展历程、行政许可须组织授权收集和公开
    组织信息基础信息核心团队和成员、融资历程、核心产品、公司规模、知识产权须组织授权收集和公开
    组织信息基础信息组织架构、组织成员档案、司法风险、法律诉讼须组织授权收集和公开

    所有与信息收集、储存、处理及数据安全有关的书面政策,应当出具《隐私政策》并进行声明。部分组织信息由于可在网上公开查到,且是法定必须公布的信息,因此可以默认公开。

    四、其他功能

    一)软件授权

    基于两级账户体系,建立云平台付费授权机制,针对用户账户和组织账户进行独立授权。根据产品的商业策略,可执行灵活的付费模式:

    • 时效限制:年付、季付、月付,不同时效费用不同。
    • 功能限制:授权不同的功能,费用不同。
    • 数量限制:最大组织数量限制、最大用户数量限制,不同的数量费用不同。

    二)组织入驻

    UIMS 应提供一个组织实体注册登记的流程,允许组织主动提交基本信息,开户入驻平台。此外,应提供在管理后台手工录入组织开户的功能。

    三)实名认证

    分为个人账户实名认证和组织账户实名认证,尽量通过技术手段自动执行实名认证的审核过程,减少甚至取消人工干预。UIMS 应提供实名认证的功能和流程。

    四)资质审核

    资质审核分为两部分:一是部分实体实名认证过程中的人工核查;二是对实体提交的额外资质进行技术或人工审核。

    五)组织绑定

    基于『从属关系隔离原则』,个人账户应在具体的业务系统中绑定组织账户,绑定过程分为两种类型:一是由组织管理员手工创建的从属个人账户,另一个是个人账户申请加入某个组织。业务系统应该提供此功能和流程。例如,个人注册帐号后,可主动登记绑定组织,对已注册登记的组织则要该组织管理员审核,未在系统中注册登记的组织,则始终处于待审核状态。

    六)组织解绑

    允许个人账户解除与组织之间的从属关系。解绑分为两种情况:一是个人账户主动解除关系,二是组织管理员解绑、解雇或清除雇员(个人账户)。其中第一种个人解绑的,应当由组织进行审核批准,个人申请解除绑定关系,组织进行审核,但是是否需要审核,应交由具体的业务系统自行决定。

    七)间接雇佣(从属)关系

    雇佣(从属)关系分为直接雇佣与间接雇佣关系。例如保安员在某保安公司入职(直接雇佣),在某物业作保安(间接雇佣)。考虑两种办法标识间接雇佣关系:

    • 增加服务单位(项目点、物业社区)的实体概念
    • 利用组织内部的组织机构体系,将间接雇佣单位作为当前组织的分支机构进行处理。

    八)账户注销

    分为个人账户的注销和组织账户的注销。UIMS 应提供相应的页面完成账户注销的操作。

    九)私有化部署

    原则上拒绝私有化部署,但对于特定的客户,考虑私有化部署。私有化部署须考虑版本升级问题,在软件架构设计时,尽量遵循业务系统和技术系统分离的原则,并抽离公共模块,最大限度为私有部署的版本提供升级服务。

    五、总结

    总体来说,统一身份管理系统要做的事情有这么几件:

    • 定义实体
    1. 业务系统实体
    2. 服务账户实体(客户端)
    3. 组织实体
    4. 组织架构
    5. 个人实体
    6. 角色实体
    7. 权限标识
    8. 资源标识
    9. 条件标识
    • 处理上述各实体之间的关系,并提供数据结构
    • 提供鉴权 APIs 和业务 APIs
    • 提供其他功能:统一注册功能(页面和流程)、统一登录功能、软件授权
      、组织入驻、组织绑定/解绑、资质审查。

    转自:https://www.jianshu.com/p/990d8acfdb69

    参考:http://www.ruanaaly.com

    展开全文
  • 概要介绍:历经一个月的时间,Debug亲自撸的一套“企业中台系统”终于完成了,课程全名为“springboot2.0企业中台实战之权限统一管理与应用统一授权(dubbo+zookeeper分布式系统实战)”,正如字面意思,本课程讲解的...

    概要介绍:历经一个月的时间,Debug亲自撸的一套“企业中台系统”终于完成了,课程全名为 “springboot2.0企业中台实战之权限统一管理与应用统一授权(dubbo+zookeeper分布式系统实战)  ”,正如字面意思,本课程讲解的是一个真正意义上的、企业级中台系统的实战,是一套真正践行“中台思想”、“分布式系统/服务开发与通信”的项目(画外音:目前全网还没有关于中台系统的课程实战哦!学习链接:http://www.fightjava.com/web/index/course/detail/13

    课程内容:本课程是一门具有很强实践性质的“项目实战”课程,即“企业中台系统实战”,其中主要包含三大块核心内容,如下图所示:

    即主要包含以下三大块内容:
    ① 企业内部应用系统菜单资源和操作权限的统一管理;

    ② 分布式应用系统通信时的统一授权,即基于AccessToken的授权与认证;

    ③ 分布式服务/系统通信时的两大方式(基于dubbo rpc协议和基于http协议的restful api实战)。

     

    值得一提的是,这套中台系统由于讲解了如何统一管理企业内部各大应用系统的“菜单资源列表”、“操作权限”,故而本门课程的“代码实战”是建立在之前debug录制的“企业权限管理平台”这套课程的基础之上的,故而在这里debug建议没有项目开发基础的小伙伴可以先去学习我的那套“企业权限管理平台”的实战课程,之后再来学习我的这套中台系统的实战才不会很吃力(课程链接:http://www.fightjava.com/web/index/course/detail/8 )

    本课程的课程目录以及课程大纲如下两张图所示(详细的课程目录可以参见文末!):

    除此之外,这套“中台系统”由于统一管理了企业内部各大应用系统的“菜单资源和操作权限”以及“应用系统之间通信时的统一授权”,故而难免需要涉及到“中台系统”与“中台子系统”、“中台子系统”与“中台子系统”之间的通信(即分布式服务之间的通信),在这里我们是采用“dubbo + zookeeper”的方式加以落地实现的,详情如下图所示:

    而众所周知,作为一款知名以及相当流行的分布式服务调度中间件,dubbo现如今已经晋升为Apache顶级的开源项目,未来也仍将成为“分布式系统”开发实战的一大利器,如下图所示为dubbo底层核心系统架构图:

    而在这门“中台系统实战”的课程中,我们也将始终贯彻、落地dubbo的这一核心系统架构图,即如何将中台系统开发的服务注册/发布到注册中心zookeeper,中台子系统如何订阅/消费/调度中台系统发布在zookeeper的接口服务,中台子系统在走http协议调度通信时dubbo如何进行拦截、基于token认证接口的调用者等等,这些内容我们在课程中将一一得到代码层面的实战落地!

    下图为本课程中涉及到的分布式系统/服务之间 采用“http协议restful api”方式通信时的Token授权、认证的流程图:

    而不夸张地说,基于AccessToken的授权、认证方式在现如今微服务、分布式时代系统与系统在通信期间最为常用的“授权方式”了,可想而知,掌握其中的流程思想是多么的重要!

    以下为本门课程的部分截图:

     

    核心技术列表

    值得一提的是,由于本门课程是一门真正介绍“中台思想”以及将“中台思想”和“分布式系统开发实战”相结合落地的课程,故而在学完本门课程之后,可以掌握到的核心技术自然是相当多的。主要由SpringBoot2.0、SpringMVC、Mybatis、Dubbo、ZooKeeper、Redis、OkHttp3、Guava-Retrying重试机制、JWT(Json Web Token)、Shiro、分布式集群session共享、Lombok、Stream API、Dubbo-Filter以及ServiceBean等等。如下图所示:

    课程收益

    (1)了解并掌握中台的思想及其如何在项目中落地,并基于微服务SpringBoot2.0和分布式系统架构相关技术栈加以实现;

    (2)掌握分布式系统架构的设计、业务需求分析、代码实战以及分布式服务通信相关的技术栈;

    (3)掌握分布式服务调度Dubbo+ZooKeeper的基本开发技术栈、Redis、分布式Session共享、Guava_Retrying重试机制、组件JWT、OkHttp3等核心技术栈;

    (4)掌握分布式系统中服务与服务之间是如何通信、拦截过滤url以及认证Token的;除此之外,分布式系统架构代码性能优化也可以从本课程中学到!

    (5)掌握分布式系统在撸码开发实战过如何进行断点调试、Bug排查以及性能优化

    (6)可用于毕业设计、Offer敲门砖以及升职加薪利器

     

    以下为本课程对应的详细课程目录(共63个课时)

    一、课程整体介绍

    1-1课程介绍与整体收益

    1-2中台思想介绍与系统整体演示

    1-3核心技术列表

    1-4课程学习要求、工具和建议

    二、应用中台实施之权限管理平台改造

    2-1回顾企业权限管理平

    2-2数据库表设计

    2-3菜单列表查询

    2-4新增和修改菜单

    2-5角色列表查询

    2-6新增修改角色

    2-7性能优化之Redis预缓存系统编码列表一

    2-8性能优化之Redis预缓存系统编码列表二

    三、应用中台实施之Dubbo服务开发与发布

    3-1整合Dubbo和ZooKeeper发布服务

    3-2用户登录服务接口开发

    3-3完成用户登录服务接口开发与自测

    3-4用户菜单资源和操作权限服务接口开发与发布一

    3-5用户菜单资源和操作权限服务接口开发与发布

    3-6修改密码服务接口开发与发布

    3-7来个小小的总结

    四、CRM客户关系管理系统(基于RPC协议实战篇)

    4-1 项目与数据库的快速搭建一

    4-2 项目与数据库的快速搭建二

    4-3 整合Dubbo和ZooKeeper

    4-4 用户登录认证功能

    4-5 用户登录认证功能收尾

    4-6 获取用户授予的菜单资源

    4-7 订单管理模块之订单列表分页模糊查询功能

    4-8 订单管理模块之剩余功能模块分页查询功能

    4-9 获取当前用户授予的操作权限一

    4-10 获取当前用户授予的操作权限二

    4-11 修改用户密码

    4-12小小的总结

    五、CRM客户关系管理系统(基于Http协议Rest API实战篇)

    5-1 必要性介绍

    5-2 整合网络通信框架OKHttp3

    5-3 开发通用的Http通信服务类

    5-4 功能改造之用户登录一

    5-5 功能改造之用户登录二

    5-6 功能改造之获取用户授予的菜单资源与操作权限

    5-7 小作业之修改密码服务改造

    5-8 整体进行回顾与总结

    5-9 问题的揭露

    六、应用授权中心实战

    6-1 问题分析与解决方案介绍

    6-2 数据库表设计

    6-3 开发创建AccessToken的方法并发布为Dubbo服务

    6-4 基于JWT(Json Web Token)创建AccessToken

    6-5 创建拦截器拦截相应的URL并认证AccessToken一

    6-6 创建拦截器拦截相应的URL并认证AccessToken二

    6-7 基于Dubbo Filter + ServiceBean拦截请求URL一

    6-8 基于Dubbo Filter + ServiceBean拦截请求URL二

    6-9 基于Dubbo Filter + ServiceBean拦截请求URL三

    6-10 中台子系统CRM获取授权AccessToken

    6-11 回顾与总结

    七、性能优化实战篇

    7-1 分布式集群Session共享

    7-2 项目启动完毕Redis预缓存AccessToken

    7-3 线程池多线程定时任务调度缓存AccessToken

    7-4 被动缓存AccessToken

    7-5 Guava-Retrying重试机制一之实战初探

    7-6 Guava-Retrying重试机制二之重试缓存Token

    7-7 Guava-Retrying重试机制三之异步重试缓存Token

    7-8 Guava-Retrying重试机制四之重试次数已到则邮件通知

    7-9 小作业之中台缓存用户每个子统的菜单资源和操作权限

    7-10 总结

    八、课程总结

    8-1 小作业与建议

    8-2 回顾与总结

     

    值得一提的是,本课程属于收费课程(毕竟是debug呕心沥血亲自撸出来的),为了低门槛可以让各位小伙伴学到更多的技术,现在关注公众号后,即可享受79元的优惠价哦!没错,确实只需要79、79、79(重要的事情说三遍)!

    感兴趣的小伙伴可以联系debug,联系得越早,优惠将越多哦!(建议各位小伙伴可以购买跟本课程相关的套餐,一是学习起来更有针对性、不吃力,二是价格更便宜!)而且,目前全网还没有关于中台系统的实战课程,因此想学习的小伙伴要赶紧趁早下手哦,其中,购买本课程的小伙伴将会获得本课程完整的视频教程、系统源代码数据库、课件PPT以及其他相关的工具跟资料(不感兴趣的小伙伴可以直接跳过)!

    结语:最后,debug希望大家拿到本视频教程以及资料后,可以静下心来学习、研究、撸码与实战,debug相信学习完本课程之后,将能更好地巩固诸位小伙伴的知识体系,尤其是在企业级应用开发中将可以胜任诸多开发任务(涨薪我觉得应用木有啥问题了)!而且,学习本课程后,也能给诸位小伙伴的简历、面试提供一些帮助哦!还等什么呢,赶紧拿起手机添加网站底部Debug的微信或者QQ进行交流吧!!

    展开全文
  • gateway-统一权限-认证

    千次阅读 2022-04-09 22:20:36
    **权限:**属于系统的安全范畴,权限管理实现对用户访问系统的控制,按照安全规则或者安全控制策略用户可以访问而且只能访问自己被授权的资源,主要包括用户身份认证和请求鉴权两部分,简称认证鉴权 认证判断一个...
  • 业务中台--系统权限管理简介

    千次阅读 2020-08-03 18:27:57
    笔者曾负责过若干种后台系统的搭建,其中都绕不开“权限管理”,现愿意将我个人经验和工作中所产生的的思考与大家进行分享。 1. 权限系统是什么 一句话概括,我个人认为权限系统就是:明确操作人员可在平台内能...
  • 在行业中使用Python进行web开发,同样也是非常受欢迎的,例如:FaceBook,豆瓣,知乎,饿了么等等,本文主要是介绍是利用Python进行web开发企业统一用户认证和权限控制平台,提供用户管理、认证和权限接入的能力,...
  • 一、RBAC模型 1.1、概念 权限设计最常见的就是...在 RBAC 中,权限与角色相关联,用户通过成为适当角色的成员而得到这些角色的权限。RBAC 中有4个比较关键的元素:用户 – 角色 – 权限 – 资源。 1.2、 RBAC 支持
  • Bootstrap3制作,内置系统设置,上传管理,权限管理,模块管理,插件管理等功能,独有的Builder页面自动生成技术节省50%开发成本,先进的最终开发的支持让开发成本一降再降,致力于为个人和中小型企业打造全方位PHP...
  • 业内在用户统一身份认证及授权管理领域,主要关注 4 个方面:集中账号管理(Account)、集中认证管理(Authentication)、集中授权管理(Authorization)和集中审计管理(Audit), 简称 4A 管理。后来发展了 IAM...
  • 后台权限管理系统

    千次阅读 多人点赞 2021-07-31 00:54:00
    CommonAdmin是一个按钮级别权限管理平台,包含企业后台最常用的系统模块,代码简洁,开箱即用。 访问地址:https://gitee.com/caochenlei/common-admin 主要功能 登录功能 部门管理 用户管理 ...
  • 通过企业邮箱管理权限可以实现: A、邮件分类过滤及监控:管理层可对重要部门邮件进行全程或有条件的监控,确保机密数据安全;对员工或部门级收发的邮件可以全程跟踪监控 B、有条件的对用户发件人地址、收件人地址...
  • shiro、基于url权限管理、超详细

    万次阅读 多人点赞 2018-10-14 15:27:38
    如果需要本篇博客内容的代码!请到我的博客下载中心... 只要有用户参与的系统一般都要有权限管理权限管理实现对用户访问系统的控制,按照安全规则或者安全策略控制用户可以访问而且只能访问自己被授权的资源。 ...
  • 集中权限管理(单点登录)、内容管理、支付中心、用户管理(支持第三方登录)、微信平台、存储系统、配置中心、日志分析、任务和通知等,支持服务治理、监控和追踪,努力为中小型企业打造全方位J2EE企业级开发解决...
  • Shiro权限管理框架详解

    千次阅读 2019-06-17 16:23:23
    1权限管理1.1什么是权限管理 基本上涉及到用户参与的系统都要进行权限管理权限管理属于系统安全的范畴,权限管理实现对用户访问系统的控制,按照安全规则或者安全策略控制用户可以访问而且只能访问自己被授权的...
  • 特别是对于中大型企业来说,在复杂的商业环境下,IT人员不仅要管理内部员工,还有大量的合作伙伴,供应商等多种类型人员需要进行身份信息和权限管理。因此,不同类型的大量人员和组织架构信息分布在不同的系统中,...
  • 通过企业门户网站,将企业总部、分支机构和各部门不同的人员集成在一个统一的工作环境中,不同的人员根据不同的权限获得不同的信息,通过人员权限的设置完全解决了下级对上级隐瞒信息或信息传递不
  • 一款 PHP 语言基于 ThinkPhp6.x + Layui + MySQL等框架精心打造的一款模块化、插件化、高性能的前后端分离架构敏捷开发框架,可用于快速搭建前后端分离后台管理系统,本着简化开发、提升开发效率的初衷,框架自研了...
  • shiro教程(1)-基于url权限管理

    万次阅读 2017-03-30 22:31:28
    一、 权限管理 1.1 什么是权限管理 基本上涉及到用户参与的系统都要进行权限管理权限管理属于系统安全的范畴,权限管理实现对用户访问系统的控制,按照安全规则或者安全策略控制用户可以访问而且只能访问自己被...
  • Shiro权限管理详解

    千次阅读 2018-08-04 18:12:30
    权限管理1.1 什么是权限管理 基本上涉及到用户参与的系统都要进行权限管理权限管理属于系统安全的范畴,权限管理实现对用户访问系统的控制,按照安全规则或者安全策略控制用户可以访问而且只能访问自己被授权...
  • 企业管理系统一般包含后台管理UI、组织机构管理、权限管理、日志、数据访问、表单、工作流等常用必备功能。下面收集的几款优秀开源的管理系统,值得大家入门学习。如有新的优秀项目,我会不断补充。 开源项目是...
  • 企业管理Mac电脑的三种方式

    千次阅读 2016-02-04 18:12:30
    虽然Mac电脑很少见,但也成功走入IT企业。IT必须找出与现有Windows Active Directory域整合的解决方案,并且确定所需的工具或系统。 确定如何将Mac电脑整合到Windows基础设施不是一个简单的任务,应该明确需要...
  • 基于url权限管理

    千次阅读 2017-09-27 14:04:15
    基本上涉及到用户参与的系统都要进行权限管理权限管理属于系统安全的范畴,权限管理实现对用户访问系统的控制,按照安全规则或者安全策略控制用户可以访问而且只能访问自己被授权的资源。 权限管理包括用户身份...
  • saas,云端开发,企业管理,业务审批
  • IDM统一认证功能说明

    千次阅读 2021-02-09 10:11:01
    公司实现了统一身份认证功能后,就相当于景区的通票,登录所有的应用系统时只需一次验证,之后就可以进入任何有权限进入的应用系统,这就是单点登录的概念。 通过IDM统一身份管理平台实现的各个业务系统的单点登录...
  • 后台系统设计——角色权限

    千次阅读 2021-02-19 19:48:53
    一、前言 不论是哪种后台管理系统,“人员权限”始终是绕不开的话题。...譬如,做企业使用类软件,不同部门、不同职位的人的权限是不同的;再例如一款收费产品的收费用户和免费用户权限也是迥然不同

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 29,412
精华内容 11,764
关键字:

企业统一权限管理中心