SAP Access Control and Spring Security

发表于 更新于 分类于

SAP Access Control is an enterprise software application that allows organizations to manage their access governance policies and to monitor for compliance.

SAP Access Control is an add-on to SAP NetWeaver, and works with SAP applications and non-SAP applications, such as SAP Finance, SAP Sales and Distribution, Oracle, and JDE.

The application provides a framework for managing application authorization functions such as:

Access Requests (ARQ) – You can implement your company’s policies for creating and maintaining access requests in ARQ. Users can create requests to access systems and applications. Approvers can review the requests, perform analysis for user access and Segregation of Duties (SoD) risks, and then approve, reject, or modify the requests.

Access Risk Analysis (ARA) – You can implement your company’s policies for SoD and user access risk in ARA. Security analysts and business process owners run reports to determine if violations of SoD or user access policies have occurred. They can identify the root cause of the violations and remediate the risks.

Compliance persons can use this function to monitor compliance with company policies.

Business Role Management (BRM) – In an SAP landscape, users’ authorizations to applications are managed through the use of roles. Role designers, role owners, and security analysts can use BRM to maintain roles and analyze them for violations of company policies.

Emergency Access Management (EAM) – You can implement your company’s policies for managing emergency access in EAM. Users can create self-service requests for emergency access to systems and applications. Business process owners can review requests for emergency access and grant access. Compliance persons can perform periodic audits of usage and logs to monitor compliance with company policies.

Periodic Reviews of User Access and Segregation of Duties (SoD) – You can use the application to carry out your company’s policies on periodic reviews for compliance. Security and business process owners identify policies that require periodic reviews and define review processes. Reviewers perform the reviews and then security and business process owners determine if corrective actions are required.

Managing Roles

This overview process explains how to monitor and prevent risks during role creation and update.

Process
Maintain and/or refine role definition

If the applicable role does not already exist, the first step is to define and document the business requirements and major attributes for the new role.

For what business reasons is the role needed?

Which part of the organization does it belong to; for example, business process, subprocess, functional area, and so on.

Who is the person responsible for the role content? Who will approve user access to the role?

Maintain role technical details

Once the role definition is created or updated, the next step is to identify the technical details to perform the work process tasks that are defined in the role definition.

Perform risk analysis

Refine role technical details to remove conflicts when possible.

If the technical details cannot be refined, the risk should be mitigated with the appropriate controls.

Maintain authorization data

Once the technical details are defined, the next step is to identify the authorization data to restrict the work process tasks based on job responsibility and organization assignment.

Perform risk analysis

After authorization data is defined or updated, risk analysis is performed to check if the role contains access risk violations.

Refine role authorization data to remove conflict when possible.

If the authorization data cannot be refined, the risk should be mitigated with the appropriate controls.

Role Owner Approval

Role is ready to be submitted for role owner approval if it does not contain access risk violations or if they are mitigated. If the role is rejected by role owner, it could be redefined, updated, or deleted.

Create and update roles

After the role is approved by role owner, the role is created or updated in the system.

Perform testing and documenting results

Testing is performed to ensure that the role has the proper access. The test results are documented.

User provisioning

Approved and tested roles are ready to be provisioned to users to provide them with system access.

Result
Roles are introduced into environments without risks or with mitigated risks to provide compliant user access.

有赞权限系统(SAM)

原链接：https://tech.youzan.com/sam/
本文为非商业转载。
商业转载请联系有赞公司相关人员。

在介绍SAM系统之前，首先以几个案例来理解权限系统的概念和设计。

计算机世界中的许多事物是现实世界的一个阴影，现实中所见的许多模式/概念在计算机世界里都能找到，权限作为现实世界随处可见的概念，在我们谈论私有制、所有权时，时常会谈及权限，在计算机世界中，权限在许多系统中举足轻重。一切皆文件的Linux操作系统，为大多技术人员所熟悉，在这样一个多用户操作系统里，每个用户有自己的工作空间，通过把权限落在文件上实现对资源的管理。曾记否，qq里隐身对她可见，怕她看不见，下线又上线，却依旧被视而不见；曾记否，亲密无间的恋人们，分手后变成了最熟悉的陌生人，悲痛伤心之余，微信、电话、 qq拉黑。上述这些，都是计算机中利用权限系统的典型案例，在qq隐身案例中，你对女神隐身可见，实际上是赋予了她可以看到你的隐身状态（真实状态）的权限，当然你也赋予了人家伤害你的权限；恋人的案例中，恋人们把对方拉到了黑名单用户组，这样一来，他们就看不见相互动态，成为最熟悉的陌生人；从此，从你的全世界路过。

RBAC

