JDE 用户权限管理的一些思考

JD Edwards EnterpriseOne Release 22应用程序增强功能详解(下)
2021年11月15日
JD Edwards EnterpriseOne 财务凭证工作台
2022年1月6日

首先声明一下,本文不是对 JDE 用户权限的设置培训,不会讨论 JDE 的各种权限具体如何设置。如果您是 JDE 初学者,请参加埃林哲公司的 JDE 用户权限培训或者到 Oracle 官网查询相关资料。

在很多 JDE 项目实施过程当中,用户的权限控制一直是一个容易被忽视,但其实又非常重要甚至是比较复杂的项目任务。

JDE 系统本身来说是一个非常开放且非常灵活的系统,甚至是说,对于一个用户而言,我们只需要为其创建建好账号,用户就能够使用 JDE 系统的绝大多数功能。 这就给人一种错觉,仿佛 JDE 系统的用户权限设置非常简单,甚至是可有可无的。

就笔者的经验,在很多项目里面都发现有这样的情况,很多项目经理,甚至是一些资深的项目经理,都对JDE 的用户权限不甚了解,当然也有一些是由于项目周期和成本的原因,不愿意在这方面花费太多的资源。 想想也是啊,建个账号就可以运行所有程序了,那我何必自找麻烦,限制用户运行这个运行那个,临到快上线了还有用户排队要求开这个程序权限那个处理选项的权限,搞不好最后还影响用户对项目的满意度。

但事实上,项目初期对用户权限的忽视会给后期的运维带来非常大的痛苦和隐患。 我曾经看到过客户花了巨大的成本进行系统权限的重新改造和实施,看到过客户不得不自己开发个软件来设置用户权限,更看到很多客户由于权限控制的混乱被内审、外审挑战。

本文试图从以往的一些项目经验和教训,吸取国外一些专业设置 JDE 权限的软件背后的理念,来阐述一下一个好的 JDE 用户权限设置策略应该是怎样的,尽量接地气,不讲大道理。

不只是CNC 的事儿!

是的,我要强调一下,特别是在项目上,很多项目经理总认为用户权限设置是 CNC 的任务, 其实不是的。

想想也知道啦,CNC 怎么会清楚客户有多少岗位,有多少业务流程,财务过账需要走哪些程序,AR、AP 流程有哪些控制点,是吧?

所以,一个很自然的结论就是:

每个模块的应用顾问应该负责收集本模块的用户角色以及在系统内设置用户角色的权限。

如果一个 JDE 应用顾问不会设置 JDE 的用户权限,我觉得他不是一个合格的应用顾问。

那个 CNC 顾问做什么呢?

1. 用户权限的基础设置,比如 LDAP 集成认证、SSO、启动长用户名密码、 *PUBLIC 权限、

UDO 等等。

2. 定义用户、角色命名规则

3. Trouble Shooting

在埃林哲的 JDE 系统实施方法论中,是专门有“用户安全性设置”这样一条任务线的,CNC 可以作为这条“线”的“线长”来 Lead 这件事情,但是具体实施应该是由每个模块的顾问来负责。

忘掉菜单过滤吧!

不知道从什么时候开始,项目上开始流行把菜单过滤做为用户权限设置的手段。 这可能还是和模块顾问的习惯有关系吧。因为传统上,模块顾问要负责为客户设计菜单,那么顺手把菜单过滤也做了,似乎合情合理。

但事实上,你去查 Oracle 的文档,从来都没有把菜单过滤作为用户权限控制的一种手段, 这是为什么呢? 原因就是因为:

1. 菜单过滤作为权限控制手段,漏洞太大!

2. 菜单过滤针对多角色冲突的处理与 P00950 里面针对多角色冲突的处理是有着非常大的矛盾的。

针对第 1 点,了解JDE 的人都知道,JDE 绝大多数交互式应用程序都有着各式各样的 Form Exit 和 Row Exit 按钮以及程序界面上还有各种按钮。 通过这些按钮就可以跳到其它应用程序,根本不需要走菜单。

针对第 2 点,从技术角度解释起来就比较复杂了。举个例子吧,如果有个角色是用来控制该用户只能看到 A 公司的数据,那么本质上它是不需要做菜单过滤的,而另一个角色是用来控制用户只能操作应收账款的程序的,给它设置上菜单过滤。 当一个用户同时拥有这 2 个角色的时候,他登录系统看到的菜单是过滤后的菜单吗?不是!他看到所有菜单!

