SAP 用户权限学习

一、SAP用户权限架构

SAP用户权限是通过Role(角色)来定义的, 从Role到最低层的最小控制单元Authorization field总共有4层，结构示意图如下.

涉及的常用T-code如下:

SU20

维护authorization field

SU21

维护authorization object(object按object class分类显示)

PFCG

维护role

SU02 / OOPR

维护authorization profile, 这2个code功能完全一样 (已经建议用PCFG)

SU01

维护用户

SUIM

权限检查

 

 

二、自下向上理解权限体系

2.1 Authorization field(权限字段): 权限检查的最小单元 （比如TCD/ACTVT / BUKRS / WERKS / BEGRU等等）.

怎么理解" 权限检查的最小单元" 呢? 所谓的"权限", 就是对某人做某事的限制. 不做事当然就不存在权限；没限制随便做当然也不存在权限。设想如下这个场景: 有一个CSR (客服) 要负责输客户订单. 那就产生了很多疑问:

1. 公司有很多客户，允许这个CSR输入哪些客户的订单?
2. 公司有多个company code, 允许这个CSR为哪(些)个company code输入订单?
3. 公司分多个销售团队区域，允许这个CSR为哪(些)个销售团队输入订单?
4. 订单分多个类型（正常订单/寄售订单/红冲订单…）, 允许这个CSR输入哪些类型的订单?
5. 订单创建后, 允许这个CSR"批准"这个订单吗？允许这个CSR查看这个订单吗？允许这个CSR删除这个订单吗？ 也就是说， 这个CSR能对订单做哪些"动作"？（无疑问，CSR至少需要"创建"这个动作）
6. ……

 

以上每一个疑问，推演到最终的需要并且可以做最终决断的对象，就是authorization field. 比如允许输入哪些客户的订单, 可以用Account No来决定，这时account no就成了authorization field. 同理，对于可以为哪些"销售团队"输订单，由于"销售团队" 又依赖于sales organization / distribution channel / product division等，所以需要再分解到最终做决定的信息元素，才成为authorization field.

 

可以通过 SU20 查看系统中的权限字段定义. 两个比较特殊的字段是TCD和ACTVT. TCD代表T-code; ACTVT代表"动作".

每一个authorization field都有对应的值域，也就是所有可能的值.

 

如下图: 运行T-Code SU20后，在列出的authorization field列表中找到ACTVT字段, 双击打开, 可以看到ACTVT权限字段的细节:

可以看到ACTVT的值表存在TACT表中. 用T-code SM30查看表内容 (不是所有的表都能通过SM30查看),. 如下图,可以看到IDES中定义了198种"动作"

 

同时我们也可能注意到，在SU20中查看authorization field时，也可以看出该field在哪些authorization object中用到了.

 

 

2.2 Authorization Object(权限对象): 权限字段的集合(1~10个), 这些权限字段会被同时检查.

Authorization object class(权限对象类别):

如下图: 权限对象M_RECH_BUK 包含2个权限字段(BUKRS/ACTVT); 而C_DRAW_BGR只包含BEGRU一个权限字段

 

同一authorization object下的各个authorization field相互之间是AND (与) 的关系

 

可以通过SU21 查看权限对象包含哪些权限字段.

 

 

2.3 Authorization(权限): . 当对authorization object 中的每一个authorization field都具体地做了设置(限定)后，就形成了一个authorization。所以Authorization是authorization object的实例。

如下图, 每一个黑框就构成一个authorization.

Authorization field可能有多个值，但是在一个具体的authorization object中，其取值可能会有限制。例如 ACTVT是最常用的一个权限字段. 在不同的authorization object中, ACTVT能使用的值是不同的. 在TACTZ表中存储了每个权限对象允许的ACTVT值. (其它authorization field也许会有类似情况)

  

 

 

 

 

2.4 Authorization profile（权限概况）: authorization profile是authorization的集合.

 

当然也可以换个角度理解. 认为authorization profile是authorization object的集合, 而且这些authorization object都已经实例化(同一authorization object可以有多个实例). 这样理解起来可能更容易.

 

