http://sap.dangjiu.com/adm/1000010385.htm
SAP用户权限管理配置及操作手册
SAP用户权限管理配置及操作手册
Overview
业务说明
Overview
SAP的每个用户能够拥有的角色是有数量限制的，大概是300多点，具体不记得了。
如果只在S_TCODE和菜单中设置了某个事务代码，而没有设置权限对象，此时将不能真正拥有执行该事务代码的权限。
SAP的权限检查机制：
SAP进入一个t-code，要检查两个东西
1） S_TCODE
2) 表TSTCA 里面和这个T-cdoe相对应的object。 有些tcode在tstca里面没有对应的object，就会导致直接往S_TCODE中加事务代码不能使用的情况。
SAP权限架构
概念
权限对象Authorization object
SAP在事务码（T-code）的基础上通过权限对象对权限进行进一步的细分，例如用户有创建供应商的权限，但是创建供应商的事务码中有单独的权限对象，那么就可以通过权限对象设置不同的用户可以操作不同的供应商数据。
角色-Role
同类的USER使用SAP的目的和常用的功能都是类似的﹐例如业务一定需要用到开S/O的权限。当我们把某类USER需要的权限都归到一个集合中﹐这个集合就是“职能”(Role)。
所谓的“角色”或者“职能”﹐是sap4.0才开始有的概念﹐其实就是对user的需求进行归类﹐使权限的设定更方便。(面向对象的权限!!)
分为single role 和 composite role两种﹐后者其实是前者的集合。
角色模板-Template Role
Role的模板﹐一般是single role.但这个模板具有一个 强大的功能﹐能通过更改模板而更改所有应用(sap称为Derive“继承”）此模板的Role(sap称之为adjust)
参数文件-Profile
参数文件相当于指定对应的权限数据及权限组的定义。
每个角色下会产生一个附属的参数文件。
真正记录权限的设定的文件﹐从sap4.0开始是与Role绑定在一起的。虽然在sap4.6c还可以单独存在﹐但按sap的行为推测﹐以后将不能“一个人活着”
用户-User
就是通常说的账号（User ID）。
通常的用户类型有
a.dialog (就是正常的用户)
b.communication
c.system
d.service
e.reference.
Table
No. Table name Short Description Memo
USR01 User master record (runtime data)
USR02 Logon Data (Kernel-Side Use) 用户的登录信息
USR03 User address data
USR05 User Master Parameter ID
USR06 Additional Data per User
USR07 Object/values of last authorization check that failed
USR08 Table for user menu entries
USR09 Entries for user menus (work areas)
USR10 User master authorization profiles
USR11 User Master Texts for Profiles (USR10)
USR12 User master authorization values
USR13 Short Texts for Authorizations
USR14 Surchargeable Language Versions per User
USR15 External User Name
USR16 Values for Variables for User Authorizations
USR20 rate of last user master reorganization
USR21 Assign user name address key
USR22 Logon data without kernel access
USR30 Additional Information for User Menu
USR40 Table for illegal passwords
USR41 User master: Additional data 每个用户当前的登录信息
USREFUS
USRBF2
USRBF3
UST04 User masters 定义每个用户对应的Profile
UST10C Composite profiles
UST10S Single profiles (角色对应的
UST12 Authorizations
SUKRI Transaction Combinations Critical for Security
TOBJ Authorization Objects 所有的权限对象
Configure
Operation
角色配置相关事务码
PFAC 维护规则
PFAC_CHG 改变
PFAC_DEL 删除
PFAC_DIS 显示
PFAC_INS 新建
PFAC_STR
PFCG 创建
ROLE_CMP 比较和调整角色
SUPC 批量建立角色profile
SWUJ 测试
SU03 检测authorzation data
SU25, SU26 检查updated profile
SU24 查看事务代码的权限对象。
用户维护相关事务码
SU0 维护用户参数
SU01维护用户
SU01D显示用户
SU01_NAV
SU05
SU50, Su51, SU52
SU1
SU10 批量
SU12 批量
SUCOMP:维护用户公司地址
SU2 change用户参数
SUIM 用户信息系统。是一组菜单，可以进行常用的用户及权限管理。
SUGR:维护用户组
SUGRD:显示用户组
SUGRD_NAV:显示用户组
SUGR_NAV:维护用户组
Profile&Authoraztion Data
SU02:直接创建profile不用role
SU20:细分Authorization Fields
SU21(SU03):维护Authorization Objects(表TOBJ,USR12).
对具体transaction code细分:
SU22 维护权限对象的分配关系
SU24 维护权限对象的分配关系
SU53:检查用户当前的权限，例如可以检查没有哪些权限对象。
SU56:分析authoraztion data buffers.
SU87:用来检查用户改变产生的history
SU96,SU97,SU98,SU99:干啥的?
SUPC:批量产生role
会计凭证的权限对象
会计凭证包含以下权限对象：
F_BKPF_BED: Accounting Document: Account Authorization for Customers
F_BKPF_BEK: Accounting Document: Account Authorization for Vendors
F_BKPF_BES: Accounting Document: Account Authorization for G/L Accounts
F_BKPF_BLA: Accounting Document: Authorization for Document Types
F_BKPF_BUK: Accounting Document: Authorization for Company Codes
F_BKPF_BUP: Accounting Document: Authorization for Posting Periods
F_BKPF_GSB: Accounting Document: Authorization for Business Areas
F_BKPF_KOA: Accounting Document: Authorization for Account Types
F_BKPF_VW : Accounting Document: Change Default Values for Doc.Type/PsKy
可以通过USR12表查询. 在DB层是UTAB.
创建角色
PFCG
需要先确定是创建普通角色还是组件角色。
对于组件角色是指可以包含其他的角色，相当于一个角色组，可以实际对应一些岗位，而将角色进行原子化。
执行“创建角色”。
如果希望继承其他的折旧，可以将父角色的编码填入“Derive from Role”字段中，在父角色改变后，需要在角色修改时，在权限的授权数据中，执行权限菜单中的“调整派生”功能。
在做下一步之前，需要先保存。
增加文件夹，同时在文件夹下插入事务码。
切换到权限页标签。
执行参数文件旁的按钮“Propose Profile Names”，生成参数文件的名称。
保存后，执行“Change Authorization Data”。
设置“Authorization Group”为genl。
其他相关的权限全部设置为“*-所有”
最后生成一次，执行“Generate“。
角色的请求传输
角色不会自动记录到请求，必须手工执行一个传输的动作。
产生的是一个Customizing request。
创建用户
SU01
设置用户的类型。对于一般用户都设置为”A Dialog”。
切换到角色页标签。
可以设置刚才创建的角色，同时可以指定有效日期。
最后保存即可。
受限用户的登录
使用创建的受限用户登录后，将受限显示用户菜单，也就是在角色中创建的用户菜单。
每个角色的菜单将会并排显示，所以如果希望显示成一个文件夹，就需要使用一个角色，或者通过修改标准的菜单结构来实现。
创建供应商-GENL权限组
FK01
创建供应商-非GENL权限组
FK01
公司代码层的权限组暂时不设置，这样所有用户都可以进行操作。
受限用户修改供应商测试-genl权限组
FK02
受限用户修改供应商测试-非GENL权限组
如果受限用户希望显示未授权的供应商也是同样的结果。
FK02
系统会提示一般没有对一般数据层的修改权限。
受限用户创建供应商测试-非GENL权限组
FK01
保存时，系统会给出错误提示信息。
为角色增加用户
我们新建一个角色。
直接指定用户后，系统显示还是红灯。需要执行“User Comparison“。
执行完成后，角色的状态才会变绿。
重新使用受限用户登录
可以发现两个角色的菜单直接叠加了。
如果在每个角色的首层都定义一个事务码，系统一样会重复显示。
当前用户权限检查
可以使用SU53检查当前用户的权限。
程序中权限的检查
通常使用任何T-code前一定会有权限检测的.
AUTHORITY_CHECK:这个函数只是小检查一下你的user有没有,什么时候过期.
如果是代码只要使用此函数就够了.
AUTHORITY_CHECK_TCODE:检查T-code
下面的函数是真正检查autorization objects的.
SUSR_USER_AUTH_FOR_OBJ_GET:
AUTHORIZATION_DATA_READ_SELOBJ:
End