上面例子，我们可以抽象出这样的模式：“Who对What(Which)进行How的操作” 。例如，恋人们的例子，在你拉黑对方后，在朋友圈中你(Who)将看不到(How)对方的消息(What)。这是一个经典的RBAC（基于角色的权限访问控制）权限模型。RBAC认为权限授权实际上是Who、What、How的问题。在RBAC模型中，Who、What、How构成了访问权限三元组,也就是“Who（权限的拥用者或主体）对What(Which)（权限针对的对象或资源）进行How（具体的权限）的操作”。

RBAC模型引入了“角色”的概念。所谓“角色”就是一个或一群用户在系统中可执行操作的集合，它是一个用户的集合，又是一个授权许可的集合。通过将角色指派给用户，为角色赋予权限的方式，使用户和权限通过角色间接相联系。RBAC基本模型如图所示：

051301

在RBAC中，用户与角色之间、角色与权限之间都是多对多的关系。会话是一个用户对多个角色的映射，此时的用户权限可以为激活角色权限的并集。RBAC对资源授权管理过程分为两个部分，首先实现访问权限与角色相关联，然后再实现角色与用户相关联，从而实现了用户与访问权限的逻辑分离。

权限系统SAM

SAM权限系统模型设计
RBAC模型不同于强制存取控制以及自由选定存取控制直接赋予使用者权限，是将权限赋予角色。在RBAC中，权限与角色相关联，用户通过成为适当角色成员而得到这些角色的权限，角色可依新的需求和系统的合并而赋予新的权限，而权限也可根据需要而从某角色中回收。RBAC相对于传统访问控制更为中性且更具灵活性的存取控制技术。从一家零售店铺员工角色管理角度看，设置角色是为了完成各种工作而创造，员工则根据它的责任和资格来被指派相应的角色，员工应该可以很容易地从一个角色被指派到另一个角色。因此，零售选择了基于RBAC模型来实现权限系统解决商家们管理员工角色问题。

依据RBAC模型思想，SAM权限系统业务模型设计为员工管理和权限管理两部分，员工管理主要指管理员工以及为员工指派角色，权限管理主要指管理菜单、页面、按钮、API等资源，通过定义最基本的业务功能点作为权限点，实现管理角色对资源主体的请求，构成“用户-角色-权限-资源”的授权模型。

下面是SAM权限系统模型中的一些通用语言：

员工：角色的载体，权限的实行者
角色：角色是权限集进一步映射。业务系统可动态管理角色,各业务为方便用户使用可提供给默认角色列表，满足不同的员工权限
权限点：全局唯一的用来表示某一个功能点对应的权限的状态
功能点：逻辑上定义的用来描述系统资源的最小基本单位，每一个功能点都对应唯一一个权限点
功能集(权限集)：即功能点的集合，有一组功能点按照特定格式进行组合
API：请求系统资源的通道和动作，拥有功能集属性
菜单：将系统资源组织后展示给请求者的入口，拥有功能集属性
页面：被当做一种特殊的菜单，拥有URL属性
按钮：页面中更细粒度的资源入口，被当作一种特殊的菜单

SAM权限系统模型的实现
在传统的RBAC模型中，通常通过一张关系表来保存角色与权限集的对应关系，实现权限与角色相关联。可以预见的是，随着零售业务的不断发展会积累下不计其数的功能点，导致关联表的数据极难维护和使用。SAM权限系统利用进制转换的策略解决了这个问题 ，同时提高了存储效率以及权限判定效率。一个基本类型为Long的十进制数字，它也可以看做是由64位0或1组成的二进制。在SAM系统模型设计中，每一个功能点定义为一个权限点，该权限点由idx和pos两个属性确保是全局唯一的权限点。idx表示第几个Long型空间，pos表示Long型对应的二进制数中所处的位置，64位长度即可代表64个不同能功能点。当64位满时无法再容放更多的功能点，这时idx属性会自增，重新申请一个Long型空间。如此一个64位的Long数字，通过0或1的组合，即可表示最多对64个不同的功能点所拥有权限的状态描述。

例如：权限集{1}表示拥有idx=0,pos=0对应功能点的权限，权限集{-1,1}表示拥有idx=0,pos∈[0,1,2,..,63]与idx=1,pos=0对应功能点的权限。

SAM权限系统将资源与所代表的功能点的关联关系通过进制的方式管理起来，采用计算机进制的思想，抽象出功能集换算公式来完成资源与二进制之间的映射，以及角色与二进制的映射。

权限集换算公式：
{(idx0,pos0),(idx0,pos1)…(idxN,posM)} => {Long0,Long1…LongN}

