ADM940 course 1.docx

26
1 Needs of Authorizations 1.1 Overview Protection of sensitiev business data Advantageous cost-benefit relation No obstruction of business process Security – Overview SAP Security layers: To avoid unauthorized system access, for example, system and data access control mechanisms are provided at the application level. 1

description

ADM940 course 1.docx

Transcript of ADM940 course 1.docx

Needs of AuthorizationsOverview

Protection of sensitiev business data

Advantageous cost-benefit relation

No obstruction of business process

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:

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.

System Access Control and Role-Based Access Control

In order to work with an SAP system, users require unique user IDs. A user master record must be created in the system for each user. This user master record also contains the password that the system prompts the user to enter when logging on.

Users, roles, authorizations

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

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.

Development of an Authorization Concept

Project Preparation

Inclusion of all relevant decision-makers for the SAP implementation and selection of the internal and external members of the project team.

Business Blueprint

The business requirements of the implementing company are determined. The Business Blueprint is a visual representation of the status of the company which is to be realized in the SAP implementation. All business processes are analyzed and described here. This is the basis for the later authorization concept.

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.

Go Live & Support

Start of SAP production operation, specification of procedures and measurement items for ongoing checking of the benefits of the investment in the SAP system.

Project preparation

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.

The team members have the following tasks:

Create SAP-dependent role descriptions in the Analysis & Conception step.

Cooperate with the IT department during implementation.

Set up and run through test scenarios.

Analysis and Conception

Specification of the role and authorization concept:

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 transactions used in several individual roles is avoided. Therefore, organizational or process-related modifications that affect several user roles can be applied by adjusting a single role.

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:

Create individual roles: Individual roles either describe higher-level functions that are independent of organizational or application-specific restrictions or are used as templates for creating derived roles that are not subject to any restrictions.

Having checked the individual roles used as the derivation basis, you create the derived roles. These contain the desired organizational or application-specific restrictions. For each responsibility area, you create a derived role from an existing individual role.

Finally, the composite roles are created from the implemented individual and derived roles as the technical counterparts of the user roles.

Quality Assurance and Test

To ensure that productive operation is not affected, it is important to thoroughly test the user roles in connection with the authorizations before you switch over to production. In addition, the responsible area manager must approve of the role and authorization concept implemented.

The test scenarios should include both positive and negative checks of the authorizations of the individual roles. The positive test checks whether the functions 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.

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).

Implementing User and Authorization Administration

The tasks of the authorization administrators include creating, activating, changing, deleting, and transporting roles.

User administrators deal with setting up, changing, deleting, locking, and monitoring users and assigning passwords and authorizations.

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 task-specific 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.

Working with the Profile Generator (PFCG)

The Profile Generator offers two different maintenance views:

Basic maintenance (menus, profiles, and other objects)

Complete view (Organizational Management and workflow)

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.

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.

Define Role Name

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:

Access all of the functions for role maintenance

Change the validity time period of the role

Link tasks with a role

Assign the role to objects in organizational plan and restrict the validity dates for each assignment

Determine Activities

Design user menus

Maintain authorization data

Creating the authorizations and authorization profiles:

The Profile Generator automatically generates authorizations based on the menu functions that you have chosen before. The Profile Generator cannot, however, propose default value authorizations that are suitable for everyone in the company. Therefore, the authorization administrator must normally postprocess the authorizations manually in cooperation with the user departments and the audit division. By choosing Organizational Levels, you can simultaneously maintain a large number of authorization fields. This greatly simplifies the manual postprocessing work.

In the example, the transaction SO01 (SAP Office) was added to the role MY_ROLE (which was created by copying the SAP template). As a result, the yellow traffic lights appear in the menu tree in the above example, The authorization for file access is a 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.

Generate authorization profile

Having maintained the authorizations in accordance with the policies of your company, you can generate the authorization profile. It is only then that the authorizations contained take effect.

During the generation, the Profile Generator collects all entered values and assigns them to a profile. However, one profile can only contain a certain number of authorizations. It is therefore possible that one role has several profiles. You can recognize these profiles from the fact that their names are identical for the first 10 characters, and an appended number starting with 1-99 (SAP Note 16466).

