ADM940 Course 1
ADM940 Course 1
1.1 Overview
Security Overview
SAP Security layers:
To avoid unauthorized system access, for example, system and data access control
mechanisms are provided at the application level.
When protecting an SAP system, you must consider the following:
1
Security must be implemented at all levels, since the overall security depends
on the weakest part.
A complex authorization concept is therefore only one aspect of an overall
security concept.
To implement roles technically, you must create roles (or composite roles) using the
Profile Generator.
A role consists of the following components:
Role Menu
The transactions, reports, Web links, and so on in a role are combined into a
menu, to which the users of the role are to have access.
Authorizations
2
The authorizations define the access rights for business functions and data.
User
To grant the access rights of a role to a user, you must assign the user to the
role. You can assign users using either the Profile Generator or user administration.
Project Preparation
Business Blueprint
Implementation
Configuration and fine tuning of the SAP system. The business processes
created and described in the previous phase are the starting point for the
implementation of the roles.
Final Preparation
Testing of all interfaces, training of users, migration of business data into the
SAP system.
Setup team with responsible for the specification and implementation of user
roles and authorization concept. Train them for roles and authorizations with
regard to specification and implementation topics. They must be able to use
Profile Generator.
SAP recommends that you inform the responsible employees of the project
targets set and establish communication channels at an early stage to ensure
efficient handling.
Identify required roles. Determine task profiles based on the organization chart
and a business process analysis. Check if SAP role templates can be used.
Specify relevant applications functions (transactions, reports, Web links) to the
roles. Make any required adjustments if role templates are used.
Specify if the roles are higher-level roles or specific roles; that is, if they are
subject to any restrictions resulting from organizational or application-specific
control mechanisms.
Identify required composite and individual roles for implementing the roles and
the authorization concept.
Using individual, composite, and derived roles, you can model the role structure in two
ways:
You can model each role as an individual role that contains all required
functions. If some functions are used unchanged in multiple roles, the
associated transactions and reports are contained in several individual roles. If
general function modifications are required, this consequently affects several
individual roles.
Alternatively, you can model each role as a composite role consisting of
individual and derived roles. In this case, the individual and derived roles
represent activity blocks, that is, groups of interrelated functions (for example:
all functions needed for a specific business scenario). Since individual and
derived roles contain encapsulated functions, they can be used in multiple or
composite roles. The advantage of this approach is that multiple access to
5
1.3.3 Implementation
From a technical point of view, user roles (job roles) can be implemented as composite
roles using the Profile Generator. Composite roles consist of individual and composite
roles that each contain the relevant authorizations and menu data. Authorizations
specify the scope of access to data and functions. User menus use hierarchical
structures to specify the access path to the transactions, reports and Internet pages
released for a specific user.
An example of how you create user roles:
are executed as desired, while the negative test must confirm that all restrictions
defined are observed. For example, a human resources administrator can display the
users for a specific work center, but not the records for other work centers. The test
scenarios must cover all functions that are to be performed by a user role.
1.3.5 Cutover
To simplify the creation of the individual user master records, you first create model
records. These model records are used as copy templates for the records of the
productive users. In the central system, create a user master record for each role
specified in the company-wide role matrix (authorization list).
The user and authorization management tasks should be distributed among several
administrators (for example, separate user, authorization data, and profile
administrators). By dividing the tasks, you ensure that no single administrator gets full
control of user authorizations (dual control principle).
By assigning the user maintenance tasks to local administrators that represent
individual departments or locations, you can even further decentralize user and
authorization management. Having an administrator on site can also be desirable
since first-time users accessing the system often need to be introduced to their taskspecific user role. In addition, decentralized administrators are useful for reporting
since they know to whom the user IDs refer.
From a technical point of view, decentralization is achieved by subdividing the users
into user groups and limiting the rights of the local administrators with regard to the
assignment of authorizations. Decentralized administrators may only maintain the
users of the group that has been assigned to them. In addition, decentralized
administrators should only be allowed to assign authorizations that are required in
their department or at their site in accordance with the naming conventions of user
roles.
The Profile Generator automatically provides the corresponding authorizations for the
functions chosen. Some of these authorizations have default values. Traffic light
symbols tell you which values you need to maintain.
The first step is defining the role and entering a short description of its
contents.
In the second step, you define the activities for the user role. The result of
this definition process is a role (or several roles) that collects all activities
of the role - represented by means of transactions, reports, and Web
addresses.
Simultaneously you define what the menu tree for the new user role
should look like.
8
Afterwards, the authorizations for the activities selected are created and
profiles generated. This step normally involves the greatest
administrative maintenance effort.
Subsequently, the users are assigned to the roles.
Finally (depending on the settings in PFCG), the comparison with the user
master records of the users which have just been assigned to the roles is
performed.
The Complete View (Organizational Management) displays all assignments and data
for a role.
This view is useful for users in Personnel Planning and Development, particularly for
organizational management and workflow. The Complete View allows you to:
10
2.3
good example to show why manual postprocessing is necessary: The Profile Generator
cannot know if the users should have only read access or also write access to the files.
12
Assigning users:
So that users are provided with the menu tree for their role when they log on to the
system, you must assign roles to them.
You assign roles to users by adding the corresponding names to the list on the User
tab page of the Profile Generator. Users can be assigned to more than one role. It
makes sense to define roles for specific cross-role activities. An example is the activity
Print. Regardless of their function, all users (who are authorized to print) can be
assigned to an role with the activity Print. This eliminates the need to add the Print
transaction to a large number of roles, which is a cumbersome task. It is also possible
to assign roles to users for a limited period of time only. This makes sense, for
example, for the year-end closing. Physical inventory activities should only be allowed
for a limited time. So that a time-dependent assignment of an activity profile to a user
master record becomes effective, you must perform a comparison (see the figure
Compare User Master Record).
There are two ways to do this:
1. As a background job: Report pfcg_time_dependency is run before the start of the
business day, but after midnight, meaning that the authorization profiles in the user
master record always have the most up-to-date status in the morning.
2. Alternatively, using transaction PFUD, (User Master Data Reconciliation). As an
administrator, you should regularly execute this transaction as a check. In this way,
you can manually process errors that may have occurred and been reported during the
background job. Choose the Complete Reconciliation radio button to compare all roles.
13
If roles were assigned directly to specific employees, then each time the user's
responsibilities change, the corresponding assignment of roles would have to be
changed
If, however, the assignments are based on the notion of positions, then no
adjustments will have to be made within the agent assignments of roles.
14
Normally, organizational plans are built by linkingobjectsof the following types with
each other:
Organizational Unit:Can be, for example, a functional unit in the company (such
as Sales and Distribution).
Position:Represents a position in the staff assignments of an organizational unit
that is to be occupied by a person (employee), such as Sales Manager Europe.
Job: While positions represent the concrete posts in a company that are to be
occupied by holders (such as Sales Manager Europe), jobs are general
classifications of functions in a company (such as sales manager) that are to be
further specified by assigning properties. Jobs provide job descriptions that are
applicable to multiple positions with similar tasks and properties.
Task: Description of an activity that is tobe performed within organizational
units.
15
16
The above figure illustrates that the first step in Simple Maintenance is to create a root
organizational unit. All other organizational units are then defined in the organizational
structure.
You can define organizational units and jobs in any order you like. However, they
should be defined before you define the relevant positions.
Positions are created after the appropriate job(s) are created in the job index.
Holders are assigned to positions, not to jobs.
Having set up the organizational plan, you can assignrolesto organizational units, jobs,
positions, and holders of positions (users).
17
18
4 Enterprise portal
In the age of e-business, many companies have very complex IT landscapes. This
includes information, applications, and services:
19
20
For example, the J2EE Engine is responsible for storing master data for portal users.
With the J2EE Engine, SAP ships interfaces for the following physical storage locations:
21
The preferred setting isUME, which is selected in the standard system during
installation. In turn, the UME provides aconnection (persistence manager) to the
following storage locations (persistence stores):
The portal users user master recordsare stored in one of these storage locations. You
can configure the UME so that several storage locations are addressed in parallel by
one portal (partitioning). For example, regular employees could be stored in the
directory service and external partners in the portal database (user partitioning).
Alternatively, some of a users data could be stored in the directory service (ID,
address, e-mail address, and so on) and some in the database (role assignments, for
example) (attribute partitioning).
Any changes made to a user master record (create, change, delete) can be sent as an
XML document to external systems using the replication manager. An external system
could also be an ABAP-based SAP system as of SAP Basis 4.6D (contains Business AddIn (BAdI) for processing these XML documents).
The UME provides extensive, open application programming interfaces (APIs) that
developers can use to access the core functions of the UME.
4.2 Logon
The authentication (user logon to SAP Enterprise Portal) checks the identity of users
before they are granted access to portal contents. Regardless of where user master
records are stored, variouslogon mechanismsare available for selection after
installation:
UserID
Logon procedure
Validity period
Issuing portal system
Signature of the portal system
If necessary, the name of the SAP reference system
4.4 Authorization
The portal objects themselves (such as iViews or roles) can be protected using an
authorization concept calleddelegated content administration.In larger companies, you
can specify multiple content administrators, each of whom is responsible only for their
own area. All portal objects are stored in a structured way in the portal catalog, and
can be processed with a central tool, the Portal Content Studio. Delegated
administration creates the possibility of allowing individual content administrators
restricted views of the portal catalog. This is controlled usingACLs, which may allow
only read access to certain objects.
23
If the user IDs in the SAP system and portal are identical, user mapping is transferred
automatically. Users that are assigned to an SAP role in the SAP system are
automatically assigned to the associated portal role.
Hint: The procedure described can also be used by customers who are migrating from
SAP Workplace to SAP Enterprise Portal (for this reason, MiniApps are also supported).
24
In this case, portal roles (or the underlying worksets) are the starting point. A portal
role of this type is created by a content administrator and can contain services (such
as transactions, reports, or BSP applications) from differentSAP systems.
The transfer requires some basic settings(which SAP system is responsible for which
roles and where is user mapping maintained) and is performed in two steps. In the first
step, which is initiated from the portal, thematchingmenu elements of the portal role
are transferred to the SAP system. In the second step, you define the associated
authorizations in the SAP system using transaction WP3R (provided by the SAP
Enterprise Portal plug-in WP-PI, which is contained in the Basis plug-in PI_BASIS as of
SAP Web AS 6.40). Depending on the configuration of the system responsibility, there
may be anumber of authorization roles in the SAP system for which authorizations are
to be maintained for one portal role.
25