前言:在邮件系统建设规划阶段,需要考虑的一个重要问题是系统中的用户账号如何管理。数据源从哪里来?后续的用户增、删、改该如何维护?带着这些问题,让我们来探讨一下针对邮箱账号管理当前可行的解决方案。
我们可以从下面几个问题着手分析一下现状:
- 企业当前是否已有邮件系统?
- 当前邮件系统中的用户是如何管理的?
- 企业是否有统一管理用户的系统?
- 当前用户管理存在哪些问题?
- 项目预算多有多少?
…
只有充分了解现状,才能做进一步的规划。
根据项目实际经验,用户账号管理模式大概有下面两种:
- 邮件系统中的用户账号由管理员手动维护管理。
- 邮件系统中的用户账号由上游系统统一维护管理。
下面分别介绍这两种管理模式。
邮件系统独立管理用户账号的情况在早些年比较常见。受制于当时的信息化建设水平,很多业务系统都采用单独管理账号的方式,形成了多个信息孤岛。随着企业信息化建设水平的提高,目前采用独立管理用户的模式也在逐渐减少。不过当前仍有大量企业采用这种模式。采用这种模式最大的缺点是管理维护的工作量比较大,而且容易出现管理疏漏。优点是不需要集成对接,成本较低。
用户及组织管理可能涉及的功能
当前主流的商业邮件系统均提供了独立的用户账号管理功能,通常是以web可视化界面进行管理。提供的功能包括:
组织架构的维护
组织架构的维护包括组织架构的增加、删除、修改;支持可视化管理层级架构等。
单个用户账号的维护
单个用户账号的维护包括在可视化界面增加、删除、修改账号。支持的账号属性包括:姓名、状态、所属部门、别名、手机号等信息。
批量导入用户账户
可以通过外部数据源手动批量导入账号。通常通过excel表格、csv文件的形式批量导入用户账号及其相关属性。
批量维护用户账号
包括对用户账号批量删除、批量修改用户属性、批量禁用等。
上游系统统一维护用户账号
所谓的上游系统包括LDAP、Active Directory(AD)、人资系统、统一身份系统等。可以简单理解邮件系统需要从这些外部数据源获取用户和组织机构的信息。通常采用拉取或者推送方式实现。
上游系统和邮件系统的交互方式
这种方式通常叫做被动获取。邮件系统通过调用上游系统的接口定时获取组织架构和用户的变动情况,然后进行相应的处理。当上游系统是LDAP、AD、中间表时通常采用这种方式。主流的邮件系统标准化产品即可支持这种方式,无需再做二次开发。这种方式的优点是开发成本较低,对接相对容易。缺点是无法实时获取上游系统的变化,只能采用定时处理的方式。
上游系统向邮件系统推送的方式
某统一身份管理系统的架构展示
这种方式通常适用于企业已经建设了统一身份管理平台系统,其他业务系统均通过该平台进行账号统一维护。通常情况下,邮件系统需要按照上游系统的接入规范开发接收接口,一般至少需要开发用户和组织两个接收接口。邮件系统收到上游系统发来的数据后在本地对用户和组织进行相应处理。也存在一些特殊情况,需要上游系统调用邮件系统的API接口进行用户和组织的推送。
不管是采用哪种管理方式,在实际的应用场景中账号管理还面临诸多困难,典型困难如下。
这种问题常见于邮件系统建设比较早,系统建设之初对账号管理不规范的企业。在后续建设统一身份管理平台时就会面临账号不一致的问题。想解决这种问题没什么特别便捷的方式,只能对当前邮箱账号进行梳理比对,和统一身份管理系统的账号进行关系对应。通常这个过程会比较艰难,而且很容易出现账号对应关系错误的情况。
在邮件系统中也会存在一些特殊的属性信息,比如用户的别名、默认发信账号等。这些信息一般在上游系统是不存在的,也不方便在上游系统进行管理。这就可能需要管理员进行手动维护。
邮箱账号的管理规划在邮件系统建设初期尤为重要,企业应根据自身情况进行统一规划,尽量避免出现信息孤岛问题。
未标注来源的文章均为原创作品,版权所有,转载请注明出处。非原创文章均已标注来源,如有侵权请告知。
如您喜欢本站,可以收藏加关注(扫码关注右上角微信公众号mailabc)。