Explaining Structural and Context-based Structural Authorizations

The existing configuration and artefacts, such as the structural profiles, transactions, such as OOSP/OOSB and other current report programs, such as RHAUTH01 are completely reused and integrated with the CDS views and DCLs to achieve the structural authorization. The steps below are performed to achieve structural authorization and distribute them on user level:

1. Step: Creation of Profiles for Structural Authorization (TCode OOSP)

   Specify details of planning version, object ID, object type, evaluation path, status vector and processing type.

   • Planning Version: Specify the planning version that corresponds to your authorization setup.
   • Object ID: Input the unique identifier for the object you are authorizing.
   • Object Type: Define the type of object you are working with.
   • Evaluation Path: Indicate the path used for evaluation purposes.
   • Status Vector: Set the status vector as required by your authorization structure.

   These details will ensure that the profile you create is tailored to the specific structural needs of your system.

   
2. Step 2: Assign Created Profiles to Users (TCode OOSB)

   Specify validity start/end date and set exclusion flag if needed.

   • Validity Start/End Date: Specify the dates during which the authorization is valid. This helps in managing temporary authorizations effectively.
   • Exclusion Flag: If needed, set the exclusion flag to exclude specific users from the authorization setup.
   

   This step ensures that the structural authorizations you created are correctly assigned to the relevant users.

3. Step 3: Execute the Program "DFS_FE_STRUC_AUTHZN" (TCode SE38)

   It is important to execute this program whenever any changes are made in the OOSB or OOSP transactions. This step ensures that all changes are properly integrated and that the structural authorizations are up to date.

Structural authorizations are a crucial aspect of managing access and permissions in various systems, particularly within the context of HR functionality. Here are the key components you need to understand:

• Authorization profile (OOSP)

  Force elements can be assigned to a profile

• Authorization user (OOSB)

  Users can be assigned to a profile

• HR authorization object used for Force Element
• Personnel Planning (PLOG)

  In HR functionalities, authorization objects are used to control access to specific HR operations. The PLOG object, for instance, relates to personnel planning activities, ensuring that only authorized users can perform tasks within this sphere.

In the context of defense and security, the handling of structural authorizations is based on the HR object. This means that the same principles and components described above are applied, but with a focus on the unique requirements and sensitivities of defense and security operations.

• User1 is binded to Profile1 and with PLOG we can control the access rights
• User2 is binded to Profile2 and with PLOG we can control the access rights
• BUT we cannot control in detail which access rights should be given to which profile, because Authorization Object (PLOG) has no connection to the profile.
• This means if you give away e.g. Create Rights via PLOG to a user, the user have create rights for all of his assigned Force Elements (by structural authorizations)

Structural authorizations are not only enabled for selected Force Elements (with lower-level structure) using profiles and usage type "Organizational Structure", they are also empowered for all assignment types between Force Elements.

• In the case of force element to force element assignments (such as sup, sup by, maint, maint by), the user requires the authority for both the source and the target force elements to be able to see/edit these assignments.
• This means that if the user does not have authority for a force element, the assignments are also not visible.
• No Customizing necessary
• New D&S assignment object
  • DFS_ASSGM1 with profile handling

New D&S Assignment Object:

SAP introduced a new D&S assignment object, DFS_ASSGM1, which handles profile management seamlessly. This ensures that the authorization process is streamlined and efficient.

With DFS_ASSGM1, profile handling is integrated, making the management of structural authorizations and Force Element assignments more straightforward and user-friendly.

Structural authorizations are a set of permissions that define what actions users can perform within a system or application. Customizing these authorizations allows you to tailor access levels to fit the specific needs of your organization or project. This process ensures enhanced security, streamlined workflows, and efficient user management.

In a system where user access is managed by roles and authorizations, context-based structural authorization is a critical aspect that ensures the right levels of access are granted to users based on the context of their interactions. This is particularly relevant when dealing with complex structures such as Force Elements, Flexible Material Planning Objects (FMPOs) and products.

Restricted Access to FMPOs and Products: When a user is not authorized to a Force Element, the restricted access extends to the FMPOs and Products that are assigned to that Force Element.

Based on structural authorization concept

• Authorization profile (OOSP)

  Force elements can be assigned to a profile

• Authorization user (OOSB)

  Users can be assigned to a profile

HR authorization object used for force element

• Personnel Planning with Context (PLOG_CON)
• Profile is included in authorization object

  Activity (display, edit, delete, etc.) clustered on profiles

The HR authorization object is used to manage Force Elements within the system. A key component of this is the authorization object 'Personnel Planning with Context' (PLOG_CON).

This authorization object is instrumental in:

• Profile Inclusion: The structural profile is included within the authorization object, ensuring that the permissions defined in the profile are effectively taken into account
• Activity Clustering: Different activities (display, edit, delete, etc.) are clustered within the profiles, allowing for a clear and organized structure of permissions.

• The main difference is that you can control the access rights on profiles level. This means you can assign profiles to authorization object PLOG_CON. 
• Before that you could only assign access rights on user level. This means if a user had "Display" and "Create" assigned with PLOG, the user had this rights for all Force Elements in the tree
• Now you can define access rights on profile level which gives you the possibility to assign different access rights to Force Element branches of your Force Element structure.

An FMPO is also enabled for the structural authorization if an assignment from the FMPO to the Force Element exists.

• If the user does not have authority for the Force Element, the Manage Flexible Material Planning Objects App does not display this FMPO.
• The user requires display authority for the assigned force element to be able to display the FMPO.

The same applies to the assigned products.

• If the user does not have authority for the Force Element, the Manage Product Master Data App does not display the assigned product.
• Prerequisite for the enablement of context-based structural authorization for Product Master is implementation of SNOTE "3081577 Manage Product App: Enablement of context based authorization".

To effectively manage and utilize the Flexible Material Planning Objects (FMPOs) and Product Master Data applications, it's crucial to understand the context-based structural authorization process.

• To activate `PLOG_CON`, you need to enable the corresponding HR parameter.
• Use the view `V_DFS_FE_PDCON` for this activation. You can access and modify this view through transaction code SM30.
• Alternatively, you can also find this parameter as part of the SPRO (Implementation Guide) under the appropriate customizing path.
• 

1. Introduction to New Authorization Object:
   • With the activation of context-based structural authorizations, a new DFS authorization object is introduced.
   • This authorization object is essential for enabling context-based handling in Core Data Services (CDS) views.
2. Dummy Authorization Object:
   • The dummy authorization object "DFS_FE_CON" is used for this purpose.
   • The activity (ACTVT) for this authorization object is set to 16 (Execute).