PFCG
PFCG
PFCG
Access to SAP system are assigned to users through roles maintained in their user
master. In this article, we explore how access to the SAP system is extended to users
through roles. We also talk about the related concepts of authorization objects and
authorizations.
The transaction to create/maintain roles is PFCG. Lets create a role in PFCG and try to
understand the various options available to us therein. We name the new role
ZTEST_HR_ACCESS and click the Single Role button. (Note that you can follow any
naming convention for your roles as long as they do not begin with SAP or /).
Inside, PFCG, there are again a number of tabs which need to be filled with data as part
of the role creation process. We start with maintaining role name and description. There
is also the option of specifying a parent role as shown in the diagram below. A child role
inherits all T-codes and authorizations from its parent except the organizational levels
(we will discuss org levels in a later article). The Long text field might be used as an
audit log to track the background behind creating the new role.
PFCG Role Description
In the menu tab, we maintain the T-codes that the role will have access to. In addition
to T-codes, we can also add reports, queries and URL. There are lots of options to build
the menu of a role. You can copy from an existing area menu defined in SAP, copy from
another role or import from a text file.
PFCG Menu
Once we have maintained the menu for the role, we go into the Authorization tab. We
have an option of generating a profile name or following our own naming convention. I
would suggest following a naming conventions of our own (even though I have used the
generated profile name in the example) as the profile name can help in subsequent
reporting on authorizations. We save the new profile and click either of the two
highlighted buttons, Change Authorization Data & Expert mode for profile generation to
get into authorization data maintenance.
PFCG Authorization Tab
The next screen is for maintenance of authorization data. The different color codes
define distinct security specific objects/concepts. Lets discuss these below
Blue Line Role In our case it's the new role which we have just created
ZTEST_HR_ACCESS.
Off-white Line Authorization Field These are the unique fields within each
authorization object. Different authorization objects will have different sets of
authorization fields.
To understand how security works at the application level, we take the example of
the S_TCODE object. To start a transaction, a user needs this authorization
object in his user buffer with the the transaction maintained as a field value. In
the example below, a user with the new role would be able to start transactions PA30,
PA40 and SU53. However, starting a transaction is only the first level of check, any
number of different authorization objects can be
checked at each step of the transaction. These checks are for presence of individual
authorizations in the user buffer.
During role maintenance, we maintain all the open field values (marked by yellow
triangles) so all authorizations become green. Once finished we generate the role,
by clicking the button with the a circle and red and white quadrants. This final step is
the most important step in the entire process as this creates one or
more authorization profiles for the role. It is actually the authorization profiles
present the user buffer that give access to SAP applications. The role is just
helps in easier maintenance of authorization profile. Even now, its technically
feasible to directly modify authorization profiles but is strongly discouraged from SAP.
Once generated, the role can be assigned through PFCG itself or through SU01.
PFCG Role Authorization Data
In the next article, we discuss the link between transactions and authorization objects.
This will in turn help us to understand how the authorization objects are pulled into the
role during maintenance.
Difference between Change authorization data and Expert mode for profile
generation in Change Roles.
Access.
2. Enter the name of the deliver
ed standard role in the Role field .
3. Copy the standard role by choosing Copy role and enter a name from the customer namespace.
Do not change the delivered standard roles (SAP_), but rather only the copies of these
roles (Z_). Otherwise, the standard roles that you have modified will be overwritten by newly
delivered standard roles during a later upgrade or release change.
4. Choose Change (the new name is in the Role field).
5. You can change the user menu on the Menutab page. You can reduce, extend or restructure it.
6. On the Authorizations tab choose Change authorization data.
7. Maintain the authorization field values as required. To adjust the authorizations for the menu
changes, choose the Profile generation expert mode pushbutton on the Authorizations tab and
thenRead old version and adjust to new data.
8. Generate the profile for the role.
9. Assign users on the User tab page and compare users if necessary.The users must already
exist in the system before you can assign them.;
2) Creating Roles
1. To start role maintenance, eit her choose Create Role in the SAP Easy Access transaction die
or Tools ? Administration ? User Maintenance?Role Administration? Roles (transaction PFCG).
2. Enter the name of the role. Roles delivered by SAP start with the prefix "SAP_". For your own
user roles, instead of using the SAP namespace, use the customer namespace. This means that the
prefix is "Y_" or "Z_". You cannot tell from the names of the delivered roles whether they are single
or composite roles. You should therefore create a naming convention for your roles so that you can
differentiate between single and composite roles.
3. Choose Create.
4. You can assign transactions, reports, and Web addresses to the role on the Menutab page
5. To generate the profile for the role, choose Change Authorization Data on the Authorizations tab
page.
An input window may appear, depending on which activities you selected You are prompted to enter
the organizational levels. Organizational levels are authorization fields which occur in a lot of
authorizations (an organizational level is, for example, a company code). If you enter a particular
value in the dialog box, die authorization fields of the role are maintained automatically.The
authorizations which are proposed automatically for the selected activities of the role are displayed in
the following screen. Some authorization have default values.
Wherever traffic lights appear in the tree display, you must adjust the authorization values manually.
You can maintain the authorization values by expanding the object classes and clicking on the white
fields to the right of the authorization field name.
When you have maintained the values, the authorizations count as manually modified and are not
overwritten when you copy more activities into the role and edit the authorizations again. You can
assign the complete authorization for the hierarchy level for all non-maintained fields by clicking
on the traffic lights.
Wherever there are red traffic lights, there are organizational levels with no values. You can enter
and change organizational levels with Org. levels.
If you want other functions in the tree display, such as copying or collecting authorizations, you can
show them with Utilities ? Settings.
a. Generate an authorization profile for the authorizations. To do this, Choose Generate.You are
prompted for an authorization profile name. A valid name in the customer namespace is proposed.
b. Leave the tree display after the profile generation.
If you change the menu and then call the tree display for the authorizations again, the authorizations
of the new activities are mixed with those for the existing authorizations. There may then be a few
yellow traffic lights, because there are authorizations in the tree that are incompletely defined. You
must either manually assign values to these, or if you do not want to do this, delete them. To delete
an authorization, deactivate it first and then delete it.
6. You can also assign users to the role immediately.
7. Save your entries.
The role is entered in a Customizing request. Use Transaction SE10 to display this.
The authorization profiles are transported along with the roles. Unless the profile parameter
transport/systemtype is set in this SAP system to value SAP. In this case, only the profiles
whose roles are assigned to customer-relevant delivery classes are transported.
2. The name of the delivered standard role should be entered in the Role field.
3. By choosing Copy role, the standard role should be copied and a name from the customer
namespace should be entered.
Only the copies of these roles (Z_) should be changed and not the delivered standard
roles (SAP_). Otherwise, during a later upgrade or release change the standard roles that have been
modified will be overwritten by newly delivered standard roles.
4. The Change option should be chosen (In the Role field, the new name is there)
5. On the Menu tab page, the username can be changed. It can be reduced, extended, and
restructured.
Role Maintenance - Role = ZTESTROLE - Create Role
Creating Roles
1. Create Role in the SAP Easy Access transaction die should be chosen or Tools? Administration?
User Maintenance? Role Administration? Roles (transaction PFCG) should be chosen to start role
maintenance.
2. The name of the role should be entered. SAP delivered roles that start with the prefix "SAP_".
Instead of using the SAP namespace, use the customer namespace for your own user roles. "Y_" or
"Z_" is the prefix here. From the names of the delivered roles; one cannot tell whether they are single
or composite roles. A naming convention for your roles should be created so that it can be
differentiated between single and composite roles.
3. Create option should be chosen.
4. On the Menutab page, transactions, reports, and Web addresses can be assigned to the role.
Create Roles - Role = ZTESTROLE, Description = this is just a stest role - Save (Ctrl+S)
Change Role: Assign transactions
Transaction code Text
3. Whether the user assignment and the personalization data must be transported also should be
specified in the following dialog box. Entire user assignment of roles will be replaced in the target
system if the user assignments are also transported. Using transaction SM30 enter it in the
Customizing table PRGN_CUST lock a system so that user assignments of roles cannot be
imported. The line USER_REL_IMPORT and the value NO should be added.
4. A transport request should be entered.
In a Customizing request the role should be entered. Transaction SE10 should be used to display
this.
Along with the roles, transport the authorization profiles. This should be done in this SAP system to
value SAP unless the profile parameter transport/systemtype is set. Only the profiles whose roles
are assigned to customer-relevant delivery classes are transported in this case.
5. A user master comparison should be performed in the target system.
SAP
Information
You are not authorized to change passwords in user group
SAP Easy Access -User menu for User TEst
User menu for TExt
User Maintenance
Display Authorization Data for User TESTUSER
Users = TESTUSER
Profile Parameter auth/new buffering = 4
Authorization obj. = S_USER_GRP
Description
Authorization check failed
Authorization Object S_USER_GRP User Master maintenance: User Group
Activity =05
User group in user master maintenance =
User's Authorization Data
Process Flow
With the role maintenance functions and the Profile Generator, the upper level shown in the graphic
should be processed. For the various job descriptions with the permitted activities the roles are
defined. The authorizations for users for a particular role based on this information are determined
by the Profile Generator. Listed below is the basic process:
1. The job descriptions to transactions should be assigned.
In your company job descriptions for each application area should be defined (for example, in a job
description matrix). For each description, the menu paths and transactions that the users require
with this job should be determined. The required access authorizations (display, change) and any
restrictions should be determined.
2. The activity groups or roles should be maintained with the role maintenance and the Profile
Generator (transaction PFCG).
To create the roles or activity groups that correspond to the individual job descriptions the role
maintenance functions should be used. The tasks (reports and transactions) that belong to the job
should be chosen for each role or activity group.
Its quite common in the SAP world that one transaction calls another via different menu
options. At the code level this is often implemented via the ABAP construct CALL
TRANSACTION. We know that to start a transaction from menu or typing via the
command window, a S_TCODE check is performed at the SAP kernel level. However
whether a S_TCODE check is performed for the CALL TRANSACTION statement can be
controlled by us through the SE97 tcode. Its not often that we need to mess with the
SE97 settings but its good to know about the option is available if needed.
The start screen for the transaction is shown below. We basically enter the transaction
which we would want to modify and click the execute button.
SE97 Initial Screen
In the next screen, we get a list of the different called transactions and whether the
S_TCODE check is performed during the call. The date shown on this screen is stored in
the TCDCOUPLES table.
SE97 List of Called Transactions
Some may consider SE97 to be similar to SU24 as it controls check indicators for
S_TCODE for the CALL TRANSACTION statement. Like SU24, you can not enforce a
check for S_TCODE without a corresponding statement at the code level. To over-ride a
a check for S_TCODE, the check indicator value should be set to No. To activate a
check, the value should be set to YES. The message options for a YES value control how
the system will react if a user doesnt have access to the called transaction. SAP
documentation mentions the following different options
To better understand the features of the SE97 transaction, I would suggest that you
further review the following two notes. The notes are especially important because they
mention different cases where the SE97 indicators might not work and reasons why
they dont.
358122 Function description of transaction SE97
515130 SE97 does not always work
Another case where I have had to use SE97 a lot is its use with custom transactions.
Like Su24, a custom transaction would come with zero entries in the TCDCOUPLES table
and any new entries would have to be created from scratch. To add new entries to
SE97 we simply use the Add New Transaction button and select the appropriate
options.
SE97 Add New Transaction
Like SU24 changes, the SE97 changes would also create a transport and would need to
be moved into subsequent systems in the SAP landscape.
The concept of parent and derived roles was introduced by SAP to simplify role
administration tasks. Its specially helpful while mapping security for large enterprises
spread across multiple geographies or divisions. A child role derived from a parent role
will have all attributes (transactions/ authorization object values) same as it parent
except the values of the Organizational Level fields (plant, company code, sales
organization). Thus maintenance is simplified as only the org levels need be maintained
at the derived role level. This also ensures that there is no opportunity to make
mistakes during authorization maintenance for the multitude of derived roles and also
reduces testing effort for roles.
Creating the parent role follows the same process as creating any other single role. In
the example below we create a global role Z_CREATE_SO_GLOBAL which allows the
creation of Sales Orders (transaction VA01) for all company code, sales orgs.
With the parent already defined we create a child role Z_CREATE_SO_US which allows
SO creation for the US companies. We maintain the parent role name as shown below.
PFCG - Derived Roles - Definition
The menu for a derived role can not be individually maintained as all entries are
inherited from the parent.
PFCG - Derived Roles - Menu can not be changed
Now we maintain the org levels values relevant for the child role. In the example below,
we have used a dummy value of @ but in a production system the correct value for org
levels should be used. The other need not be maintained at this stage. Now we save the
authorization entry for the derived role.
PFCG - Derived Roles - Maintain Org Levels
To populate the rest of the authorization values for the child role, we go into the
authorization maintenance screen for the parent and click the button push from gl.
This option pushes the non org level values from the parent to the child role and
generates the profiles for both.
The most critical success factor for a parent-derived role concept is how well, the
different business processes mapped by SAP roles are mirrored across the different
divisions in an enterprise. In other words, a parent-derived role concept will not be very
beneficial in case an enterprise follows different business process in its different
subsidiaries.
Composite Roles
Till now, all our discussion on role administration has been concentrated on creation
and maintenance of single roles. A single role as we have seen till now is a
collection of T-codes and/or authorization objects. However in addition to
these, SAP also allows to create composite roles which contain one or more
single roles. In this post, we will discuss the technical and business reasons for
working with composite roles.
During role creation, the PFCG initial screen allows us to choose whether we create a
single or composite roles. Once created, there is no way to changing a single role to a
composite or vice versa. In the screen below, we look at the role definition of the
SAP_AUDITOR composite role provided by SAP to allow the use Audit Information
System (AIS). You will notice that the individual tabs inside PFCG are different from
those for a single role. for ex, we do not have the common transaction or authorization
tabs. Instead we have the Roles tab and also a menu tab. The roles tab allows us to
specify any number of single roles that constitute the composite role as well as the
system for the roles. This is important in a SAP system with CUA installed as a
composite role defined in the central CUA system can point to roles defined in the child
systems.
PFCG - Composite Role Definition
Depending on role design or user assignment strategies, composite roles can be used in
a number of ways. Let's look at a few scenarios using composite roles. This is not an
exhaustive list in any way but just meant to give an idea of the common uses for
composites
Single roles are mapped to tasks performed by users . Since a typical user
performs multiple tasks, the total access for a user is represented through a
composite role which includes the individual task roles.
Access is divided into transaction role ( which contain transactions but no
authorization object access ) and value/controller roles (authorization objects but
no transactions). Complete access is represented through a composite role with
the transaction and value roles.
The entire system landscape consists of a number of separate SAP systems (like
ECC, BW, SRM, CRM etc.) and users are administered through a CUA connecting
the individual systems. A user getting role A in ECC will need the corresponding
role B in BW and role C in CRM. This can be achieved through a composite role
created in the central system which links the individual roles in the different
systems.
Organizational Levels
In the role below, we see Org Levels like Company Code, Purchasing Org, Purchasing
Group, Sales Org, Division, Plant, etc.
PFCG - Org Levels
In the expanded view of the authorization data in PFCG, the org levels defined earlier
appear side-by-side with the authorization fields. In fact, all org levels are also
authorization fields but not all auth fields are org levels. For example, the org
level Plant appears as an authorization field in two objects, M_LFPL_ORG and
M_MATE_WRK. On the other hand the field Activity is not an org level. Once we
maintain a particular value for an org level in a role, all authorization objects using the
same org level as a field will automatically take the same value. Its technically feasible
to break an org level, so that for a particular object, its value is different from its
defined org level value but this defeats a the purpose of defining something as an org
level.
Another difference between org levels and normal auth fields come to light while
deriving a role from another master role. A normal auth field will be inherited by the
child role with the same value as maintained in the parent but an org level can be
maintained in the individual child roles.
PFCG - Org Levels vs Auth Fields
It's possible to change an authorization field to an org level for the purpose of security
by executing the program PFCG_ORGFIELD_CREATE. However, since this program
impacts all roles which contain the org field it should only be run after a thorough
analysis of all impacted roles. Also certain auth fields like Activity can never be
changed to an org level.
Authority-Check
This post talks about the program level mechanism to implement a check for a
particular authorization object. SAP Business applications are coded in the SAP
proprietary language, ABAP. All transactions call ABAP programs at the back-end and it
is this code which is responsible for checking security.
The security check for an authorization object is through the standard ABAP
construct AUTHORITY-CHECK. The actual form of this statement is given below for
checking display access (ACTVT 03) to a table belonging to particular table
authorization group (DIBERCLS SC).
Copying a portion of the SAP code which is used to check for table access
Authority-Check for Tables
This statement checks the user buffer of the person executing the program/ T-code to
see if he has an authorization for S_TABU_DIS with actvt 03 and dibercls sc.
Depending on the contents of the user buffer, the statement might return different
values (the values of the system field SY-SUBRC)