SAM权限系统同样通过进制思想实现“Who对What进行了How的操作”，角色请求某个资源（菜单/API）时，通过权限校验计算公式——进制按位“与”运算操作的思想（见下）得出该角色是否拥有访问资源的权限。采用进制来实现运算，权限判定的效率会变得更加的高效。例如，一个仓管在点击一个商品库存菜单时，背后的权限校验计算公式，其实是将角色的权限集与资源的权限集进行按位与计算，任意一对序号为idx的Long算得不为0，即两集合有公共的功能集，认为该角色拥有对资源访问的权限。

权限校验计算公式：
{Long0,Long1…LongN} & {Long0,Long1…LongM}

SAM权限系统模型的实现遵循RBAC模型中的最小权限原则，责任分离原则和数据抽象原则三大原则，通过最小权限原则可以将角色配置成其完成任务所需要的最小的功能集；有了责任分离原则可以通过调用相互独立互斥的角色来共同完成敏感的任务而体，比如要求一个仓管和商品管理员共同参与一个商品。数据抽象则可以通过权限的抽象来体现，如仓管操作商品发货，库存管理等抽象权限，而不用操作系统提供的典型的读、写、执行权限。

菜单渲染
SAM通过客户端的方式进行接入，菜单渲染在客户端一侧进行。目前SAM已经提供了php/node js两套客户端，供web层进行接入和渲染。
菜单渲染的过程可以分为三点：
一、结点定位
按照系统功能的划分，菜单通常以一棵树的形式进行展现。以零售PC后台为例，所有在页面中展示的元素，都认为是一种菜单，这样的菜单元素包括：菜单、页面、按钮。在后台访问时，用户停留的菜单通常是页面，页面有一个全局唯一的属性：URL，往上：可以通过父菜单找到根结点，往下，页面下可能包含一些子菜单——按钮。因此SAM只需要根据当前请求的URL，即可在后台菜单树中定位到唯一的页面菜单，同时获得该菜单的结点路径以及拥有的按钮。
二、权限计算
我们已经获得了用户的角色权限和完整的菜单树，根据每个菜单结点的权限集，可以计算出当前用户对结点的访问权。根据计算结果，客户端对菜单可以进行区分渲染，比如：用户通过拼URL访问一个无权限页面时会提示非法，无权限访问的菜单和按钮会自动置灰不可点击。
三、属性传递
默认菜单不具备URL属性。菜单的URL属性通过子菜单的URL传递生成，SAM会选择第一个有权限的子菜单的URL作为父结点的属性，并逐级传递到一级菜单。

SAM权限系统抽象模型

SAP Security - System Authorization Concept

PFCG Role Maintenance

PFCG Role Maintenance can be used to manage roles and authorization in a SAP system. In PFCG, the role represents a work that a person performs related to real-life scenarios. PFCG allows you to define set of transactions that can be assigned to a person to perform their daily work.

When the roles are created in a PFCG Transaction, you can use Transaction SU01 to assign these roles to individual users. A user in a SAP system can be assigned multiple number of roles and that are related to his/her daily task in real-life.

These roles are in connection between user and authorizations in a SAP system. The actual authorizations and profiles are stored in the form of objects in a SAP system.

Using PFCG Role Maintenance, you can perform the following functions −

Changing and Assigning Roles
Creating Roles
Creating Composite Roles
Transporting and Distributing Roles
Let us now discuss these functions in detail.

Role Administration

Purpose
You can use the role administration functions to manage roles and authorization data. The role management tool creates authorization data automatically based on selected menu functions, and presents it for postprocessing. It is also integrated with organizational management.

We recommend you use the role maintenance functions (transaction PFCG) to maintain your roles, authorizations and profiles. Although you can continue to create profiles manually, you need detailed knowledge of all SAP authorization components.

The role administration functions support you in performing your task by automating various processes and allowing you more flexibility in your authorization plan. You can also use the Central User Administration functions to centrally edit the roles delivered by SAP or your own, new roles, and to assign the roles to any number of users.

The roles (previously: activity groups), which are based on the organizational plan of your company, form the basic framework of the tool. These roles form the link between the user and the corresponding authorizations. The actual authorizations and profiles are stored in the SAP system as objects.

With the roles, you assign to your users the user menu that is displayed after they log on to the SAP system. Roles also contain the authorizations that users can use to access the transactions, reports, Web-based applications, and so on that are contained in the menu.

When you work with the role administration tool, you work with a level of information that is a step away from the actual objects in the SAP system. The graphic below shows how these two levels are separated, yet linked together with the role administration functions.

Implementation Notes
Since the standard SAP system contains a large number of roles already, you should check whether you can use these before defining your own roles.

To get an overview of the roles delivered with the system, do one of the following:

