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功能完全一样 (已经建议用PFCG)
• SU01        维护用户
• SUIM        权限检查
  

二、自下向上理解权限体系
2.1、Authorization field(权限字段)：权限检查的最小单元 （比如TCD/ACTVT / BUKRS / WERKS / BEGRU等等）
怎么理解" 权限检查的最小单元" 呢? 所谓的"权限"，就是对某人做某事的限制，不做事当然就不存在权限；没限制随便做当然也不存在权限。设想如下这个场景：有一个CSR (客服) 要负责输客户订单，那就产生了很多疑问：

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

        以上每一个疑问，推演到最终的需要并且可以做最终决断的对象，就是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值。


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可能的取值等于2n -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处理。