所有综上所述,把菜单过滤作为用户权限作为控制手段是不合适的。 事实上,针对新版本的 JDE,我建议用 E1 pages 搭建流程式的页面,既能直观的反映业务流程,又能避免菜单过滤的“陷阱”,而且还足够简单。你唯一需要做的,就是拿起书,学习一下怎么做 E1 pages, 大概也就半天时间吧。

JDE 传统菜单和E1 Page 的对比-传统JDE菜单
JDE 传统菜单和E1 Page 的对比-E1 Page菜单

先关后开!

传统上,JDE 秉持的是“没有设置安全权限就是允许”的原则。 这固然是灵活性的体现,但是针对这样一个有着几千个程序对象的应用系统而言,老实说,我觉得有点太大大咧咧了。那么,既然默认所有程序都是开放的,你去一个一个关吗?天啊,那什么时候项目才能上线? 而且,F00950 这张表得有多大啊。

这里就要用到 JDE 的 *PUBLIC 这个特殊角色了。*PUBLIC 是 JDE 里面最低权限的角色,通过对 *PUBLIC 角色设置对于*ALL 的程序进行关闭,就可以轻松实现“先关后开”的目的。 当然,有些低敏的程序也还是可以在*PUBLIC 上开给所有用户的,比如 UDC 查询、更改自己的密码、日历查询等等。

有了*PUBLIC 这一层的保障,我们已经关闭了大多数的程序,那接下来我们只需要针对每个角色考虑它需要开放的程序就行了。其实,每个角色需要开放的程序也没有多少啦,一个角色大概只需要开十几个程序?最多几十个吧。

其实,Oracle 也已经注意到这个“默认所有程序都是开放”所带来的问题,在新版 JDE 引进的

UDO 对象,默认权限就已经改为关闭的了。

怎么样定义角色比较清晰?

“思路决定出路”。在真正实施之前,我们先要想清楚按照什么样的思路去收集、整理和定义用户的角色。

首先,我们可以把 JDE 的角色权限分成 2 大类型:

1. Functional 权限类

主要是指 P00950 里面的 1 类型(Application)和 3 类型(Action)的用户权限,也可以加入 5 类型(Procession Option & Data Selection)等类型的用户权限。所以有时候又被称为“1+3”权限或者“1+3+5”权限。

新版本 JDE 里面带来的 UDO 对象的权限也基本上可以归为这一类权限。

这种类型的权限主要是控制用户能够运行哪些程序以及在这些程序里具体的操作选项。

2. Data 权限类

主要是指 P00950 里面的 4 类型(Row)和 3 类型(Column)的用户权限。所以有时候又被称为“2+4”权限。

这种类型的权限主要是控制用户能够读写哪些公司、MCU、BU 的数据。

Functional 权限类和 Data 权限类是 2 个象限上的权限设置,是不存在冲突的。而 1 个典型用户,应该既有他的 Functional 权限类角色,也有他的 Data 权限类角色。

接下来,我们更进一步思考一下 Functional 权限类角色该如何定义:

传统的,我们定义角色是通过面对面的用户访谈,“你的岗位包含哪些工作啊?”等等,然后把这个岗位包含的工作定义为一个角色,我们称之为“岗位角色(Position Role)”。

然而,岗位是易变的。这会带来角色经常性的变动,维护变的困难。

定义角色的另一种方式是从流程出发,把一个流程定义为一个或多个角色,称之为“流程角色(Process Role)”。

一个流程可以定义出多个流程角色,之间的差别主要是不同的角色在这个流程里面的权限不同。

由于流程的相对稳定性,通过流程定义出来的“流程角色”也会相对稳定。

留个尾巴

先提个建议,建议 Disable Role Chooser。 主要是为了降低复杂性。

事实上,在真正的项目中,还有很多实际的问题需要解决。我举个例子,比如有一个用户, 他在 A 公司担任职位 a,而在 B 公司担任职位 b,A、B 公司在同一个 JPD920 环境里面,那么这个用户的用户权限怎么设计合适呢?

欢迎大家在公众号中回复讨论,期待您的参与!

公众号二维码

发表评论

您的电子邮箱地址不会被公开。 必填项已用*标注