These are known as sequential profiles. This division is performed automatically and is decided by the Profile Generator. It depends on the fields used and on the number of entries.

Assign users

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.

User master record comparison

Integration into the Company LandscapeIndirect Role Assign

Advantages:

Substitution and Transfers

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.

Time-Dependent Planning in Reorganization Processes

SAP Organizational Management allowsboth the validity and the assignment of organizational objects to be planned and activated according to the time available. You must schedule the User Master Record Update program so that profiles can be added or removed based on changes to the organizational plan.

Administration tasks can be done through Organizational Management component.

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.

By choosing the menu path SAP MenuHuman ResourcesOrganizational ManagementOrganizational PlanOrganization and Staffing, you have three options for editing organizational plans:

Create, transaction code: PPOCE

Change, transaction code: PPOME

Display, transaction code: PPOSE

Hint:You can, however, still use thesimple maintenancemode to edit organizational plans (as in previous releases). To switch from the new maintenance interfaceto thesimple maintenance mode, choose the following menu path: SettingsMaintenance Interface.

In the simple maintenance mode, you can edit organizational plans either in the Overall viewer in the Human Resources view. TheOverall view provides specific functions for users of the authorization system and SAP Business Workflow. In this view you can, for example, work with roles. TheHuman resources view

provides specific functions for HR users.

The simple maintenance method uses a tree structure which allows you to rapidly put together a basic framework for organizational plans. You use optimized procedures to do this.

You work in three main windows. Each window covers specific maintenance activities:

TheOrganizational Structurewindow allows you to build up and maintain the organizational structurefor your organizational plan.

TheStaff Assignmentswindow allows you to identify the fundamental staffing details required for an organizational plan.

TheTask Profilewindow allows you to assign roles to jobs, positions, organizational units, and holders of positions (users). Workflow Tasks are also assigned at this level, however, these are not related to authorizations.

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).

Enterprise portal

In the age of e-business, many companies have very complex IT landscapes. This includes information, applications, and services:

The information stored inapplication systemssuch as CRM, ERP, and legacy applications is usually only beneficial in one single system. If, however, this data can be used for specific contexts across application boundaries, this makes the process more efficient for users.

The increasing volume and complexity of information is making it more and more difficult for users to locate indata warehouses the data and evaluations they are required to provide for making decisions.

The Internet has become one of the most important sources of information for employees. One of the challenges associated with this is replacing traditional methods of accessing and using Web information by integrating theintranet and Internetin other business systems in an intelligent way.

Managing, maintaining, and searching for texts, e-mails, CAD drawings, and otherunstructured documentsand contents can prove to be extremely time consuming.

User administration

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:

DBMS provider: Storage in the system database

UDDI provider: Storage via external service providers (universaldDescription, discovery, and integration)

UME provider: Connection of the integrated User Management Engine (UME)

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):

Directory service (LDAP server)

System database

ABAP-based SAP system (as of SAP Web AS 6.20)

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 Add-In (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.

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:

User ID and password

Form-based (standard logon procedure)

Basic authentication (browser displays dialog box)

Digital certificates (in accordance with the X.509 standard)

External mechanisms

Use of a Microsoft Windows logon

Web Access Management (WAM) products

Anonymous logon

Single Sign On

Due to SSO, a single logon to the enterprise portal is sufficient. You no longer need to identify yourself every time you access another application through the portal. This increases user efficiency and satisfaction.

Once the user has logged on successfully, SAP Enterprise Portal issues the user anSAP logon ticket. This represents the users credentials (user-specific, security-relevant information), and is technically stored as a temporary cookie in the users Web browser. The logon ticket contains information about:

UserID

Logon procedure

Validity period

Issuing portal system

Signature of the portal system

If necessary, the name of the SAP reference system

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.

Exchanging Role Information with ABAP-Based SAP Systems

In the following, it is important to distinguish which type of role is meant. A portal roledefines the navigation options (top-level navigation and detailed navigation) of portal users, and the portal content that they can access. In an ABAP-based SAP system, the (classic)(SAP) roleacts as a carrier for authorization profiles and (if you are using SAP GUI) for the structure of the role-based SAP Easy Access menu.

Upload SAP Role to Portal

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).

Transferring Portal Roles to SAP Systems

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.

18