事实上, authorization 本身是不能单独存在的， 它依附于authorization profile. 也就是说，虽然从架构上authorization profile下挂authorization, 但是并不是生成所有的authorization，然后分别给个代码，然后用这些authorization代码去组成authorization profile. 为什么呢？因为authorization的数量是天文数字.

如上图中的B_USERST_T这个authorization object, 包含4个authorization field. 每一个field可能的取值等于2ⁿ -1 , n是该field允许值的个数. 即使每个field 只有3个值, 那么也会形成2401个可能的authorization . 当一个field增加一个值时，结果就以指数级别增长。所以是不可能先定义出各个authorization, 给以编号， 然后再用这些authorization组合成authorization profile的.

 

可以用Tcode SU02查看 profile的细节. 如下图, profile T-E1550950包含11个authorization. 注意每个object的authorization的代码就是profile名称后再加2位的识别码(也就是说: 同一个object允许有100个authorization)

 

 

每个authorization的细节可以双击后看到, 如下图:

 

如果同一个authorization object有多个实例(authorization), 那么这些authorization之间是 OR 的关系.

一个authorization profile下的不同的authorization object间应该是 AND 关系

 

Authorization profile是真正控制权限的最高元素. 但是感觉SAP现在更愿意仅把它做为后台的技术手段，在前台， SAP希望用Role(角色) 来处理。

 

Role (角色): Role定义一个SAP用户(user)的活动。一个Role可以生成一个Authorization profile。 除了authorization profile外, Role同时可以指定用户的菜单显示等其它信息.

 

可以用Tcode PFCG 维护Role, 如下图. 可以看出Role与profile的一一对应关系.

在 "Authorizations" 这个选项卡中, 就是一个结构化的authorization列表，也就是profile. 这个列表是按authorization class分类的. 它与从Tcode SU02中看到的profile的清单式的列表在内容上是完全一致的.如下图

 

前面讲authorization profile时说， 可以把authorization profile理解成authorization object的集合，但是是实例化的object. 这个理解有两个部分，而且是有先后次序的，但实际上是不能拆分的。

对于Role, 如果不考虑到Role的其它部分, 仅从权限这个角度，则完全可以同样理解，而且更妙的是： role确实是authorization object的集合. 而可以把authorization profile看成是role的实例.

 

一个role, 在没有生成authorization profile时(也就是没有实例化), 它已经包含了authorization object. 如下图, role SAP_AUDITOR_A 尚未生成profile:

 

但是, 在authorizations中可以看出它包含的authorization objects, 如下图. 注意到此次并没有authorization编号.

 

生成profile的过程，就是把role实例化的过程. 一个role只能有一个实例

 

一个role未经实例化, 仍然可以赋于user, 从而可以显示出对应的菜单, 但是用户却没有任何权限.

当Role实例化生成了profile, 则在创建user时, 赋于该user相应的role, 保存后就会自动带出对应的profile. 而且该profile 不能在创建用户时单独赋于用户, 必须通过赋于用户role从而自动带出该profile. 对于一个已经生成profile的role, 即使在user 主数据中强行删除profile, 但是只要role没删除，保存后会自动又把profile填上。但是如果删除role, 则自动将对应的profile也删除.

 

从中可以看出, SAP 真的是希望用户忘记profile. 猜想现在用户还能看到profile主要是出于系统兼容的原因。

 

但是, 确实有部分profile是单独存在的, 与role无关. 比如SAP_ALL, SAP_NEW, IDES_ALL等. 这种profile的Type与 和role绑定的profile是不一样的。如下图:

独立的profile: 

绑定的profile: 

题外话, 发现IDES_ALL 这个profile很好用。除了设置用户外，其它操作权限都有，很适合在学习系统中的用户。

也许有一天，SAP会彻底隐藏profile, 而要求用户全部以role处理.

 

三、自顶向下的理解与实践