● In the SAP Easy Access menu, choose Tools → Administration → User Maintenance → Information System → Roles → Roles By Complex Selection Criteria and then Execute.

● In role administration (Tools → Administration → User Maintenance → Roles), choose the input help for the Role field.

If you want to make modifications to an existing role, make a copy of it and modify this.

If you do not find suitable roles, write job descriptions before beginning your work in role administration (see also Initial Installation Procedure).

Either have all tasks performed centrally by a single superuser, or divide the tasks among several users in order to increase system security. For more information, see Organization of the Authorization Administration.

SAP－客户主数据维护

客户主数据是销售与分销模块中最重要的主数据，是指将各种商业伙伴的相关信息以主数据的形式在系统中建立，并以唯一的代码进行标识。维护客户主数据的主要作用是在进行销售与分销业务的各个阶段明确业务对象，并按照业务对象的客户主数据中维护的控制信息指导系统完成相应的业务处理。
客户主数据中的一般数据是对整个集团有效的数据，对任何公司代码和销售区域都有效，是客户的基本信息。
客户主数据中的公司代码数据是基于公司代码有效的数据，是客户的财务信息。
客户主数据中的销售区域数据是基于销售区域有效的数据，是客户的销售、发运和销售开票信息。

1：创建客户主数据一般数据视图
主数据维护人员按照创建客户主数据请求，在系统中确认是新客户之后，创建客户的一般数据视图，为客户选择帐户组和建立唯一的代码标识。
步骤：（事务代码：VD01/XD01）

  1. 输入客户帐户组，它有以下作用：
    1）确定客户主数据的编码范围，确定使用内部编码还是外部编码（若使用外部编码，还需要手动输入客户编码）
    2）确定客户主数据中各个字段的维护状态（显示、可选输入或强制输入）
    3）是否是一次性客户
    4）影响销售视图中的合作伙伴功能确定
    5）影响输出确定
    选定客户帐户组（如果是外部编码需输入客户编码）之后，维护一般视图。
  2. 可以在一般数据视图中维护下列信息：
    1）地址信息（如名称、地址、国家、城市、邮编、联系电话、传真号码等）
    2）控制数据（如税务信息、权限组、对应供应商编码等）
    3）付款业务（如银行信息等）
    4）市场信息（如行业、客户分类等）
    5）卸货点信息（如收货时间等）
    6）出口数据（如出口控制数据等）
    7）联系人（如商业伙伴地址等）
  3. 保存客户主数据。

2：创建客户主数据公司代码数据
创建客户的财务相关信息。
步骤：（事务代码：VD01/XD01）

  1. 可以在公司代码数据视图中维护下列信息：
    1）帐户管理（如统驭科目等）
    2）付款业务（如付款方式、付款冻结等）
    3）联系（如职员等）
    4）保险（如投保金额等）
  2. 保存客户主数据。

3：创建客户主数据销售区域数据
创建客户销售、发运及销售开票的相关数据。
步骤：（事务代码：VD01/XD01）

  1. 可以在销售区域数据视图中维护下列信息：
    1）订单数据（如销售办公室、货币、销售组、销售区域、价格组等）
    2）发运数据（如发运条件、交货工厂、运输区域等）
    3）发票数据（如销项税分类、付款条件等）
    4）合作伙伴功能（如售达方、送达方、付款方、开票方等）
  2. 保存客户主数据。

4：更改客户主数据
步骤：（事务代码：VD02/XD02）

  1. 输入组织结构：
    1）客户编码
    2）如更改公司代码数据，需输入公司代码
    3）如更改销售区域数据，需输入销售区域
  2. 更改相应信息并保存。

5：显示客户主数据
步骤：（事务代码：VD03/XD03）

  1. 输入组织结构并显示：
    1）客户编码
    2）如显示公司代码数据，需输入公司代码
    3）如显示销售区域数据，需输入销售区域

收到客户创建申请
系统中没有创建过相同客户的主数据
对要创建的客户各种信息都已收集审核完毕
明确创建客户主数据的组织结构数据（公司代码和销售区域）

维护客户帐户组及其编码范围

维护各个控制字段的选择值配置
维护其合作伙伴功能的后台配置及前台主数据

一次性客户：
可以在客户帐户组中控制是否为一次性客户，如果是一次性客户，那么在每次使用这个客户创建销售凭证时都要重新维护其地址等基本信息。

通用分销渠道和通用产品组：
可以为几个分销渠道或产品组设置通用分销渠道和通用产品组。那么在创建客户主数据的销售区域数据视图时，如果采用通用渠道或产品组，则维护的数据对其它分销渠道或产品组同样适用。
————————————————
版权声明：本文为CSDN博主「wtxhai」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/wtxhai/java/article/details/72356426