自下向上虽然容易理解权限的来历，但对实际工作帮助甚微。当需要为一个用户分配权限时，如何才能知道需要哪些authorization object?

这时Role功能的强大就体现出来了。 当讲到用户权限时，第一个必须回答的问题就是：这个人要做什么事？ 而"做什么事"，换成SAP的语言就是：这个人要用哪些T-Code?

SAP 针对每一个TCode, 定义了相关联的authorization object (存储在表TSTCA中,可以SE16查表或用SU24 查看), 当决定给这个用户某个TCode的使用权限，其对应的authorization object就可以被自动加入。（这是从理解的角度说的，实际上还要看用户的意愿）

 

3.1 创建一个新的Role (完全新建)

Role 名称最多30个字符

 

 

 

在添加Tcode之前还是看一眼Authorization选项卡吧。 不出意外， 是空的….

 

现在创建一个目录ORD，添加Tcode VA01.

 

这时再来看看Authorization. 如下图. 此时尚未生成profile. 先不急着生成. 点change authorization data. 或 expert mode for profile generation. 二者效果类似，expert mode for profile generation 有点小复杂，以后再说。

 

点击后会要求先保存profile, 保存吧（此时profile明明没生成嘛，也许后台已经给了个临时的？）。

然后会要求设置organization levels, 可以现在设， 也可以先跳过以后再设. 现在先不设，有个概念要讲解.

 

如下图, 可以看到Tcode VA01动用了11个authorization object (总共4个authorization object class).

 

点开最后一个object, 可以看到Divison / sales organization / distribution channel这3个authorization field. 这3个field是不要自行设定的。它自动从organization level的设定绑定.

 

上面这个界面只有在最"原始"的状态下才能看到。 当进入authorization时，即使你没有输入profile名称，SAP应该是已经自动生成了一个profile名称。显示object的代码(从Uitilities菜单下选择technical name on)，你就会立即看到这个profile的名称。当然在保存时是可以改的。

而且此时可以发现Divison / sales organization / distribution channel这3个authorization field的值是$开头的。 如果熟悉Windows 系统设置的可以立即联想到这就是所谓的"系统变量"了。

设好organization level后，可以看见这些field值自动变化了.

 

点开所有的分支，把每个field设好(不确定的就输*), 然后所有的object都变绿灯。绿灯说明是各个authorization field已经有值了(当然并不一定是想要的); 黄灯是普通的field缺值；红灯表明object中有organization level的field没有赋值(需要设定organization level)

保存. 会要求确认profile的名称。就按系统产生的吧。如下图，设定为这个role只能操作ZOR类型的订单(正常订单)

当选择退出时，会问是否要生成(generate) profile,

点  , 生成。或者先生成再退出。

 

回到Authorization的主界面， 可以看到profile处已经有名称了. 而且authorization变成了绿灯. User选项卡还是红灯，那是因为这个role还没有赋于任何用户。

 

在User选项卡中，将此role赋于用户ID，或者用 SU01进入用户维护界面，设定用户role. 设定好后，用测试用户ID登录, 从Menu菜单中选择"user menu", 可以看出Role中设计的菜单(话说SAP就是牛！),

 

运用Tcode VA01, 发现可以运行。 试其它Tcode, 不能运行。

 

注意, 虽然限定了此Role只能处理ZOR类型的订单， 但是在订单创建界面，仍然可以看到并选择其它类型，只是后续操作时不能继续。

 

至此，已经搞明白了SAP 权限的核心。实践操作上，Role可以通过复制(copy)、衍生(derived或曰继承)而来。同时还可以设置"复合角色"(composite role).

 

Role的命名管理又是另一个学问，想象一下，假定一个全球化的公司在世界的主要国家都有业务，（假定100个吧）, 几个主要国家可能还会有多个company code, 各个一个国家的用户是不能操作另一个国家的作业的，这时如果Role命令混乱，那简直就是灾难。

 

另一方面， Role的内容变更也是学问。假定在一个国家新开了一个company code, 总不见得要打开几十个role逐一修改吧？

 

这些再慢慢研究…