Adm - Idm 920

ADM920
SAP Identity Management (SAP

IdM)
.
.
PARTICIPANT HANDBOOK
INSTRUCTOR-LED TRAINING
.
Course Version: 19
Course Duration: 5 Day(s)
Material Number: 50155435
SAP Copyrights, Trademarks and
Disclaimers
© 2022 SAP SE or an SAP affiliate company. All rights reserved.
No part of this publication may be reproduced or transmitted in any form or for any
purpose without the express permission of SAP SE or an SAP affiliate company.
SAP and other SAP products and services mentioned herein as well as their
respective logos are trademarks or registered trademarks of SAP SE (or an SAP
affiliate company) in Germany and other countries. Please see https://
www.sap.com/corporate/en/legal/copyright.html for additional trademark
information and notices.
Some software products marketed by SAP SE and its distributors contain proprietary
software components of other software vendors.
National product specifications may vary.
These materials may have been machine translated and may contain grammatical
errors or inaccuracies.
These materials are provided by SAP SE or an SAP affiliate company for
informational purposes only, without representation or warranty of any kind, and SAP
SE or its affiliated companies shall not be liable for errors or omissions with respect
to the materials. The only warranties for SAP SE or SAP affiliate company products
and services are those that are set forth in the express warranty statements
accompanying such products and services, if any. Nothing herein should be
construed as constituting an additional warranty.
In particular, SAP SE or its affiliated companies have no obligation to pursue any
course of business outlined in this document or any related presentation, or to
develop or release any functionality mentioned therein. This document, or any related
presentation, and SAP SE’s or its affiliated companies’ strategy and possible future
developments, products, and/or platform directions and functionality are all subject
to change and may be changed by SAP SE or its affiliated companies at any time for
any reason without notice. The information in this document is not a commitment,
promise, or legal obligation to deliver any material, code, or functionality. All forward-
looking statements are subject to various risks and uncertainties that could cause
actual results to differ materially from expectations. Readers are cautioned not to
place undue reliance on these forward-looking statements, which speak only as of
their dates, and they should not be relied upon in making purchasing decisions.
Typographic Conventions
American English is the standard used in this handbook.

The following typographic conventions are also used.
This information is displayed in the instructor’s presentation
Demonstration
Procedure
Warning or Caution
Hint
Related or Additional Information
Facilitated Discussion
User interface control Example text
Window title Example text
© Copyright. All rights reserved. iii

iv © Copyright. All rights reserved.
Contents
vii Course Overview
1 Unit 1: SAP Identity Management (SAP IdM)
3 Lesson: Describing SAP Identity Management

9 Lesson: Explaining SAP IdM Architecture
19 Lesson: Describing the SAP IdM Data Model
37 Unit 2: Forms
39 Lesson: Creating Forms

43 Lesson: Customizing Search Results
45 Lesson: Implementing a Custom User Interface with IdM REST API
53 Unit 3: Jobs
55 Lesson: Creating Jobs

63 Lesson: Creating a Repository
67 Lesson: Creating Repository Jobs
69 Lesson: Implementing Scripts for Advanced Data Conversion
73 Unit 4: SAP IdM Connections to Other Systems
75 Lesson: Connecting to SAP S/4HANA On-Premise

77 Lesson: Connecting to AS JAVA
79 Lesson: Connecting to Active Directory With LDAP
85 Unit 5: Privileges, Business Roles, and Dynamic Groups
87 Lesson: Assigning Privileges

97 Lesson: Describing the SAP Provisioning Framework
103 Lesson: Creating Business Roles
105 Lesson: Defining Automatic Role Assignments
111 Unit 6: SAP IdM Processes and Workflows
113 Lesson: Creating Processes

119 Lesson: Configuring Approval Workflows
123 Lesson: Sending Notifications
125 Lesson: Storing Information with Pending Value Objects (PVOs) and
Context Variables
129 Lesson: Implementing Automatic Approve/Decline
© Copyright. All rights reserved. v

135 Unit 7: Context-Based Assignments
137 Lesson: Defining Context

141 Lesson: Creating Guided Activity Forms
145 Lesson: Provisioning Context Toward Backend Systems
149 Lesson: Assigning Automatic and Conditional Context
159 Unit 8: Advanced SAP IdM Topics
161 Lesson: Configuring the Virtual Directory Server (VDS)

173 Lesson: Managing Passwords with SAP IdM
177 Lesson: Explaining the Reporting Tools
183 Lesson: Debugging Entries
185 Lesson: Running Housekeeping Procedures
187 Lesson: Implementing Hybrid Scenarios
vi © Copyright. All rights reserved.

Course Overview
TARGET AUDIENCE
This course is intended for the following audiences:
● System Administrator
● Solution Architect
© Copyright. All rights reserved. vii

viii © Copyright. All rights reserved.
UNIT 1 SAP Identity Management (SAP
IdM)
Lesson 1
Describing SAP Identity Management 3
Lesson 2
Explaining SAP IdM Architecture 9
Lesson 3
Describing the SAP IdM Data Model 19
UNIT OBJECTIVES
● Explain the main purpose and functionalities of SAP Identity Management

● Understand the important role that SAP IdM plays in an IT landscape
● Identify the components of SAP IdM and understand their purpose
● Connect to SAP IdM
● Describe the Identity Store
● Describe configuration packages
● Create an Identity Store and import SAP delivered packages
© Copyright. All rights reserved. 1

Unit 1: SAP Identity Management (SAP IdM)
2 © Copyright. All rights reserved.

Unit 1
Lesson 1
Describing SAP Identity Management
LESSON OBJECTIVES
After completing this lesson, you will be able to:
SAP Identity Management (IdM) Positioning
Figure 1: SAP Portfolio
Identity Management (IdM) is a key component of the security portfolio of SAP, which is
responsible for managing the identity lifecycle of employees, externals, administrators and
other entities, which require a single point of truth when it comes to their accounts and
authorizations. IdM ensures that the right users have the right access to the right systems at
the right time, thus enabling efficient, secure, and compliant execution of the business
processes. The following are some of the key capabilities of SAP IdM:
● One central location for managing:
- Identities master data and lifecycle
- Permissions (privileges and business roles)
- Granting and revoking authorizations
- Synchronizing data between applications and systems

- Confirming valid assignments (attestation)

- Providing auditing capabilities (who has what access at which time)
- Maintaining passwords across connected systems
Main Challenges and Business Drivers
Figure 2: Business Drivers
Enterprise landscapes tend to be heterogeneous by nature, which could lead to scenarios

including multiple sources of identity data, manual approval processes and incomplete audit
information.
A lot of issues could result from the above challenges – delays in granting/revoking access,
wrong/incomplete provisioning of assignments, inefficient processes and last but not least –
a compliance breach.
When things get so complex that their execution is seen as a burden, rather as an
optimization, then it is time to turn to an IAM solution, such as IdM.
Figure 3: Identity Lifecycle

Lesson: Describing SAP Identity Management
Employee Lifecycle
A typical identity lifecycle enters the career circle usually with a hiring process. This is the
moment when an identity is registered in IdM for the first time, unless it is a returning
employee, for example, a re-hire. During this phase, one of the biggest challenges which IdM
solves is the time for the new employee to become productive, for example, the creation of
required accounts, email, role assignments, and so on.
Normally within the identity lifecycle of an employee, (we use employee as a collective term
for internal, external, or other type of employee), there are many milestones, but not all of
these are relevant for their accounts or permissions. While some obvious events such as New
position impact access that the employee might need, or not need anymore, there are others
such as Promotion, where if the promotion is only related to salary changes, then surely it has
little to zero impact on the IdM profile of the identity. During position changes, it is very
important how access is changed between positions, so that there is no disruption for the
ongoing work of the employee. At the same time, it should be avoided that the employee still
has access related to their old position for long periods of time.
There are also certain master data changes, which unexpectedly can have big impact on IdM.
One example is the change of a family name, which is often the case when people marry.
Although not related to a particular career event, this simple change of names could lead to
processes in IdM for change of email address and even account names, if the account name is
built based on the user's first and last name.
Normally identity lifecycle ends with a resignation or termination of the employee contract.
This process requires equally high attention, as access and accounts of the employee should
be removed in a timely manner. In today’s digital world, the biggest risk of not handling this
process properly would be that ex-employees can still access enterprise data long after they
have left the company.
The following sections identify some additional challenges related to a missing or non-
performing IdM.
Disconnected Systems
When systems are disconnected, applications are unaware of each other, and the following
tasks have to be completed manually:
● Maintaining identity data

● Adding new employees to every required application
● Modifying access rights for employees changing positions
● Revoking access rights from employees that are leaving an organization
Note:
Even connected systems may not comply to the same business logic.
SAP Identity Management helps to automate these processes without requiring a change in
the applications.
High Complexity Challenges

The following are examples of high complexity challenges:

● Difficult or impossible to obtain an overview of all employees:

- Find the correct information
- Access rights to applications
● Errors when entering the information:
- Duplicate entries for the same physical person
- Human errors, for example, the misspelling of attribute values
SAP Identity Management synchronizes and correlates the identity data from all connected
systems. Existing errors could be detected and resolved, while new errors are being
prevented.
Security Risk Challenges

The following are examples of security risk challenges:
● Employees leaving the organization

- Access rights are not revoked
● Change in employee positions
- Granted new access rights
- Previous access rights are not revoked
● Manual procedures involved
- Human errors may cause security flaws
● Lack of auditing
- Who has access to what, for what period and why?
SAP Identity Management controls the complete lifecycle of the identity and thus the risks are
prevented, for example, if an employee leaves the company, the appropriate rights are
revoked either immediately or based on company policies and active country/region/union
laws.
High Maintenance Cost Challenges

The following are examples of high maintenance cost challenges:
● Many manual operations

● Resources could be used more efficiently
● Time-consuming and error-prone
● Employees are not productive on time
As SAP Identity Management automates the processes, you no longer need manual steps and
can free-up human resources. The automation guarantees compliancy to various regulations.
Compliance Challenges
The following are examples of compliance challenges:

Lesson: Describing SAP Identity Management
● SOX - Sarbanes-Oxley Act

● HIPAA- Health Insurance Portability and Accountability Act
● Internal audits
● Risk assessments
SAP Identity Management: Solution Overview
Figure 4: Solution in a Nutshell
● Central management of identities throughout the system landscape

● Rule-driven workflow and approval process
● Extensive audit trail, logging, and reporting functionality
● Governance through centralized and auditable identity data
● Compliance through integration with SAP Access Control
● Compliant and integrated identity management solution to mitigate segregation-of-duties
risks
With SAP Identity Management, SAP offers integrated identity management capabilities for
heterogeneous system landscapes (SAP and non-SAP software), driven by business
processes including the following:
Central Identity Store

The central store consolidates identity data from different source systems (example:
SAP HCM, SAP SuccessFactors) and then distributes this information to the target
systems.
Approval Workflows
Workflows distribute the responsibility for authorization assignments to the different
business process owners and line managers.
Identity Virtualization/Identity as a Service
The data within SAP Identity Management can be accessed using services and standard
protocols such as LDAP.
Integration with SAP Business Suite and SuccessFactors

The integration with human capital management (HCM) solutions, like SAP Business
Suite on premise HCM or cloud SAP SuccessFactors Employee Central, as source
systems for identity information is a key functionality for enabling business-driven
identity management.
Compliance Checks (GRC-AC)
The integration with SAP Access Control offers extensive functions for assuring
compliance and segregation of duties in the role and authorization assignment process.
Definition of Business Roles and Rule-Based Assignment
Business roles are a very powerful concept, which can combine privileges from different
systems into one role, representing all access, which a particular employee on a certain
position would need in order to be productive. You can define different rule sets for the
assignment of those roles to users. This means that the assignment can be performed
automatically based on attributes of the identity.
Audit and Reporting
Provides auditors with one central place to check employees’ authorizations in all
connected systems. The information is time-based and can also be tracked back from
when IdM was activated in the enterprise.
Password Management
A centralized password management reduces calls to the help desk for password resets
and enables password provisioning across heterogeneous landscape.
Provisioning
Handles user accounts and role assignments to SAP and non-SAP applications.
Figure 5: IdM Functional Components
LESSON SUMMARY
You should now be able to:

Unit 1
Lesson 2
Explaining SAP IdM Architecture
LESSON OBJECTIVES
Components of SAP Identity Management
Figure 6: SAP Identity Management Components Overview
SAP Identity Management consists of several components. Some of the components run on
SAP NetWeaver AS for Java, like the Identity Management User Interface. Other components
are stand-alone and are installed separately. The clean installation of SAP IdM from version
8.0 onwards is executed exclusively using another software from SAP – SWPM 1.0.
Exceptions to the general rule are applied for systems, which were upgraded from version 7.2.
The core of the IdM product consists of the Identity Management database, the Keysini utility,
and the configuration packages. In the following sections, we will briefly describe the separate
components and explain their purpose in the big picture.

Figure 7: SAP Identity Management Core Components
The core of the IdM product consists of the Identity Management database, the Keysini utility
and the configuration packages.
Identity Management Database

The Identity Management database holds various types of data, distributed in different tables,
and the business logic in the form of stored procedures that are used to manipulate that data.
Examples include the identity store, the configuration data, audit data, logs, and so on.
The Identity Management database is installed on one of the supported database vendors/
versions.
The installation uses a dedicated database for IdM that should not be combined with a
database of another product, for example, it should not be combined with SAP NetWeaver
Application Server database. The default database name is mxmc_db.
Note:
The prefix mxmc can be changed. This also affects the prefix for the generated DB
users during installation.
The installation creates dedicated IdM database users and roles, which are used by the IdM
components to connect to the IdM database.
Table 1: Database Users Created upon Installation

Database User Use Other Details
mxmc_oper During database mainte- Main IdM database tables
nance and upgrades owner
mxmc_admin For operations from the IdM -

developer studio
To create and initially config-
ure the dispatchers with the
dispatcherutil
mxmc_user - Read-only access to the con-

figuration in the database
mxmc_rt For the runtime engine and Creates temporary tables
dispatchers when executing jobs/tasks

Lesson: Explaining SAP IdM Architecture
Database User Use Other Details

mxmc_prov Used to communicate in IdM -
between the user interface
(UI), administration UI, and
database
The Identity Management Keys Utility

This utility is used to create the encryption keys that are used to secure the connection to the
database and passwords and other sensitive data in the identity store.
It is important to note that used encryption keys from the Keys.ini file should never be
deleted, even if a new key for the encryption is generated. This is because the new key will be
used only for future encrypted values in the database. All old encrypted values keep the
number of the key, with which they were encrypted and those should be available in the
Keys.ini, if we are to successfully recover those values.
Configuration Packages
The configuration package concept was introduced with SAP Identity Management 8.0. A
configuration package is a collection of configuration information including constants, scripts,
repository types, processes, forms, and jobs. Users are granted access to different packages,
which allows multiple users to work on the configuration and transport separately. These
configuration packages are delivered as part of the SAP Identity Management core
component and imported into the SAP Identity Management database to provide a starting
point for the configuration of the solution. Generally, those split in two categories –
provisioning frameworks and connectors. Provisioning frameworks designate a set of
reusable jobs, tasks, and functions that are necessary when provisioning various system
types, for example, SAP Provisioning framework, GRC provisioning framework, and so on.
Connectors are a set of reusable IdM artifacts, which are used for the connection to the target
repositories within IdM, for example, AS ABAP, AS Java, SuccessFactors, and so on.
Identity Management Runtime Components
Figure 8: SAP Identity Management Runtime Components
The Identity Management runtime components include the runtime engine, the dispatchers,
and the SAP Identity Management Dispatcher Utility.
The Dispatcher is constantly running as a service and constantly checks with the database for
any items ready to be processed. When the dispatcher needs to execute a certain job, it can
start a runtime engine process. The Runtime Engine process only runs temporarily and stops
when the job is complete.

Dispatcher
● The dispatcher runs as a service and is responsible for the following tasks:
- Evaluates process decisions
- Starts the runtime engine to execute tasks and jobs
- Housekeeping jobs
Runtime Engine
● The runtime engine runs on Java and is responsible for the following tasks:
- Connecting to external repositories and systems
- Performing the work identified by the dispatchers as due
Identity Management User Interface Components

There are three types of user interfaces: the Web Dynpro end user/key user interface, the
Web Dynpro administration user interface, and the static HTML5 screens for end users.
Additionally, as part of the user interface component, there are three more members –the
two REST API versions (v.1 and v.2), and the portal components for SAP IdM. Below is an
overview of those.
Web Dynpro End User/Key User Interface
Figure 9: SAP Identity Management User Interface Components
The Web Dynpro end user/key user interface is also known as the IDM UI or the IDM Web UI.
It is used by end users/key users/line managers to execute self-service tasks, approvals,
reporting, and tasks on behalf of their role in the organization, which is accessible through the
Manage tab.
Identity Management UI Features
● Main interface for end users, key users, and line managers
● Web interface accessible on the SAP NetWeaver server at http(s)://host:port/idm
● Requires the UME action idm_authenticated (part of IDM_User role) and IdM privileges for
access to tabs such as Manage and To Do

Figure 10: Identity Management UI
Web Dynpro Administration User Interface

The Web Dynpro administration user interface, also known as the IDM Admin UI, is used to
configure and operate the IdM system, for example to connect new repositories, monitor
queues, jobs, and so on.
Web Dynpro Administration User Interface Features
● Main interface for IdM system administrators (access granted using standard MX_ roles)
● Web interface accessible on the SAP NetWeaver server at http(s)://host:port/idm/admin
● Requires the following UME actions to enable the Monitoring tab:
- idm_monitoring_administration (not part of any role by default – create custom)
- idm_monitoring_support (readonly access – not part of any role by default – create
custom)
Figure 11: Web Dynpro Administration UI
The IDM User Interfaces are accessed through the SAP NetWeaver Java server and
authentication is handled completely by the SAP NetWeaver User Management Engine
(UME). In order for a user to be able to access the UIs, the user account in UME should be the
same as the identity account in the IDM Identity Store. In order to optimize performance,
some of the Web Dynpro UIs are cached on the server. To refresh the cache when certain
changes are not visible in the browser, use “?NoCache” at the end of the URL.

Static HTML5 User Interface

Apart from the Web Dynpro interfaces, SAP IdM offers a static HTML5 UI. SAP Identity
Management User Interface for HTML5 can be used by all users to maintain their own profile
information and request new roles (self-service). Authorizations are grouped into business
roles, again made available to end-users, who can request assignment of the business roles.
SAP Identity Management User Interface for HTML5 only supports assignment requests for
business roles, that is, users cannot request privilege assignments. The HTML5 screens
cannot be modified and are not dynamic, thus should be used as is.
REST API
As mentioned, in addition to the UIs provided by the solution, SAP Identity Management
offers a REST API to provide access and management on Identity Store data by external
applications or custom-developed UIs. It comes in two releases (v.1 and v.2). While v.1 is
rarely used nowadays, the v.2 has a broad usage scope. It supports both JSON and XML
format and implements the ODATA v2.0 protocol. It is the API behind the HTML5 screens of
IdM and also can be used for development of custom SAPUI5 screens, which further enhance
the usability of SAP IdM.
Portal Components for SAP IdM

The last of the user interface components of SAP IdM is the portal content. It is used for
integration to the Universal Worklist (UWL). UWL gives users a unified and centralized way to
access their work and relevant information in the portal. It collects tasks from multiple
provider systems in one list for easy access to all tasks. With this component, you can also
include tasks that originate from SAP Identity Management, for example, approvals.
Identity Management Developer Studio
Figure 12: Identity Management Developer Studio Components
The Developer Studio is used to configure the scenarios and processes in the IdM. It consists
of two main components: a plug-in for Eclipse, which is installed on the computer of every IdM
developer, and a central component called Developer Studio REST service. Those two
components communicate in order to establish the connection to the IdM database. The
Developer Studio REST service is deployed on SAP NetWeaver Application Server Java.

Figure 13: IdM Developer Studio Architecture
The authentication between the Eclipse plug-in and the REST service is handled by UME. The
Developer Studio REST Service connects to the IdM database using the mxmc_admin DB
user.
In addition to authentication, the Developer Studio service also checks that the authenticated
user is defined as an IdM developer before it allows any operation.
Figure 14: IdM Developer Studio Connection Configuration
To connect from Eclipse to the IdM database through the IdM Developer Studio REST service,
the developer needs to maintain the host and port number of the appropriate SAP NetWeaver
Java server, where the Developer Studio REST is installed. This communication runs over a
secure http channel (https), thus the port for the connection data should be the secure port of
the SAP NetWeaver Java server. The data source name should be the same as the one
maintained during the installation of IdM (part of the post-installation procedure). It can be
found in the NetWeaver Administrator of the respective SAP NetWeaver Java server under
the sub-component Application Resources.

Figure 15: IdM Developer Studio Service Configuration
The IdM Developer Studio Service is configured by the IdM Administrator before it is used by
IdM Developers. As a minimum, the database connection, the keys encryption file and the
SAP NetWeaver Java certificate have to be configured so that a successful connection is
established. The same keys.ini file is used independently of the number of database
connections established from one SAP NetWeaver Java instance. If you have to use different
encryption keys, you will need to use additional Developer Studio REST services running on a
different host.
Additional Components
● Virtual Directory Server (VDS):

Provides virtualized directory service information, offering LDAP support (when running
standalone) and SPML support (when running on AS Java). It can connect to various
external SAP and non-SAP systems. You can use the VDS to provide LDAP/SPML access
to Identity Center database data.
Figure 16: VDS image
● Logon Help
Provides self-service to reset the password of a user directly in the Microsoft Windows
Domain by answering a set of security questions maintained in IdM.

LESSON SUMMARY


Unit 1
Lesson 3
Describing the SAP IdM Data Model
LESSON OVERVIEW
In this lesson, you will learn how to describe the SAP IdM data model.
LESSON OBJECTIVES
Identity Store Schema

The Identity Store holds identity-relevant entries like users, roles, assignments, and so on.
The main identity store represents the central single source of truth. For correlation
purposes, you can first store data from the connected systems in a staging area/Staging
Identity Store and after successfully correlating the account with the main identity, merge it
into the main identity store.
Figure 17: Identity Store
SAP Identity Management maintains information in the Identity Store including the following:
● Users
● Roles and privileges
● Assignments
● Groups

Each Identity Management database can have multiple identity stores, but only one can be
the main one.
An identity store is created with a default SAP schema (a set of entry types and attributes)
that can be extended. The attributes within the schema can be pre-defined or automatically
created when new entries with unknown attributes names are identified. For the main identity
store, it is recommended to keep the pre-defined attributes. When using staging areas, it is
common practice to enable the automatic creation of new attributes.
Identity Stores contain instances of entry types and attributes defined by the Identity Store
Schema.
Identity Store Entries: Important Characteristics
● Instances of an Entry Type

● Persisted within an Identity Store
● Can be searched, viewed, and modified in the IdM Web UI
● Can trigger event tasks, which may result in provisioning or deprovisioning
● Can be synchronized to and from external systems
● Can be read or written by the runtime engine
● Can have links between entries:
- Assignments (for example, Role/Privilege to Person)
- Hierarchies (parent/child dependencies – for example, Role, Group)
- References (for example, manager of a person)
Identity Store Schema Data
● Entry types, such as the following:

- Person
- Role
- Privilege
- Group
● List of attributes, such as the following:
- First and last names
- Address and telephone number
- Entry types display names
- MSKEYVALUE
Identity Store Attributes

Attributes define the purpose of a given value. Note the following information about
attributes:
● Attribute storage

Lesson: Describing the SAP IdM Data Model
- Can store values for predefined datatypes (text, numeric, binary, and so on)
- Can have multiple values
- Can represent a reference to another entry (for example, manager of a person)
- Can keep historic values
● Attribute presentation
- Can be customized to have different display names with translation support
- Can be customized to have different UI element visualization (for example, SingleLine
or MultipleLine)
● Attribute value
- Can be checked for uniqueness – no other entry within the IdStore can have the same
value
- Can have a minimum and maximum length (only on UI level)
- Can be checked against specific regular expressions (only on UI level)
- Can be limited to a pre-selected list – allowed values (for example pre-defined or
dynamically determined values (SQL), or fixed value help table with values)
Note:
One Attribute definition can be attached to multiple entry types, for example,
DISPLAYNAME.
The Identity Store Attributes Event Processes tab allows you to use assignment triggers
instead of event processes for attributes when possible. These settings can have an impact
on a system’s performance.
Important Identity Store Attributes
● MSKEYVALUE
- Unique key within the whole identity store across all entry types
- As an example within the MX_Person entry type, the value of this attribute could
contain the employee ID or e-mail address (as long as those are unique in the
enterprise)
- Only the first 400 characters are searchable, thus should be unique
● DISPLAYNAME
- The display name for an identity
● MX_*,SAP_*, SAPC_*
- Default attributes, which are part of the identity store schema
- When creating new custom attributes, make sure that they do not start with MX_ , SAP_
or SAPC_
● MX_DISABLED

- Assigned to a person
- Used for enabling/disabling logon to target systems
- Usually is attached to a trigger
● MX_INACTIVE
- Assigned to a person or a custom entry type defined as Identity
- Used for setting an entry as inactive (similar to delete, but without removing the data
from IdM)
- Entries with MX_INACTIVE are not visible in the UI (unless additional configuration is
done)
● MX_IDENTITY_CATEGORY
- Assigned to a person and used for license management
■ 0 (or missing): identity category undefined
■ 1: internal identity
■ 2: external identity
■ >2: for future use
● MX_ENTRYTYPE
- Defines the type of entry (for example, MX_PERSON)
● MX_APPROVERS
- Holds the list of legal approvers
● MX_OWNER
- References the owners of the entry
● MX_ENCRYPTED_PASSWORD
- Provides two-way encrypted password for password provisioning
Identity Store Entry Types

Entry Types
● Specify the definition for instances of the entry type

● Define display and search forms as well as access limitations for search and user
attributes
● Specify processes for add, modify and delete events
● Set the mandatory, list and allowed attributes for the entry type
Entry Type Properties
● Display name of the entry type used in IdM UIs

● Purpose of the entry type (does it hold identities or context and if it is searchable (available
in the IdM UI))
● Access control of the entries of a specific type (who can see whom)
● Display and search forms (defines how entry type is displayed and how it is searched)
Entry Type Classes
● Leaf-Object
- An entry type, which cannot contain other entry types
- Example: MX_Person → MXREF_MX_PRIVILEGE (MXREF_<entry type>)
■ Attribute, which is created automatically, when references between entry types are
defined
■ Reference to the parent entry (assignment)
● Container-Object
- An entry type which can contain other entry types
- Example: MX_Role → MXMEMBER_MX_PERSON (MXMEMBER_<entry type>)
■ Attribute, which is created automatically, when references between entry types are
defined
■ Reference to the child entry (assigned entries or hierarchy)
Figure 18: Schema Example

Identity Data
Figure 19: Identity Data
Now that we know how data is stored in the identity store (using entry types and attributes),
let’s review briefly how this data is distributed and handled when target systems are
connected to SAP IdM.
Each connected repository stores its own user information such user id/logon id,
authentication information like passwords and authorization data – which roles does the
respective user has in the repository in question.
SAP Identity Management provides the means to correlate the various User Accounts either
automatically, semi-automatically or manually. This enables the concept of having only one
identity in SAP Identity Management. Authorization data is synchronized with the appropriate
systems and applications providing an easy way to retrieve an overview of all authorizations
of a given identity.
The master record of an identity in the identity store includes attributes from various
repositories. The attributes included depend on the requirements of the user and the quality
of the attributes within each of the connected repositories. For example, the master record
may retrieve the employee's personal data from the company's HR system. It then retrieves
the employee's phone extension from the company phone system and retrieves the
employee's email from the company's e-mail system. This data is then orchestrated in SAP
IdM following the organization needs and requirements.
Identity data consists of different information that is used for decisions on authorizations.
Therefore, security depends on the quality of the following data:
Identity Data
● Personal data
Personal data consists of short data elements such as names, phone numbers, e-mail
addresses, pictures, or certificates.
● Pointer data
Pointer, reference data points or links from identity to other objects such as web pages,
document archives, files, and so on.
● Assignment data
Assignment data refers to roles, privileges, or other objects that grant certain
authorizations to an identity.

● Read-mostly data –high read ratio

● Authorization Data requires high quality master data
Data Ownership Challenges
● Determining which system owns which data

● Managing different applications:
- Different identifier
- Different attributes
- Different way of storing data
- Different semantics of the same physical data (title – in some systems means
salutation, in others might refer to position)
● Determining how to map role structure across applications
● Determining how to make a business role model incorporating multiple requirements and
privileges
If you cannot correlate identities automatically, you will need to decide how to resolve the
issue. A solution would be to have a data steward correlate the identities manually, but should
be avoided where possible, since this could lead to unwanted human errors.
That is why a very important role plays the data quality and consistency across all systems
including IdM. With cleansed and organized data with clear data ownerships it is much easier
to have a streamlined and optimized security processes.
Figure 20: Configuration Packages
A package is the smallest part of the configuration that is maintained as a unit. This could be a
connector for a repository type or a collection of utilities that are used by other packages.

Users are granted access to different packages which allows multiple users to work on the
configuration and transport separately.
● Contains configuration, which includes:

- Constants, scripts, repository types, processes, forms, jobs
● Globally unique name
- Qualified name = [base qualified name – defined during installation and cannot be
changed].<given package name>
- Example: [com.training].<NewPackage1>
● Authorizations
- View, import, layout developer, developer, owner
● Public objects with qualified name
- Processes, scripts, and forms may be public, and used by other packages
- Repository types are always public
- Non-public/private objects can be used only within the package
Configuration Package Benefits
● Configuration authorization
- Users can have different access to different packages
● Multiple developers
- Can work on different parts of the configuration
- No danger of overwriting each other changes
● Revision control
- Each package check-in is stored in the database
● Transport
- Each package can be transported separately (keep dependencies in mind)
Keep the content of a package as small as possible, for example, the workflow for a given
business scenario, such as employee on-boarding. This simplified testing and transport
procedures. It should be also avoided to define too small packages. They should be business
meaningful.
Package Authorization
● Owner: Can change all package contents including authorizations for the package
● Developer: Can change all package contents excluding authorizations
● Layout Developer: Can change only forms within the package
● Import: Can import new versions of the package

● View: Can view all package contents, but cannot change anything
Package Types
There are several package types including the following:
Table 2: Package Types

Package Types Description
SAP package SAP read-only package A package distributed by SAP
that cannot be modified by
customers. For example, the
engine package.
SAP modifiable package A package distributed by SAP
that can be modified by cus-
tomers. For example, a pack-
age for a specific connector,
such as com.sap.idm.con-
nector.hana.
When a package of this type
is modified, its type changes
to SAP package modified by
customer.
SAP package modified by A package distributed by SAP

customer that used to be an SAP modi-
fiable package that was later
modified by customers.
Customer package A package created by cus-
tomers.
Package Versioning
● When creating a package, the initial version is set to 0.0

● The minor version is incremented automatically every time the package is checked in
● The major version is incremented every time a public object is changed, then the minor
version is reset to 0
● When making a package copy, the initial version is set to 0.0 for the copy
Editing a Package: Versioning Information
● Check out (lock) for editing

- Requires proper authorization
- Only one user can check out a certain package at a given point of time
● While the package is checked out

- Only the user who checked out the package can edit it
- Updates are made directly in the database
- Any user can run jobs and processes and access forms
● Check in
- Updates revision control
- Closes the edit mode for the package
- Force check in is available only for authorized users
● Revert restores the package and the database to the version before it was checked out
Package Dependencies
When creating package names, be sure that each package in your IdM system has a unique
name. Package dependency is established based on the qualified name. If the name is
changed, any established dependencies with the old name are broken. The qualified name
should contain only alphanumeric values (A-Z, a-z, 0-9), underscore(_) and period(.).
Referencing Processes in Other Packages
● Only processes can reference processes in other packages

- You cannot reference from a task to a process from another package as an event
process (for example, OnOK) - to be validated
● Public processes may be referenced as an event process for:
- Attributes (onCreate, onModify, onDelete)
- Entry types (onCreate, onModify, onDelete)
Referencing other Objects
● ID
- Internal ID: Every new object receives a new ID (taskid, jobid, and so on)
- When changing an object, the object receives a new ID
● GUID
- Global unique ID: Every new object receives a new ID and if it is a new object, a new
GUID is generated.
- Every modified object receives a new ID and inherits the GUID from the previous version
of the object, which gets a new generated GUID.
- Both new and old process are stored. The old object version gets assigned a new GUID
and is marked as “Obsoleted”. Pending provisioning queue items are executed against
the old GUID.
● Qualified name
- Created based on the baseQN and the objectname

- References between packages

- References from package to repository
● Always use QN for referencing public objects, do not use GUID or ID
When changing a process, the modified process will keep the existing GUID.
For example, you have package A, version 1 and process P with GUID 123. You import a new
version of the package – version 2, which contains the same process P with same GUID 123.
Before importing version 2, the database already contains process P with GUID 123 and
probably some pending items in the provisioning queue. Upon importing version 2, the new
process in the database keep the old GUID 123 (but receives a new ID) and new items will
point to it. The old process gets a new GUID, but reference in the provisioning queue is by ID.
Therefore old items in the queue are executed against the old version of the process and
newly added items will get the new process version. The old version of the process is not
visible anywhere.
Figure 21: Provisioning Framework
The SAP Provisioning Framework is distributed in multiple configuration packages. There is

one central package (called the engine package) that contains the core part of the framework.
There is a package for each connector type, and one custom package that can be used for
customization of the standard connector packages. There are also helper packages like the
Notification package that is used for sending notifications, and the Forms package that
provides standard web forms. You only need to import the packages that are required for
your scenarios.
Connector Packages
● Repository types
- Defines the parameters needed for the connection to the target repository
- The package may provide more than one repository type
● Jobs
- Initial load job
- Other jobs depending on the connector type
● Process reference to the SAP Provisioning Engine Package,which are linked as constants
in the respective repository type

- Provision
- Deprovisioning
- Modify
● List of pre-defined public processes with specified names:
- AssignUserMembership, RevokeUserMembership
- CreateGroup, DeleteGroup
- CreateUser, ModifyUser, DeleteUser
- EnableUser, DisableUser
- SetUserPassword
- CreateCompanyAddress, ModifyCompanyAddress, DeleteCompanyAddress
Package Transport
Figure 22: Transporting Across Multiple Landscapes
The transport concept within SAP IdM is realized through package export/import. Usually
IdM is installed in as many tiers as the systems it provisions to. In the above example of a 3-
tier landscape, the purpose of the systems is as follows:
● Dev (Development system)

- New features are implemented
- New patches and service packs are applied here first
- Initial developer tests are performed
- Once ready, packages are checked-in and exported from the Developer Studio
● Test/QA
- Import packages from development
- Business and Integration Tests
- Keep both the hardware and software configuration as close to production landscape
as possible

- Do not do any direct changes in the system, unless they are minor fixes, which are also
automatically applied to Dev
● Production
- No direct changes in the system
- Import only tested packages from Test/QA
- If the setup and configuration is done properly, the key users should be able to operate
the solution using only the user interface
- Developer Studio and an SQL editor might be needed in problematic cases for root
cause analysis
Package Export
● In order to start a transport, a package should be exported

● A package can only be exported if it was previously checked-in
● Packages are the only supported form of transport between SAP IdM systems
● Transport on any other lower level (e.g. jobs, tasks, database) is not supported and should
not be attempted (e.g. might lead to an inoperable system)
● Approvers defined on the approval task are exported with their MSKEYVALUE, not with the
MSKEY
● Scheduling rules for repository jobs are set automatically to “On demand”, since job rules
are not exported
Package Import
● Dispatcher names should match across systems in order to assign the transported objects
to the same dispatcher as in the source system.
● Packages contain references to various other objects. For the import to work correctly,
those objects should be available in the target system prior to the import.
● If the package is imported for the first time, the contents are imported as-is.
● If package already exists, then:
- New objects in the package are imported in the target system
- Modified package objects overwrite the existing objects with the exception of package
constants, which are visible in the Admin User interface
- Deleted package objects are preserved in the target system. Those can be deleted
manually. Alternatively, you can delete the package in the target system and import it
again from the source system
● One and the same package name cannot be imported in different identity stores of one
and the same SAP IdM system
● During import, a process called Obsoletion is started. It makes sure that new versions of
the jobs and tasks, which are running at the moment, continue to do so uninterrupted and
newly scheduled ones will use the new definitions

● If approvers are not found in the target system with their MSKEYVALUE, they are omitted.
LESSON SUMMARY

Unit 1
Learning Assessment
1. The overall purpose of IdM is to manage the user life cycle.

Determine whether this statement is true or false.
X True
X False
2. Which of the following components are part of the IdM architecture?

Choose the correct answer.
X A Identity Management Database, Management Console, User Interface, and

Runtime Components
X B Identity Management Database, IdM Developer Studio, User Interface, and

Runtime Components
X C Identity Store, Management Console, User Interface, and Runtime Components
X D Identity Store, Runtime Components, Identity Management Database, and

Management Console
3. For which Identity stores is it recommended to select the Automatically Create Attributes
checkbox?
X A For the main identity store
X B For staging area identity stores with unknown attribute structure
X C For any kind of identity stores
X D This checkbox should never be selected, since it might lead to errors with the IdM
schema

Unit 1: Learning Assessment
4. Which of the following objects can be declared public?

Choose the correct answers.
X A Configuration packages
X B Processes
X C Constants
X D Scripts

Unit 1
Learning Assessment - Answers
1. The overall purpose of IdM is to manage the user life cycle.

X True
X False
2. Which of the following components are part of the IdM architecture?

X A Identity Management Database, Management Console, User Interface, and

Runtime Components
X B Identity Management Database, IdM Developer Studio, User Interface, and

Runtime Components
X C Identity Store, Management Console, User Interface, and Runtime Components
X D Identity Store, Runtime Components, Identity Management Database, and

Management Console
3. For which Identity stores is it recommended to select the Automatically Create Attributes
checkbox?
X A For the main identity store
X B For staging area identity stores with unknown attribute structure
X C For any kind of identity stores
X D This checkbox should never be selected, since it might lead to errors with the IdM
schema

Unit 1: Learning Assessment - Answers
4. Which of the following objects can be declared public?

X A Configuration packages
X B Processes
X C Constants
X D Scripts

UNIT 2 Forms
Lesson 1
Creating Forms 39
Lesson 2
Customizing Search Results 43
Lesson 3
Implementing a Custom User Interface with IdM REST API 45
UNIT OBJECTIVES
● Create a custom IdM UI

● Customize a default display and search task
● Invoke an SAP IdM API

Unit 2: Forms

Unit 2
Lesson 1
Creating Forms
LESSON OVERVIEW
In this lesson, you will learn how to create forms.
LESSON OBJECTIVES
Forms Overview
Forms stand for the way that end users, key users, and administrators perform certain
activities on entries in SAP IdM. Standard forms are dynamically generated based on
configuration performed with Developer Studio. They are always defined for a concrete entry
type and have a list of attributes, which are visible in the UI.
In the SAP IdM Store schema, you can define which attributes relate to which entry type.
Following the same logic here, attributes that do not belong to the selected entry type for the
form cannot be assigned to it. Forms can be organized in hierarchical folders. In the UI, these
folders can be declared as visible or not visible. The folder hierarchy is visible only when
choosing a task from within the Manage tab of the standard SAP IdM UI.
Form Types
Form types define the purpose of and the reference for a form. These include the following:
● Regular form: The normal user interface form.
● Access Control form: A form used for defining the access control of attributes.
● Display form: A form used for display of an entry type.
● Search form: A form used for search of an entry type.
Form Access Control

Form Access Control: Who has Access
When a form is opened in the Developer Studio, one of the tabs that displays is the Access
Control tab. It is used to determine who is allowed to execute the task, and on which entries.
The following options are available:
● An anonymous user (guest)

● Any logged-in user
● A concrete logged-in user with an assigned MSKEYVALUE
● Any logged in user that has a particular privilege or role

Unit 2: Forms
SQL filters are supported for backwards compatibility only. Do not use them from SAP IdM
8.0 onwards for other actions because they can affect performance.
Form Access Control: On Behalf of Options

Access is granted to the following:
● Everybody
- Any entry
● User or identity store entry
- One specific entry
● Relation
- Self: Self-service
- <Entry> Manager: Any entry where the user is a manager (MX_MANAGER)
- <Entry> Owner: Any entry where the user is an owner (MX_OWNER)
- <Entry> Member: Any entry where the user is a member
- Member of same: Same entry assigned
● Filter/SQL query
- Can be used to define more complex On behalf of rules
Form Layout Configuration

Another tab in the forms configuration is Layout configuration. In this tab, the configuration
for the dynamic UI is defined. Attributes are ordered in a table according to their appearance
on the screen. The following special UI elements are available also:
● Tab: Everything below a declared Tab row in the attributes list is in that tab until another
Tab row is created.
● Column: Another column of UI controls, for example, a two-column layout.
● Section: Sections appear with a given title, for better visual representation on the screen.
● Line: A horizontal line drawn for separation.
● Label: A header with custom text.
Form Presentation
In addition to the layout, you can control how the form is visualized in the IDM UI, including the
following:
● Display Name: Translatable, shown on various places in IDM UI (self-services, managed

tasks).
● Help URL: Shown as a Help link that can be followed for further information.
● Task Header: Shown on top of any UI controls when opening the task.
● Task Description: Shown in self-services next to the name or as a tooltip in the Choose
Task dialog.

Lesson: Creating Forms
● Submit/Modify Button Caption: Allows you to change the captions of the form action
buttons (for example, Save & Modify).
● Confirmation Message: A message that displays upon successful submit.
SAP Delivered Forms

Form Packages
The following SAP-delivered form packages are available:
● The default forms package (com.sap.idm.forms.default)

- Identity store management (create, modify, and delete)
- Default search and display tasks
● The html5 forms package (com.sap.idm.forms.html5)
- Access control tasks used by the UI5
Note:
If you upgrade from 7.2, you will have the UI Tasks from 7.2 Provisioning
Framework migrated to Forms. Consider replacing them with the ones from
the default forms package of version 8.0.
Access Control
The following access controls are set by default for the display and search forms:
● Self-service forms can be executed by any user and are visible in the Self-service tab of the
standard UI.
● Other forms require the MX_PRIV:IDS:MANAGE privilege (this gives access to the Manage
tab).
● In order to validate if the logged-in user has permissions to execute the forms, additional
access control checks apply after opening the Manage tab.
● Even if the form is accessible to the logged-in user, it might be the case that all referenced
objects require additional permissions to be expanded.
LESSON SUMMARY

Unit 2: Forms

Unit 2
Lesson 2
Customizing Search Results
LESSON OVERVIEW
In this lesson, you will learn how to customize search results.
LESSON OBJECTIVES
Display Form
The purpose of a display task is to show some default information in the search results. It is
displayed below the search table after selecting an entry from the results. It is recommended
to have a display task for each entry type. If no display task is assigned, a default one with a
limited number of attributes is generated.
● Purpose of the display form:

- Shows more information from the search results upon result entry selection
- Opens details of a referenced entry (for example, manager, role, or privilege)
● Specifics of the display form:
- Attributes on the task are visible to everyone
- Do not include sensitive information in this form
- If undefined, only basic details are displayed
Search Form
● Searching for entries in the IdM user interface:

- Searches take place on the attributes defined in the search task.
- You can define your own search task to customize how to search for entries.
- If you use the REST API, these tasks are used to search and define the list of attributes
a search result contains.
● Access control for search tasks:
- Ignored: Customization is valid for everyone.
● Mandatory and read-only flags for attributes list within a search task:
- Ignored: Not relevant within a search task.

Unit 2: Forms
Search Results
Customizing Search Results
When customizing search results, note the following points:
● The search result is always in a table.

● Columns in the table represent the entry type attributes marked as List.
● The column order is based on the order of the entry type attributes.
The display and search forms are attached to an entry type. This reference is kept as an
incoming dependency to the package, where the form is defined. You can define display and
search forms in multiple packages, but the first form imported occupies the vacancy. The
import of the second form would result in a “target already occupied” error for the
dependency. You can see which display or search form is attached to an Entry Type within the
General tab of the Entry Type in the Developer Studio. The state of the dependency can be
seen in the properties of the package on the Dependencies tab.
Figure 23: The Display and Search Forms
LESSON SUMMARY

Unit 2
Lesson 3
Implementing a Custom User Interface with
IdM REST API
LESSON OVERVIEW
In this lesson, you will learn how to implement a custom user interface.
LESSON OBJECTIVES
SAP IdM REST v2 API
Figure 24: REST API v2
The REST API v2 of SAP IdM implements the Open Data Protocol (Odata) in version 2.0. It
supports both XML and JSON formats. Version 1 of the REST API is still available for
backwards compatibility, but should not be used for new developments. When using the REST
API, an SSL communication channel is recommended, for example, https.
All components of the REST API v2 are deployed on the SAP NetWeaver AS Java server and
thus have dependencies to the underlying stack. One of these dependencies is the
authorization and authentication, which is executed by the UME of the Java stack. In order to
get access to the REST API, certain UME actions need to be present within the profile of the
logged-in user. Both idm_authenticated and idm_authenticated_restapi UME actions are
needed for proper access to the API.

Unit 2: Forms
REST Functionality
Figure 25: REST Functionality
The following operations are supported with IdM REST v2:
● GET
Retrieves an entity or a set of entities
● POST
Creates a new entity
● POST & MERGE
Updates an entity
● Some examples for calls to service URIs are as follows:

- Search for entries: [GET] /idmrestapi/v2/service/ET_MX_PERSON
- Retrieve entries and attributes: [GET] /idmrestapi/v2/service/
ET_MX_PERSON(ID=7894,TASK_GUID=guid'35B264BF-A75A-447D-
A4EA-7894725245CE')
- Update entries: [POST] /idmrestapi/v2/service/
ET_MX_PERSON(ID=7894,TASK_GUID=guid'D092EA23-9E5D-4FC7-9467-1E1D0BBE
3629')/ HTTPS/1.1
● X-HTTP-METHOD:MERGE
● Get particular attribute value: [GET]/idmrestapi/v2/service/
ET_MX_PERSON(ID=7894,TASK_GUID=guid'35B264BF-A75A-447D-A4EA
7894725245CE')/MV_MX_PHONE_ADDITIONAL
● Get open approval requests: [GET] /idmrestapi/v2/service/TaskCollection
● Processing of approvals: [POST] idmrestapi/v2/service/Decision?
InstanceID='1x4'&DecisionKey='APPROVE'

Lesson: Implementing a Custom User Interface with IdM REST API
LESSON SUMMARY

Unit 2: Forms

Unit 2
Learning Assessment
1. Which of the following is an example of a self service that end users can access in the user
interface?
X A Request an information change in a back-end system
X B Create a UI task
X C Change personal data
X D Approve authorization requests
2. A manager wants to execute a specific task on the users he or she directly manages.
Which access control should you set to allow this?
X A Filter/SQL Query
X B Logged-in user
X C Relation-Self
X D Relation-Manager
3. What rules should you use to design a user interface task?

X A Use attribute presentation text keys to minimize visual text inconsistencies.
X B Always use the Mandatory attribute.
X C Show only the essential information in the UI for the task at hand.
X D Use structure elements like Sections to organize the attributes on the task in
alphabetical order.

4. What is the purpose of a display task?

X A To show information for an entry type in the Developer Studio.
X B To show information for a selected search result.
X C To show sensitive information.
5. What is the purpose of a search task?

X A To define attributes used when searching for a specific entry.
X B To enable basic search.
X C To enable automatic system search.
X D To set search permissions for specific users.
6. The REST API v2 can be used to read from identity stores, but not write to them.
X True
X False

Unit 2
1. Which of the following is an example of a self service that end users can access in the user
interface?
X A Request an information change in a back-end system
X B Create a UI task
X C Change personal data
X D Approve authorization requests
2. A manager wants to execute a specific task on the users he or she directly manages.
Which access control should you set to allow this?
X A Filter/SQL Query
X B Logged-in user
X C Relation-Self
X D Relation-Manager
3. What rules should you use to design a user interface task?

X A Use attribute presentation text keys to minimize visual text inconsistencies.
X B Always use the Mandatory attribute.
X C Show only the essential information in the UI for the task at hand.
X D Use structure elements like Sections to organize the attributes on the task in
alphabetical order.

4. What is the purpose of a display task?

X A To show information for an entry type in the Developer Studio.
X B To show information for a selected search result.
X C To show sensitive information.
5. What is the purpose of a search task?

X A To define attributes used when searching for a specific entry.
X B To enable basic search.
X C To enable automatic system search.
X D To set search permissions for specific users.
6. The REST API v2 can be used to read from identity stores, but not write to them.
X True
X False

UNIT 3 Jobs
Lesson 1
Creating Jobs 55
Lesson 2
Creating a Repository 63
Lesson 3
Creating Repository Jobs 67
Lesson 4
Implementing Scripts for Advanced Data Conversion 69
UNIT OBJECTIVES
● Create jobs to read data from a repository or a temporary table

● Enable delta to reduce the load on the systems
● Understand and create repositories
● Run repository jobs
● Use scripting for advanced logic and data transformation

Unit 3: Jobs

Unit 3
Lesson 1
Creating Jobs
LESSON OVERVIEW
In this lesson, you will learn how to create jobs.
LESSON OBJECTIVES
Job Definition and Execution

Job Definition - Jobs
Jobs and passes in SAP Identity Management are used for the following activities:
● Jobs are a collection of passes that run sequentially. Jobs can be scheduled for periodic
execution using scheduling rules. Jobs do the following tasks:
- Synchronize master data and access.

- Read information from target systems.
- Do initial load.
- Reconcile.
Job Definition - Passes
● Passes work in a job and carry out the following tasks:

- Read from and write to the Identity Store.
- From Pass: Reads from a source system or file and writes into a temporary database
table.
- To Pass: Reads from the database of the Identity Store or other and writes to a target
system of choice, or to the Identity Store
- Data mapping, transformation, and cleansing for attribute values.
The Temporary Database (From-Passes)

Temporary database tables are created by From-passes. The Temporary database field gives
the name of the database, the Database table name field gives the name of the table, and the
definition section in these passes indicates which columns are to be created in the temporary
database. Temporary database tables created in this way are stored in the MXMC_RT user
schema.

Unit 3: Jobs
Creating a Sub-Table (From-pass)

When entering definitions for a From-pass, you can create a sub-table in the temporary
database if you want to split a multi-value field into separate values. This enables a "reverse
lookup" to find all entries with a specific value. The unique identifier (UID) in the main table is
used as a reference (RefID) in the sub-table.
To create a sub-table, select TABLE as the data type for a column in the temporary database.
Use the Define sub-table dialog box to specify the properties of the sub-table. To modify the
sub-table, use the … button next to the Target column in the grid.
The fields contain the following values:
● Table name
● Column name
● Data type
● Field size
● Multivalue separator
Temporary Database Structure
Figure 26: Temporary Database Structure
The temporary database structure includes the following components:
● Tables are created on-the-fly according to from pass-definitions.

● Fields can be indexed for performance (as used later by To Passes).
● Subtables can be used for storing multivalue attributes (for example, group
memberships).
From-Passes — Source Tab (Read from)

From-passes read data from a repository and write data to a temporary database. The
following are types of From-passes:
● FromASCII: Reads from a file.

● FromLDAP: Reads from an LDAP directory.

Lesson: Creating Jobs
● FromLDIF file: Reads from an LDIF file (LDAP exported file).

● FromGeneric: Generates the information using scripts.
● FromDatabase: Uses SQL to retrieve the information.
● FromCustom: Uses a custom Java class (SAP or non-SAP).
From-Passes — Destination Tab (Write to)

● After the read, From-passes write to a temporary table.
- The table is created and updated on the fly, based on pass definitions.
- Usually the IdM database is used for the temporary table, but the user can specify a
different database.
- The table can be cleaned up on each run.
To-Passes — Source Tab (Read from)

To-Passes gather information from single or joined tables in the Source tab of the pass using
SQL.
To-Passes — Destination Tab (Write to)

Gathered information from the Source tab is processed in To-passes:
● ToIdentityStore: Writes directly to the identity store of SAP IdM.

● ToASCII: Writes to a file.
● ToLDAP: Writes to LDAP directory.
● ToLDIF file: Writes to a LDAP file.
● ToGeneric: Processing information using scripts.
● ToDatabase: Uses SQL to store information.
● ToCustom: Uses custom Java class to process the information.
● Shell execute: Executes shell commands/scripts.
Job Execution and Scheduling

Job Execution Process
The process of executing a job involves the following steps:
1. The Dispatcher detects a new job in the queue. Starts corresponding runtime
2. Runtime requests a job and locks for execution. Prepares for next job execution based on
scheduled time, engine type, and machine or machine name defined
3. The job is executed.
● Periodically creates a trace file in the Jobs folder of the IdM Runtime
● Report status
4. The job is finalized.

Unit 3: Jobs
● Writes log data into DB (but trace file stays next to the IdM Runtime)
● Unlocks the job
● Reschedules (if not On demand)
Job Scheduling
SAP Identity Management uses scheduling rules for scheduling a job. You may define
scheduling rules for the following types of jobs:
Table 3: Job Types

Job Description
Frequency The job is executed every n seconds, mi-

nutes, hours.
Fixed times The job is executed at specific times every
day.
Provision Jobs are executed continuously. Each job is
rescheduled immediately after execution.
On demand The job is executed only when request-
ed. The job request may come from other
jobs, external events, or a user.
On specific weekdays Jobs are executed only on specific weekdays
as requested.
Job Status and the Job Log

Job status can have one of the following values:
● Disabled: The job is disabled and will not run again until enabled.
● Idle: The job is ready to be executed at the next scheduled time.
● Running: The job is running.
● Stopping: The job has been ordered to stop and is cleaning up.
● Error: The job has entered a permanent error state and must be “force” restarted.
● Timeout: The job has timed out waiting for execution. In this case, verify that the
dispatcher is running.
Job Log
There are several different types of logs, including the following:
● Job log
- Each job execution is stored in the database
- Accessible using the IdM Admin UI or the Developer Studio
- Written in XML format, which can be used for custom integration with other tools

- By default, the job log contains only 25 lines, but this can be increased with
configuration
● Trace file
- Overridden on each run
- Access by users with file system access
- Required for support
● Log level
- Controls the amount of information that is stored in the log and trace files
- Debug and information levels might decrease performance and should only be used for
debugging
● System log
- Stores all information from trace files without overwriting it (for all jobs – mixed content
sorted by timestamp)
● Execution log
- Stores only the state of the executed jobs, for example, OK or not OK
Job Design Rules

When you create your own jobs, observe the following basic design rules:
● A job may run on different machines, so a job must not depend on local files.
● A job should consist of as few passes as possible, unless dependencies exist between
passes, or the passes execute in a given sequence.
- Better for throughput
- Different jobs can run in parallel
● If a job or multiple jobs run on multiple dispatchers, you do not know which dispatcher will
process the job every time. On the other hand, running more than one dispatcher is also
seen as good practice for failover scenarios. In those cases, it is recommended to share
resources between systems where dispatchers run (for example, load files/logs, and so
on).
● All passes within a job always run on the same dispatcher.
● The recommendation is to have 1 dispatcher per runtime component (for example, running
on different systems).
● A high-availability environment ensures that a job may be executed on different machines
(for example, runtimes). If one machine fails, another machine takes over.
● A job is a single thread - until running, it cannot be started again.
● To make elements easier to find and to communicate across the project team, design a
naming convention for Identity Center elements, including the following:
- Repositories

Unit 3: Jobs
- Jobs
- Table names
- For example, you could use the following convention:
<yourcompany namespace><repositoryname><contents>
Naming Conventions
When naming components, use the following naming convention guidelines:
● Do not use special characters
● Temporary tables
sap%$rep.$NAME%<objectType>
● Delta keys
sapd%rep.$NAME%<objectType> where %$rep.$NAME% resolves the repository name
● objectType examples:
- User
- Role
- Profile
- Group
- Company
Delta Functionality
Delta Benefits
Enabling delta functionality has the following benefits:
● It reduces the load on the network and target systems because only changes are written.
● It can detect both new and obsolete entries.
Figure 27: Delta Workflow

Delta Workflow
Deltas are built using the following process:
● Marks all read entries as Not Processed.

● Before writing, generates a hash of what will be written.
● Compares the hash to the hash in the delta table.
● If the hash is missing or different, then the delta functionality:
- Writes the entry to the target
- Stores the hash in the delta table
● If the hash is the same, then it is marked as processed in the delta table.
● After the process is complete, any entry that is marked as Not Processed was not present
in the source and is a potential candidate to be removed from IdM.
Delta Functionality Guidelines

Use the following guidelines when using delta functionality:
● Do not use delta in from-passes.

- Delta is meant for less writing, not less reading.
- With from-passes, it is more difficult to identify deletions.
Note:
Be careful with deletions. If the source is empty due to a connection failure,
this could delete all entries.
● Use a unique delta identifier.

- If a repository is used, use %$rep.$NAME% as part of the identifier, for example:
tmpd_% $rep.$NAME%
● Do not enable delta until the job is working.
LESSON SUMMARY

Unit 3: Jobs

Unit 3
Lesson 2
Creating a Repository
LESSON OVERVIEW
In this lesson, you will learn how to create a repository.
LESSON OBJECTIVES
Repository Types
Repositories Overview
The following is a brief overview of repositories:
● Repository definitions
- There is one repository definition for each target system and application.
- A repository definition contains system-specific parameters required to connect
systems and databases, such as servers, ports, credentials, and so on. (For example,
ABAP, LDAP, SAP SuccessFactors, and so on.)
● Repository type
- Constants relevant for all repositories of a given type (for example, ABAP) are stored
within the repository type.
- The repository type stores common settings for roles and privileges, job references,
and other common parameters.
Repositories in IdM 8.0
Figure 28: Repositories in IdM 8.0

Unit 3: Jobs
Note the following when working with repositories in IdM 8.0:
● All constants are declared in the repository type.

● Common values are only stored in the type. These changes apply once for all repositories.
● Constants are easily modified or added.
Repository Constant Declaration

Consider the following when declaring repository constants for name, type, and category:
● A unique name is required within the repository type.

● Decide how to display the constant in the IdM Admin UI, for example, as a string,
checkbox, or password.
● Set up the repository category as follows:

- The repository constant must be present on the repository (for example, host name,
port). For example, the connection details for the particular repository.
- A repository type constant with an override may be present on the repository (for
example, assignment grouping, validation processes [Validate Add, Validate Remove,
and so on], No master process). If not, a default value is used.
- A repository type constant, which is never present on the repository (for example,
events [Create, Modify, Delete, Assign, and so on]) and should not be changed in QA
and production.
Repository Type
Figure 29: Repository Type
Note the following about repository types:
● Identified by a qualified name

- Moving the repository type to another package changes its QName
● Defines one type of repository, for example:
- Active Directory

Lesson: Creating a Repository
- SAP SuccessFactors
- AS ABAP Database
● Maintained in the IdM Admin UI
Event Processes [Create, Modify, Delete, and so on]

Note the following about event processes:
● Common for all repositories of the same type.

● Valid for all privileges from a specific repository.
● Defined on the repository type.
● Not editable or visible in the IdM UI.
● Can be overridden by an attribute within a privilege or a role, but this is not recommended.
Repository Type Creation

When to Create a Repository Type
Create a repository type in the following situations:
● Creating a new connector

- Define the constants to be set when connecting a repository of that type
● With SAP IdM 8.0, there is no need for a repository type for notifications, since connection
details are part of the package constants (notification package)
Repository Type Deletion
● Can be deleted from the IdM Developer Studio.

● A new version of a package is imported and the repository type is missing in the new
package.
● A package is deleted. This also deletes all contained repository types.
● The repository type is moved to another package, because its QName will change.
Orphaned Repositories
Deleting a repository type may result in orphaned repositories.
● Orphaned repositories characteristics:

- Can be edited in the Admin UI.
- Constant descriptions are missing because they are stored in the repository type.
- Jobs and tasks will not run (repository constants return an empty string).
● To resolve orphaned repositories, do one of the following:
- Restore a deleted package, which contained the deleted repository type.

Unit 3: Jobs
- Re-create the repository type manually in the same package, so that the QName is the
same as before.
- Change the repository type to a new one. All declarations missing from the new
repository type are removed.
Admin User Interface Repository-Related Operations
● The central UI for IdM repositories can be found under the “System configuration” tab of
the IdM Admin UI
● Apart from the usual Create and Delete operations, there are some additional interesting
features:
- Enable/Disable – A disabled repository is not deleted, and all its related contents are
still in SAP IdM. It is only marked as temporary unavailable. Provisioning for the
repository is stopped until it is enabled again.
- Import/Export – Repositories are not transported with the package transport. They can
be exported and imported separately through this user interface.
- Change Repository type – available only for disabled repositories. Allows the user to
change the repository type for a repository. Keep in mind that such change might lead
to some inconsistencies and should be used carefully.
● Below the selected repository, in a table, there are two additional tabs “Constants” and
“Jobs”. Within the constants tab you see all “Repository Constants” and “Repository Type
Constants with Override”, which are defined within the Repository Type.
● On the second tab “Jobs”, you can view and run all repository jobs, which are created for
the repository type of the repository you have selected.
LESSON SUMMARY

Unit 3
Lesson 3
Creating Repository Jobs
LESSON OVERVIEW
In this lesson, you will learn how to create repository jobs.
LESSON OBJECTIVES
SAP Delivered Repository Jobs

Purpose of Repository Jobs
The purpose of repository jobs includes the following:
● Run a job with a given repository. An instance exists for each repository.
● Provides the following:
- Initial load
- Reconciliation
- Reports
● Can provide a link from a package constant, which makes the repository job visible in the
Admin UI.
- Run jobs
- Inspect logs
Note:
Do not link the repository job if you want to keep it internal so that the IdM
Administrators cannot run it directly.
Repository Job Instances

Note the following about job instances:
● The same repository job is executed for various repositories of a given type.
- All instances share the same pass definitions independent of the concrete repository.
● The following settings can be defined per repository:

Unit 3: Jobs
- Dispatcher
- Scheduling rule
SAP Delivered Initial Load Job
● The purpose of the SAP initial load job includes the following:
- Starts the initial synchronization between the repository and IdM.
- Provides IdM with relevant information from the repository.
● The initial load job can load the following:
- Users
- Authorizations as privileges
- Groups
- Company addresses (from AS ABAP)
- Current user assignments
- Help values (from AS ABAP) for selected attributes, for example, salutation
SAP SuccessFactors Implementation Requirements

The SAP SuccessFactors implementation requires the following:
● Cloud tenant with enabled ODATA/SOAP APIs

● User with proper access and company ID
Handled Information
SAP SuccessFactors handles the following information:
● Users (read/write)
● Dynamic groups (read/write)
● Roles (read)
LESSON SUMMARY

Unit 3
Lesson 4
Implementing Scripts for Advanced Data
Conversion
LESSON OVERVIEW
In this lesson, you will learn how to implement scripts for advanced data conversion.
LESSON OBJECTIVES
Scripts
SAP Identity Management scripts primarily perform data manipulations. The following are
examples of data manipulation:
● Verify attributes
● Build attributes
● Retrieve values
● Modify values
● Convert data (advanced)
Using Scripts
Note the following when using scripts:
● Scripts are defined in the job definition or within the action tasks.
● Package scripts can be defined so that you can reuse the same script in many jobs or
action tasks.
- An explicit reference to a package script is declared in the job or action task.
● Scripts can be declared public and therefore be reused in jobs and action tasks from other
packages.
Scripts and Functions

Note the following about scripts and functions:
● Based on JavaScript.
- Basic JavaScript syntax error checks are performed on save.
● Can call IdM Script functions, like uEncrypt.

Unit 3: Jobs
● Can reference constants.

● Can reference other scripts.
LESSON SUMMARY

Unit 3
Learning Assessment
1. What is the difference between a From-pass and a To-pass?

X A From-passes read and write data to repositories and to-passes read and write data
to databases.
X B To-passes read from identity stores and write to repositories, from-passes read
data from repositories and write to databases.
X C From-passes read from identity stores and write to repositories, to-passes read
X D To-passes read and write data to repositories and from-passes read and write data
to databases.
2. What happens when you activate the delta functionality of a certain pass?
X A Only changes are read from the source.
X B A hash is generated from the values and target is updated only if the hash differs.
X C The delta is stored into an hcm.txt file.
X D The delta is visible in IDM Web UI.
3. What type of jobs can work with repositories?

X A Standard jobs
X B Action jobs
X C Repository jobs
X D Housekeeping jobs

Unit 3
1. What is the difference between a From-pass and a To-pass?

X A From-passes read and write data to repositories and to-passes read and write data
to databases.
X B To-passes read from identity stores and write to repositories, from-passes read
X C From-passes read from identity stores and write to repositories, to-passes read
X D To-passes read and write data to repositories and from-passes read and write data
to databases.
2. What happens when you activate the delta functionality of a certain pass?
X A Only changes are read from the source.
X B A hash is generated from the values and target is updated only if the hash differs.
X C The delta is stored into an hcm.txt file.
X D The delta is visible in IDM Web UI.
3. What type of jobs can work with repositories?

X A Standard jobs
X B Action jobs
X C Repository jobs
X D Housekeeping jobs

UNIT 4 SAP IdM Connections to Other
Systems
Lesson 1
Connecting to SAP S/4HANA On-Premise 75
Lesson 2
Connecting to AS JAVA 77
Lesson 3
Connecting to Active Directory With LDAP 79
UNIT OBJECTIVES
● Connect to an SAP S/4 HANA on-premise system

● Connect to an SAP AS JAVA system
● Connect to an active directory system

Unit 4: SAP IdM Connections to Other Systems

Unit 4
Lesson 1
Connecting to SAP S/4HANA On-Premise
LESSON OBJECTIVES
SAP S/4 HANA as a Target System

ABAP Connectors
There are three packages, which could be used to connect to an ABAP based system. The
first, which is known as the ABAP connector is targeted for user maintenance, which reflects
the transaction SU01 in the ABAP system. The second is the Business Suite connector, which
also supports the SU01 operations, but additionally it handles also business partners from the
various modules of the Business Suite system. The last one is the dual stack connector, which
replicates mostly the ABAP connector, but adds also additional functionality to handle the
second stack of the system – Java. As of the time when the course was created, there was no
standard connector for S/4 HANA you will use the standard ABAP connector for the purpose.
● ABAP Connector
- For managing ABAP user accounts and their assignments to roles and profiles (SU01)
- Supports both Load Balanced Connection and Specific Application Server connection
- Contains a job to read help value information, for example, salutation)
- Contains a job to provision company addresses from IdM to ABAP repositories
● Business Suite Connector
- For managing ABAP user accounts and their assignments to roles and profiles (SU01)
- For managing Business Partners in SAP Business Suite components
- Depends on the standard ABAP Connector
- Contains a job to provision company addresses from IdM to ABAP repositories
● Dual Stack Connector
- For managing both ABAP and Java stack in one repository
- Supports both Load Balanced Connection and Specific Application Server connection
- Depends on the standard ABAP Connector
- The connector can be used for scenarios, where the Java system user management is
connected to ABAP AS server and thus all users and assignments done in ABAP are
also visible in the Java stack

Connectivity Specifics
Communication from SAP IdM to the ABAP target system is based on RFC (using SAP JCo)
● Communication for the Business Suite integration from ABAP to IDM is based on SPML. In
this scenario, Virtual Directory Server (VDS) is deployed on NetWeaver
● Secure communication is achieved using SNC and may be required in some cases (e.g.
setting a productive password in the target ABAP system)
● Connection parameters like hostname, client number, r3name, instance number, user and
password are the minimum requirements for successfully established connection
● For the ABAP connector, the technical user used for the communication should have as a
minimum the SAP_BC_SEC_IDM_COMMUNICATION role.
● If the Business Suite connector is used, then the technical user requires one additional role
– SAP_CA_BP_IDM_INTEGRATION.
● Support AS ABAP systems with release 4.6 or higher
LESSON SUMMARY

Unit 4
Lesson 2
Connecting to AS JAVA
LESSON OBJECTIVES
SAP AS JAVA as a Target System

Java Connectors
There is one package with two different repository types. The first – ASJavaDB should be
used when we have a standalone AS JAVA server, which user management is self-contained.
The standard engine for an AS Java server is called UME (User Management Engine). The
UME is very flexible and thus allows that the AS Java server connects to other identity
providers like LDAP, ABAP, etc. to handle user creation, role assignments, etc. For that
purpose, is the second repository type – if the UME is connected to an LDAP server, then use
the ASJavaLDAP repository type.
● For managing Java user accounts and their assignments to roles and groups (UME)
● Supports both standalone and connected UME (LDAP)
● For ABAP connected UME, use the dual stack package explained in the previous unit
● Often the first repository to be connected in order to provision proper privileges to users,
who need access to SAP IdM
Communication from SAP IdM to the Java target system is based on SPML.
● Secure communication is achieved with exchange of certificates between the SAP IdM
runtime and the AS Java server. Respectively, the https parameters need to be maintained
in the repository (e.g. HTTP_PROTOCOL = https).
● Connection parameters are very simplified and require only hostname, port, user and
password.
● For the Java connector, ensure the technical user in the communication has a proper
authorizations, which are granted with the ‘Spml_Write_Action’ UME action. For read-only
access, use ‘Spml_Read_Action’ UME Action.
● Supports AS JAVA systems with release 7.0 or higher.
LESSON SUMMARY


Unit 4
Lesson 3
Connecting to Active Directory With LDAP
LESSON OBJECTIVES
Active Directory as a Target System

AD Connectors
SAP IdM offers one standard package for connecting to Active Directory. It contains only one
repository type. This type of system is often used in mixed mode – both as source for certain
attributes and as target (e.g. for group assignment). This is because, it is widely used as
identity provider for multiple other applications and thus can be seen as a simplification to the
authorization landscape.
● Used for managing Active directory user accounts and their group assignments
● Provides templates for Sun One LDAP and Microsoft Active Directory Server (ADS). Those
may be adapted to fit to the project needs
● Can be used for creation of mail accounts for users with Microsoft Exchange 2007 or 2010
Communication from SAP IdM to the Active Directory target system is based on LDAP
● Secure communication is achieved using the LDAPS protocol. (requires maintenance of
LDAP_PORT_SSL repository constant and certificate trust between IdM runtime and LDAP
server)
● The minimum set of connection parameters consist of hostname, port, user starting point
and filter and groups starting point and filter, as well as technical user and password to
establish the connection.
● For the AD connector, the technical user used for the communication should have proper
authorizations to read/write both users and groups in the respective locations within AD.
● Supports AD versions 2000, 2003, 2008, 2012, and 2012 R2.
LESSON SUMMARY


Unit 4
Learning Assessment
1. How many different IdM packages can be used to connect to an ABAP backend system?
X A 1
X B 2
X C 3
X D 4
2. Which repository types are supported with the Java IdM package of SAP IdM?
X A ASJavaDB, ASJavaPortal
X B ASJavaPortal, ASJavaLDAP
X C ASJavaDB, ASJavaABAP
X D ASJavaDB, ASJavaLDAP
3. What can be done additionally with an Active Directory repository connected to SAP IdM,
apart from provisioning users and groups?
X A You can create mail accounts using Exchange.
X B You can change passwords for a user in Active Directory.
X C You can grant users access to 3rd party applications, which are connected to
Active Directory.
X D You can print any document stored in SAP IdM.

4. What additional benefit does the Business Suite connector offers compared to the
standard ABAP connector?
X A It can maintain users in SU01.
X B It can read value help values from the backend system.
X C It allows maintenance of business partners in various components of the Business

Suite.
X D It can create company addresses from SAP IdM to the connected backend system.

Unit 4
1. How many different IdM packages can be used to connect to an ABAP backend system?
X A 1
X B 2
X C 3
X D 4
2. Which repository types are supported with the Java IdM package of SAP IdM?
X A ASJavaDB, ASJavaPortal
X B ASJavaPortal, ASJavaLDAP
X C ASJavaDB, ASJavaABAP
X D ASJavaDB, ASJavaLDAP
3. What can be done additionally with an Active Directory repository connected to SAP IdM,
apart from provisioning users and groups?
X A You can create mail accounts using Exchange.
X B You can change passwords for a user in Active Directory.
X C You can grant users access to 3rd party applications, which are connected to
Active Directory.
X D You can print any document stored in SAP IdM.

4. What additional benefit does the Business Suite connector offers compared to the
standard ABAP connector?
X A It can maintain users in SU01.
X B It can read value help values from the backend system.
X C It allows maintenance of business partners in various components of the Business

Suite.
X D It can create company addresses from SAP IdM to the connected backend system.

UNIT 5 Privileges, Business Roles, and
Dynamic Groups
Lesson 1
Assigning Privileges 87
Lesson 2
Describing the SAP Provisioning Framework 97
Lesson 3
Creating Business Roles 103
Lesson 4
Defining Automatic Role Assignments 105
UNIT OBJECTIVES
● Assign privileges
● Understand how provisioning works in SAP IdM
● Create business roles
● Define automatic role assignment using dynamic groups

Unit 5: Privileges, Business Roles, and Dynamic Groups

Unit 5
Lesson 1
Assigning Privileges
LESSON OVERVIEW
In this lesson, you will learn how to assign privileges.
LESSON OBJECTIVES
Privileges
Privileges are used to manage provisioning based on assignments of authorizations in
external systems. These can be user accounts, e-mail accounts or access control systems.
The fact that a user is given a privilege does not in itself mean that the actual account is
created, only that the process has been initiated. Assigning and removing privileges can
automatically start tasks to perform provisioning and de-provisioning.
Privileges represent the smallest authorization entity in SAP IdM. They can be mapped to
various objects in the respective backend systems depending on the connector used. Here
are some examples:
● ABAP technical roles (composite or simple)

● ABAP profiles
● UME roles
● UME groups
● UME portal roles
● LDAP groups
Privileges and Authorizations

No matter which of the above objects is mapped to the privilege, the mapped object's
underlying complexity is invisible to SAP IdM. For example, if we map a composite ABAP role
to a privilege in IdM, nothing is visible to the privilege about the roles, which build up this
composite role,, the authorization objects assigned to any of the roles part of the composite
role, nor of the role itself. It is the same for UME roles that have underlying actions in the SAP
Java AS server. Those are invisible to SAP IdM after the UME role is mapped as a privilege.
This abstraction is deliberate. It simplifies the handling of authorizations in SAP IdM
independent of their source system.
Privileges are also used for authorizations in the IdM solution to grant access to the UIs and
functionalities within it. Here are some examples:

● MX_PRIV:WD:TAB_TODO: Enables the To-Do tab in the standard IdM UI, which is used for
approvals
● MX_PRIV:WD:TAB_MANAGE: Enables the Manage tab in the standard IdM UI, which is
used to execute tasks on other users (not self-service)
● MX_PRIV:APPROVALS:READONLY: Provides read-only access to the Approval
Management tab. This tab provides an administrator an overview over all approvals in the
system.
Note:
Privileges are not used for access to the Developer Studio.
Assignments
Figure 30: Assignments
Assignments in SAP Identity Management link a person to an authorization (privilege or role).

An authorization can be assigned to none, one, or multiple persons.
Every assignment has properties that specify it, for example, reporting, statistics, and
auditing. Properties also answer questions including the following:
● How was the authorization assigned? (Direct, indirect, or automatic)
● Who assigned the authorization? (Process or person)
● When was the authorization assigned? (Date or time)
● Why was the authorization assigned? (Reason)
● Has the assignment been approved? (Approval process)
Assignment Attributes
Privileges can be assigned to a user in two ways:
● Directly: Adding the privilege to the user. Assigning direct privileges is done by adding the
user entry as a member of the privilege entry.

Lesson: Assigning Privileges
● Indirectly: Through a business role. When assigning a business role to the user, all
privileges associated with the business role (and all sub-business roles) are added to the
user.
Figure 31: Privilege Types
Privilege Types
There are two general types of privilege:
● Master privilege: Any privilege on which other privileges depend, for example, an account
privilege.
● Sub-privilege: Any privilege that depends on another privilege.
● The following specifics apply to privileges in the SAP IdM identity store.
- PRIV:<repository>:ONLY (Account privilege of type master)
■ The initial load of the <repository> creates it.
■ If assigned to a user, starts the process for creating an account in the <repository>.
■ If assigned to a company address, indicates that a change in the company address is
provisioned to the respective <repository>.
■ Contains the attribute MX_IS_ACCOUNT with value 1. The privilege is not
provisioned to the backend system.
■ Removing this privilege from a user deletes the user account from the <repository>.
■ Removing this privilege from a company address, deletes the company address in
the respective <repository>.
Note:
The account privilege cannot be assigned with context to a user.
- PRIV:SYSTEM:<repository>

■ The initial load of the <repository> creates it.

■ An internal privilege mainly for master data modifications (set attribute triggers for
automatic modification of master data)
■ Never assign or remove this privilege. It is handled automatically, for example,
assigned after the account privilege is assigned and respective removed, when the
account privilege is removed.
■ By default, it is invisible in IdM UI.
■ Contains the attribute MX_IS_ACCOUNT with value 1. The privilege is not
provisioned to the backend system.
- PRIV:ROLE:<repository>:<authorization name>
■ May also be named PRIV:PROFILE or PRIV:<something else>, where the type could
be derived from the type of authorization in the backend.
■ Gives one authorization.
■ Remains in Pending status until the PRIV:<repository>:ONLY is successfully
assigned.
■ Has a master privilege that makes the connection to the repository from which it
originates.
■ Can have a No Master task assigned. Do this if you want the roles of the respective
repository to be provisioned automatically on being assigned (for example, without
explicitly assigning the ONLY privilege).
- Attribute ACCOUNT<Repository>
■ Created by the initial load of the <repository> in the IdM Schema.
■ Attached to the user, for which the ONLY privilege is being assigned, indicating the
user account (unique identifier) for the repository.
Event Task Assignments

Each privilege can react on certain events:
● Validate event processes (Approval, Other validations)

- Used to validate and request approval for an operation
- There are three validate processes: Validate add, validate remove, and validate modify
validity
● Member processes (Provision, De-provision, Modify validity)
- Executed on one of the following process placeholders: Add member, Delete member,
and modify validity
● Notify event process
- Notifies that an assignment is about to expire (notify link expiry)
● Do not maintain these directly in the privilege. It is good practice to have them inherited
from the repository type to which they belong.

● Processes can define when to be executed: Immediately, when valid, never, N days before
valid to (only for link expiry).
Figure 32: Assignment Attributes
Assignment Attributes
Note the following about assignment attributes:
● On the user (MX_PERSON), an attribute MXREF_<entry type> shows what assignments a

user has, for example MXREF_MX_ROLE, MXREF_MX_PRIVILEGE:
● In the IdM UI, for simplification, you can use the MX_ASSIGNMENT attribute. It allows
assignment of both privileges and roles in one.
● On a role or group level, the MXMEMBER_<entry type> attribute shows who is assigned to
the role or group, for example MXMEMBER_MX_PERSON, MXMEMBER_MX_PRIVILEGE.
Assignment Properties on Attribute Level

Assignment properties can be split into two: properties that can be edited only on identity
schema level and properties that can be overwritten for every form.
Properties available only on identity schema level are:
● Show search field: if you allow searching for assignment in the UI

● List entries on load: If the entries of the reference assignment are loaded automatically or
only after performing a search operation (useful, when there are a lot of assignments per
user)
● Number of Lines: the number of visible lines for the table in which the entries are
visualized.
Assignment properties that can be changed on the form level include the following:
● Status filter

- Defines which assignments to show by default (others can be shown in an advanced

search)
- Options include All, assigned (default), not assigned (waiting for ValidFrom, waiting for
an approval, waiting for processing, declined, and failed)
● Default Search Filter: If there should be a pre-defined filter in the search, which is applied
by default.
● Read-only search filter: A filter for searching the assignment, which cannot be changed
● Include Direct Assignments only: Show only assignments, which are directly assigned to
the object you are viewing
Extended Assignment Properties on the Relation Between Entry Type and Attribute
The following properties are additionally available to configure the assigments:
● Decide if the IdM UI asks for a reason during the assignment with the following options:
- No: Do not ask.
- Optional: A reason can be entered, but is not required.
- Mandatory: A reason is required.
● Decide if Valid From and Valid To is visible in the UI.
● Decide if assignment status is displayed or not.
Programmatic Assignments
Programmatic adding of privileges are as follows:
● The MXREF_MX_PRIVILEGE value can be assigned with MSKEY or MSKEYVALUE using the
following notation:
- MSKEY
- <MSKEYVALUE>
● Multiple values are separated by a pipe: |
Assignments Validity
● When making an assignment, you can define the following:

- ValidFrom
- ValidTo
● ValidFrom and ValidTo determine when the assignment is added and removed and when
event tasks are executed.
Uses Cases
Here are some examples of addition and removal of assignments and when event tasks are
executed.

Figure 33: Use Case: Assignment Without Validity
A user requests an assignment without maintaining validity. This immediately triggers the
Validate Add event. If this is approved, it is followed by the Add member event. After those
two events, the privilege is assigned. Because no Valid To is defined, a user starts a manual
delete operation. This operation is followed again by a Validate Remove process and, if it is
approved, but a Delete member process.
Figure 34: Use Case: Assignment With Validity
This is the same scenario as the previous one. However, the requestor provides validity. There
is no difference for Validate Add but, when approved, the Add member has an execution
condition set to “When Valid”. This delays the provisioning until the privilege's valid from date
is reached. 14 days before its Valid To date, a notification is sent and, if no action is taken,
after the expiration the del member event is called.

Figure 35: Use Case: Assignment with Validity to a Validity-Aware System
If the target system is validity aware, the add task can immediately provision the assignment
to the target system, including ValidFrom and ValidTo (for example, ABAP systems).
Figure 36: Use Case: Auto Reassignment
Where validity of a certain assignment must be automatically extended, the above setup can
do this extension. 14 days before the Valid To date, a notify validity process starts that
extends the privilege validity for a certain period. On the other hand, this triggers a Validate
modify event. If approved, it triggers a Modify validity member process, which extends the
privilege in IdM and the backend system.

Assignments Visibility
● When searching for entries to assign the privilege, only entries accessible to the user are
visible in the search result.
● When managing the privilege, only group members accessible to the user are visible.
● When assigning a privilege to an entry, only privileges accessible to the user are visible.
The following entry visibility options are available:
- All: The privilege is visible to all users. This is the default value.
- Owner and members: The privilege is visible to the owner and entries assigned to the
privilege.
- Owner only: The privilege is only visible to the entries defined as owners.
LESSON SUMMARY


Unit 5
Lesson 2
Describing the SAP Provisioning Framework
LESSON OVERVIEW
In this lesson, you will learn how to describe the SAP provisioning framework.
LESSON OBJECTIVES
Provisioning Framework
Figure 37: Provisioning Framework
Figure 38: Package Dependencies
The provisioning framework for SAP Identity Management (IdM) 8.0 provides the templates
used to connect SAP systems to SAP IdM and to set up jobs and processes for provisioning
corresponding users and assignments.

Artifact Distribution
The engine itself is in a read-only package. In SAP IdM 8.0, provisioning needs artifacts that
are distributed in several packages:
● Engine package: The engine package contains the core provisioning flow responsible for
triggering the necessary processes (Provision, Deprovision and Modify) as well as
common scripts used by all packages.
● Connector packages: The package for each connector contains the specific processes for
provisioning to a specific system (for example ABAP).
● Forms package: The forms package contains the definition of all User Interface tasks for
CRUD operations (create, read, update, delete) on different entry types.
● Notification package: The notification package contains the notification task and the
notification templates used to send notifications from the SAP Provisioning framework,
approval and attestation tasks.
● Custom package: The custom package allows customizations of the provisioning
framework without changing other packages. It contains customizations and extensions
made by the customers, default constants as well as custom scripts that could be changed
later.
Note:
To perform successful provisioning, you need to import the engine SAP package,
the custom SAP package, and at least one connector package.
Execution Path
Figure 39: Request Account Privilege for Repository MyASJava

Lesson: Describing the SAP Provisioning Framework
Figure 40: Privilege to Repository Reference
Figure 41: Connection to Repository Type
Check during workflow approval and then revert to this statement. The member event
process is called directly because validate add is not set for the scenario.

Figure 42: Validate Add Not Set
You must determine the correct connector package and process to be called.
Figure 43: Determining the Correct Connector Package and Process (1)
Based on the performed operation, the process name is pre-defined.

Lesson: Describing the SAP Provisioning Framework
Figure 44: Pre-Defined Process Name
Predefined processes must be public. They have a strict naming convention. Depending on
the type of connector, the processes can include the following:
● CreateUser
● ModifyUser
● DeleteUser
● AssignUserMembership
● RevokeUserMembership
● EnableUser
● DisableUser
● SetUserPassword
● CreateGroup
● DeleteGroup
● CreateCompanyAddress
● ModifyCompanyAddress
● DeleteCompanyAddress
Provisioning Framework Customization

When customizing the provisioning framework, note the following:
● Basic: Does not require checking out the package (repository constants, package
constants)
● Custom Package
- Can be changed by the customer

- Contains some custom scripts

● Connectors
- May need to change to add new attributes
- Breaks the upgrade from SAP
● Engine
- Cannot be changed. Any changes require changing all of the references all existing
packages.
Note:
An SAP package that has been modified by a customer requires manual
work to upgrade to a newer version from SAP.
Copying or Importing SAP Packages Under New Names
● Connector packages can be imported under a new name with the following conditions:
- Can be used to create a new connector.
- The new package has a newly assigned qualified name, which is used to identify all
public objects it contains.
- The package still references the original engine package.
- There are no references to any other connector package.
● Engine packages cannot be copied or renamed. All connector packages reference them
(both standard SAP and those renamed or copied).
LESSON SUMMARY

Unit 5
Lesson 3
Creating Business Roles
LESSON OVERVIEW
In this lesson, you will learn how to create business roles.
LESSON OBJECTIVES
Business Roles
IdM Business Roles
● Note the following about IdM business roles:

- It is good practice to include an abstract description of the role in the description field.
- Usually, it contains some company-specific semantics based on specific key attributes.
- It can be organized in a hierarchy with inheritance.
● Leaf nodes are usually privileges but can also be business roles, for example, in a
hierarchy.
● Assigning a role to a user also assigns all child roles and privileges.
Figure 45: Role Hierarchy

Member Events on Roles
Figure 46: Role Inheritance
Business roles share the same member event processes as privileges. They trigger based on
the defined hierarchy. If we take the example from the figure, Role Inheritance, then, if the
ROLE:MANAGER is assigned to a person, the events of all marked business roles and
privileges trigger. The only direct assignment is the business role MANAGER, while others are
inherited.
Visibility and validity are other properties of the business role. They have more in common
with each other in how they are handled than with privileges. However, there is one property
that is exclusively available only for business roles. This property is restrictions.
Business Role Restrictions

Note the following about business role restrictions:
● Allows or disallows the assignment of the business role to a particular set of entries, for
example, person or role
● Can define the exclusion of a possible co-existence of two or more business roles. These
are assigned to one and the same entry. The business roles part of this list cannot co-exist
attached to the same entry.
LESSON SUMMARY

Unit 5
Lesson 4
Defining Automatic Role Assignments
LESSON OVERVIEW
In this lesson, you will learn how to define automatic role assignments.
LESSON OBJECTIVES
Dynamic Groups
Purpose of Dynamic Groups
The purpose of dynamic groups includes the following:
● Dynamically define members based on the attributes of an entry.

This can be done using:
- A simple definition filter: this includes an attribute name and value. It can also be a
negative filter.
- An advanced SQL statement
Dynamic Group Recalculation

Dynamic Group Calculation
● Dynamic groups need to be calculated first before they can be used

- Members of the group are added/deleted when the group is resolved
- Changing the filter of a dynamic group does not automatically re-resolve it
- To trigger resolve of a dynamic group, run a job using the following script function
“uIS_ResolveDynamicGroup”
● Retrieving calculated members
- Use the MXREF_MX_DYNAMIC_GROUP attribute
How to Achieve Automatic Assignment with Business Roles and Dynamic Groups
You can use automatic assignments in the following scenarios:
● Business roles can have dynamic group assigned

- When a dynamic group is resolved, all members of the group automatically receive the
business role to which the dynamic group is assigned
- Business roles assigned in this way are appearing as indirect assignments to the
person, since they are assigned through the dynamic group
● If you want to programmatically assign dynamic groups to business roles:
- Use the attribute MX_ROLE_AUTOASSIGN_TO, which is part of the MX_ROLE entry
type
LESSON SUMMARY

Unit 5
Learning Assessment
1. Which of the following options is NOT a valid way to assign a privilege to a person?
Assume that the person already has an account in the system from which the privilege
originates.
X A Assign a business role which contains the privilege in question.
X B Assign a dynamic group to a business role which contains the privilege.
X C Assign the privilege directly to the person.
X D Create a job with a To Identity Store pass, which has the following destination tab
setup (Entry type → MX_PERSON):Attribute 1 (MSKEYVALUE) with a value of
<MSKEYVALUE of PERSON>.Attribute 2 (MXREF_MX_PRIVILEGE) with a value of
<MSKEYVALUE of privilege>.
2. When creating a new dynamic group, which attributes/values do you add to the filter in
order to select all of the people which belong to department “Development”?
X A MX_ENTRYTYPE = MX_PERSON
X B MX_ENTRYTYPE = MX_ROLE
X C MX_DEPARTMENT = Development
X D MX_DEPARTMENT = Admin
3. Which part of the provisioning framework performs operations in the target system?
X A The forms, which are used to change the information in the UI
X B The member event tasks
X C The relevant connector, depending on the target system
X D The repository events

4. Which of the below privileges from target system SYS100 has an attribute
MX_IS_ACCOUNT set to 1 by default? Assume that we are using the standard initial load
for the system, which is type ABAP Single Application Server.
X A PRIV:SYS100:ONLY
X B PRIV:ROLE:SYS100:ONLY
X C PRIV:SYSTEM:SYS100
X D ROLE:SYS100:ONLY

Unit 5
1. Which of the following options is NOT a valid way to assign a privilege to a person?
Assume that the person already has an account in the system from which the privilege
originates.
X A Assign a business role which contains the privilege in question.
X B Assign a dynamic group to a business role which contains the privilege.
X C Assign the privilege directly to the person.
X D Create a job with a To Identity Store pass, which has the following destination tab
setup (Entry type → MX_PERSON):Attribute 1 (MSKEYVALUE) with a value of
<MSKEYVALUE of PERSON>.Attribute 2 (MXREF_MX_PRIVILEGE) with a value of
<MSKEYVALUE of privilege>.
2. When creating a new dynamic group, which attributes/values do you add to the filter in
order to select all of the people which belong to department “Development”?
X A MX_ENTRYTYPE = MX_PERSON
X B MX_ENTRYTYPE = MX_ROLE
X C MX_DEPARTMENT = Development
X D MX_DEPARTMENT = Admin
3. Which part of the provisioning framework performs operations in the target system?
X A The forms, which are used to change the information in the UI
X B The member event tasks
X C The relevant connector, depending on the target system
X D The repository events

4. Which of the below privileges from target system SYS100 has an attribute
MX_IS_ACCOUNT set to 1 by default? Assume that we are using the standard initial load
for the system, which is type ABAP Single Application Server.
X A PRIV:SYS100:ONLY
X B PRIV:ROLE:SYS100:ONLY
X C PRIV:SYSTEM:SYS100
X D ROLE:SYS100:ONLY

UNIT 6 SAP IdM Processes and
Workflows
Lesson 1
Creating Processes 113
Lesson 2
Configuring Approval Workflows 119
Lesson 3
Sending Notifications 123
Lesson 4
Storing Information with Pending Value Objects (PVOs) and Context Variables 125
Lesson 5
Implementing Automatic Approve/Decline 129
UNIT OBJECTIVES
● Create your own workflows

● Configure approval workflows
● Send notifications
● Store information with pending value objects (PVOs) and context variables
● Implement automated approve/decline

Unit 6: SAP IdM Processes and Workflows

Unit 6
Lesson 1
Creating Processes
LESSON OBJECTIVES
Processes and Tasks

Processes
A process defines the flow of operations executed on entries stored in the identity store and is
characterized as follows:
● It is built from a sequence of tasks/other processes, which are added to a process flow
diagram.
● If one of the tasks fail, none of the subsequent tasks are executed.
● The workflow can be controlled using special type of tasks (for example, Wait, Switch,
Conditional, and so on).
● Task processing within one process instance is always sequential.
● Parallel processing can be achieved using event tasks.
● A process can be public, meaning that it can be referenced and called from other
packages. If that is the case, its name must comply with the qualified name requirements
(for example, there must be no empty spaces or special characters in the name, apart
from an underscore).
● A process may have a type, for example, Validate Add.
- The type is used when adding process references to identify to filter the relevant
processes.
- The default value of the process type is Regular. Regular processes can be attached
generally on any type of event process reference.
● The tasks of a process are not visible within the Identity Management tree. They can only
be accessed through the workflow editor of the process to which they are added.
● A process may be called as an event process.
- For example, Entry type, attribute, OnOK, and so on.
Tasks
Note the following points about tasks:

● They are always part of a process

● They cannot be shared/reused with other processes
● They cannot be called from outside of the process to which they are added
● They cannot be attached to an event
Task Types
Irrelevant of its type, a task always operates on entries in the identity store (such as entry
types, attributes, and assignments).
The following task types are available:
● Action task
The action task contains a reference to a job that is run after the task is executed.
● Conditional task
The conditional task executes a certain process flow branch based on the result of a
specific condition. The condition may, for example, check the presence of an attribute in
the identity store. The condition must always evaluate to TRUE or FALSE and each result is
bound to one conditional task output branch.
● Switch task
The switch task, similarly to the conditional task, executes a certain process flow branch
based on the result of a condition. The switch task, however, may evaluate to more than
two conditions (for example, true/false). It can have a number of exit case branches that
should correspond to the possible values of the returned result. For fallback scenarios, you
must have an “Else” branch which is executed if none of the other branches match the
result.
● Wait task
The wait task influences the task execution flow. It is a kind of synchronization task, which
waits on previous tasks to complete before continuing with the rest of the process flow.
● Approval task
Approval tasks will be explained in detail in a later lesson. For now, it is enough to know
that those tasks are included in the process when a certain request requires approval (for
example, Assignments approval).
● Attestation task
Those tasks are used to perform periodic attestations of roles/privilege assignments.
Action Tasks
Action tasks have the following properties:
● It contains a job with the following limitations:

- No source definition for the pass; this is always the entry being processed
- Only one To-Pass is allowed
● The job operates on a single given entry in the Identity Store
- Optimized by the runtime if multiple entries are to be processed

Lesson: Creating Processes
● Other properties include the following:

- Parallel provisioning (meaningful when many entries are processed to several
repositories of the same type – connected with dispatcher max concurrent RT engines
configuration)
- Number of retries in case of error (how many times should this action task retry before
finally failing the process execution)
- Retry delay (what is the delay between separate retries)
Conditional Tasks
Conditional tasks have the following properties:
● The task executes either a ‘true’ branch flow or a ‘false’ branch flow
● A condition defines which flow to execute
- LDAP-like filter
■ Includes possibility to include inactive entries
■ You can use attribute IDs instead of attribute names for faster comparison, but not
so generic as attribute name
■ Can define the Return attribute, for example, MSKEYVALUE
- SQL statement
- Database stored procedure
● The SQL statement must return one of the following:
- 0 or empty string: Execute the FALSE branch
- Anything else: Execute the TRUE branch
Switch Tasks
Switch tasks include the following properties:
● A decision point which evaluates a condition and executes one of the matching exit
branches.
● The condition is defined the same as with conditional tasks.
LDAP Filtering
The filter is a string representation of LDAP search filters based on RFC2254:
● Similar to LDAP filters for defining selections

- (MX_ADDRESS_CITY=TRONDHEIM)
- (&(MX_ADDRESS_CITY=TRONDHEIM)(!(MX_TITLE=MANAGER)))
● At runtime, it is automatically converted to an SQL query
- Runtime execution is based on SQL

- If you edit the generated SQL, it is not possible to go back to the LDAP filter (for
example, a reverse conversion)
Specifics when using SQL Query

There following variables in the SQL query can be used:
● %MSKEY% – MSKEY of the entry being processed

● %REPID% – Repository ID of the repository to which the entry belongs
● %TASKID% – ID of the task being executed
● %AUDITID% – Audit ID of the task being executed
● %NOLOCK% – Expands to “with (nolock)” if running on MS SQL server
- If SQL queries are used, those should be designed to run on all supported databases:
ASE/SQL/DB2/ORA
Wait Tasks
● Used as synchronization point for the process:

- As long as there are tasks in the system where the ref audit ID is the same as the
running process audit ID, the process is not going to continue.
● A running task within a process may also start a parallel process using one of the following
options:
- By executing one of the result handling events of the task (onOK, OnFail, onInitialize)
- By changing attributes or entries that have event tasks (add, modify, or delete)
- By adding or removing a role or privilege with a member event task (for example, Add,
Remove, Validate, and so on)
- By modifying an attribute that has been added as a trigger for a SYSTEM privilege
● The new parallel process receives a new audit record and a new audit ID
- The ref audit ID references the parent process audit ID
- In this case, the wait task in the parent will wait for the first-level children and continue
only after all of them are completed
- However, if the children start other processes on their own, then those are not handled
by the wait task in the parent. If needed, they can be handled with a wait task in the first
level child.
Task Execution and Monitoring
● Provisioning audits
- Keep track of what a process or task has triggered and the result of that task
- Can be viewed within the Monitoring tab of the IdM Admin UI
● Provisioning queue

Lesson: Creating Processes
- Keeps track of pending tasks

- Large queue usually means slower performance
- Some tasks may remain pending for various reasons, including waiting for approval,
time-outs, incorrect configurations
- Can be viewed within the Monitoring tab of the IdM Admin UI
LESSON SUMMARY


Unit 6
Lesson 2
Configuring Approval Workflows
LESSON OVERVIEW
In this lesson, you will learn how to configure approval workflows.
LESSON OBJECTIVES
Approvals
Approval Definition
An approval definition includes the following:
● Approval workflow
- Attached to a role or privilege as a Validate Add process
- Can contain multiple approval tasks — each task is a separate level of approval
● Approvers and escalation approvers can be defined on:
- Role or privilege
- Assignment Context – in case of context-based assignments
- Approval task
- Pending value object – when event is started, the approvers are copied to the PVO from
the role/privilege. The difference here is that you can modify the approvers manually
before entering the approver task
● Approvals are sequential
- Each approval can be configured independent of the others
- Example: first approval by line manager, second approval by role owner
Approval Tasks
The approval task has the following three sub-branches:
● Approve – if the task is approved, all tasks under this branch are executed
● Decline – if the task is declined, then all tasks under this branch are executed
● Timeout – if neither of the above takes place for a certain period of time, then the timeout
branch is triggered

● The approval task can be configured for both assignment and basic approval.
- For assignment approval, the approver confirms if a certain role or privilege should be
attached to a person. The object which is being approved is a pending value and waits
for the process to complete with a proper decision.
- For the basic approval, which approves certain master data objects, there is no pending
object. This means that the values which are being approved are already set and it is
only a matter of the approver’s decision which influences the branch to be executed in
the approval workflow.
- The approvers for the type basic are always defined on the approval task itself.
Note:
The basic approval can be configured using the Attributes tab of the
approval task, which is enabled only if the Show Attributes checkbox is
selected in the task.
Approval Management
Central Approval Management
Use central approval management to centrally monitor and act on pending approvals. Central
approval management is available to administrators in IDM Admin UI and managers in the
IDM Standard UI with the following roles:
● Administrator: If users have any of the following privileges, they can see all approvals in the
system:
- MX_PRIV:APPROVALS:READONLY – only read access, no approval
- MX_PRIV:APPROVALS:PROCESS
● Manager: Users are allowed to see the approvals for all approvers as MX_MANAGER
- MX_PRIV:MANAGED_APPROVALS:READONLY – only read access, no approval
- MX_PRIV:MANAGED_APPROVALS:PROCESS — this role is also allowed to decline and
escalate
Delegation
Manual Delegation
An approval item can be delegated to somebody else for processing. This delegation can be
done manually or automatically. Note the following about manual delegation:
● Must be enabled on the approval task

● Delegation is not allowed in the following cases:
- To someone who is already an approver
- To a previous approver (when multiple approvers are part of the approval workflow)
- To a user who is not allowed to see the role or privilege for which the approval was
started

Lesson: Configuring Approval Workflows
- To a role or a privilege
- To the user receiving the assignment (for example, the recipient)
● The new approver can be notified by email about the delegated task
Auto Delegation
Auto delegation can be used when an approver is out of the office or unavailable for any other
reason. Note the following points about auto delegation:
● Automatically delegates all approvals to another user

● Configured for each user separately with the following attributes:
- MX_AUTODELEGATE_MSKEY – MSKEY of the user you delegate to approve on your
behalf
- MX_AUTODELEGATE_MESSAGE – the reason for delegation
● Auto delegation may fail if any of the following scenarios occur:
- The delegate is not allowed to see the role or the privilege that is requested for approval
- Loops are detected – for example, the original approver delegated to the delegate, who
delegates to the original approver
- The delegate is the recipient or the requester of the assignment
● In cases when the auto delegate fails, the approver is removed. If there are no other
approvers available, the approval is declined.
LESSON SUMMARY


Unit 6
Lesson 3
Sending Notifications
LESSON OVERVIEW
In this lesson, you will learn how to send notifications.
LESSON OBJECTIVES
Notification Types
Notification Package
The notification package includes a notification framework that allows you to send e-mail
notifications for certain events.
● The name of the package is “com.sap.idm.util.notification”.

● The package contains a notification process and notification templates.
● Configuration is done using package constants and can be accessed from the IdM Admin
UI.
● The provided message templates can be customized, or new ones can be created.
Message Templates
Message templates allow you to perform the following tasks:
● Specify the text of an e-mail being sent

- Use special variables as placeholders in the template, which are resolved at runtime
before sending the message
● Templates are maintained in the IdM Admin UI, where you can:
- Modify the text of the template
- Add or remove supported template languages
● To do any of the above, you should have one of the following privileges assigned:
- MX_PRIV:WD:MSGTEMPLATE:R (read-only access)
- MX_PRIV:WD:MSGTEMPLATE:RW (read and write access)
LESSON SUMMARY


Unit 6
Lesson 4
Storing Information with Pending Value
Objects (PVOs) and Context Variables
LESSON OVERVIEW
In this lesson, you will learn how to store information with pending value object and context
variables.
LESSON OBJECTIVES
Pending Value Objects (PVOs)

Pending Value Object – Event Tasks
A pending value object (PVO) is used to hold information before it is applied to an entry. The
object itself also has an entry type, which is always MX_PENDING_VALUE. Such objects are
created in the following cases:
● When executing member event processes
● For future attribute values
● For reference attributes the future values are handled in the mxi_link table
Pending value objects are deleted some time after the process for which they were created is
completed.
Common attributes of the PVOs during approvals include the following:
● MX_ENTRY_REFERENCE – contains the mskey, which references the entry for which the
pending object was created (for example, during approval – the mskey of the requestee).
● MX_ATTR_STATE – indicates the state of the attribute on the PVO. Usually it is not
changed, except in cases of automatic decline. It can have the following values:
- 0 – disabled (no reason)
- 1 – pending approval (added on Validate-Add/Delete/Modify events). If during task
completion, the value of this attribute is still 1, the assignment is considered approved.
- 2 – pending enable (waiting for future validFrom)
- 3 – declined approval
● MX_APPROVALS – used for assignment approvals and stored as one multi-value attribute
on the entry. Contains the approvals for the requested role/privilege.
● MX_OWNER – contains the owner(s) of the requested object (for example, role/privilege).

● MX_LINK_REFERENCE – for assignment approvals, it contains the link reference.

● MX_ASSIGNER – holds the mskey of the user who requested the assignment. If the value
is a negative number, it has a special meaning, which could refer the runtime, the REST
API, the dispatcher, VDS, and so on.
● MX_REPOSITORYAME – contains a reference to the repository definition used for the
execution of the task.
● MX_MODIFY_BY – contains the mskey of the last person who modified the entry. Similar
to MX_ASSIGNER, negative values have special meaning.
● MX_MODIFY_REASON – contains the reason for the modification.
● MX_OPERATION – holds information about the operation, for which the pending value
object was created (for example, VALIDATE-ADD, ADD, REQUEST-COMPLETE, and so on).
Pending value objects for future values additionally include the following attributes:
● MX_ATTRIBUTE_NAME – the name of the attribute which will be processed in the future.
● MX_ATTRIBUTE_VALUE – the value to be written when the ValidFrom date arrives.
● MX_ATTRIBUTE_DELETE – contains a list of values with their unique identifiers, which
allow removal of multi-value attributes, for example, role assignments.
- MX_VALIDFROM – the date/datetime from which the attribute value is valid. If this is
not provided, then no pending value object is created, and the value of the attribute is
applied immediately.
- MX_VALIDTO – the date/datetime on which the attribute value will be removed. This is
set as expiryTime for the attribute value.
- MX_VALIDFROM_NEW/MX_VALIDTO_NEW – only during change of validity, these two
attributes hold the extension values for the new validity.
Context Variables
Context variables can transfer data between tasks of the same process. The following
characteristics apply:
● SAP IdM generated context variables always start with #Mx.

● Indicates the type of event which started the task – #MxEventType
● User-defined context variables are allowed (should not start with #Mx)
- Maximum length of the context variable name should be 255 characters, and for the
value, 2000 characters
● Used to pass contextual information between tasks within a process
● A number of u-functions are available to handle context variables
● Deleted when the process execution finishes
● Should only be used if really needed because there is a performance impact
Context Variables List

The following is an excerpt of some of the most commonly used context variables:

Lesson: Storing Information with Pending Value Objects (PVOs) and Context Variables
● #MxEventType – the type of event which started the process. It is a numeric

representation of the various event processes.
● #MxEventAttrCount – a number indicating how many attributes where changed.
● #MxEventAttrName_n – the name of each of the changed attributes.
● #MxEventAttrValue_n – the new value for the changed attributes (empty if the operation is
delete).
● #MxEventAttrContext_n – the new context mskey of the attribute value. Only relevant for
context-based privilege or role assignments.
● #MxEventAttrtype_n – used with modify entry task events and indicates if an attribute was
added, modified, or deleted.
● #MxParentAuditId – the audit ID of the parent process. If empty, there is no parent audit.
● #MxRepositoryId – the repository identifier.
● #MxParentTaskId – the ID of task which started this process. If empty, there is no parent
task.
● #MxLinkReference – a unique numeric reference to the link table.
● #MxMasterPrivilege – the mskey of the master privilege, set for NoMaster task.
● #MxNewValidFrom / #MxNewValidTo – contains the validity dates for the modify validity
task.
● #MxRequestID – generated during request for assignment of role/privilege. Stored in the
link table. All roles/privileges started from one and the same task/job have the same
RequestID.
● #MxInherit_All – if set to 1, all context variables starting with #Mx will be copied to the child
process from the parent, along with user-created context variables.
Note:
For the event attributes values, the context, and the validity, there are also context
variables representing the old values.
Table 4: Event Types

1: EntryAdd 9: Provision task 17: NoMaster task
2: EntryModify 10: Deprovision task 18: ValidateAdd
3: EntryDelete 11: Modify privilege task 19: ValidateDel
4: AttributeAdd 12: InitTask 20: ModifyValidity
5: AttributeModify 13: OnChainOK 21: Validate Modify validity
6: AttributeDelete 14: OnChainError 22: Notify
7: OnOK 15: AddMember task 23: RequestComplete
8: OnError 16: DelMember task 24: IdMUI submit

Context Variable Functions

The following u-functions are available for handling context variables:
● uSetContextVar – updates the value of a context variable. The existing value is

overwritten. If it does not exist, it is created.
● uGetContextVar – returns the value of a given context variable.
● uIncContextVar – increments a context variable by 1. If the variable has no value or it is not
numeric, 0 is assumed.
● uAppContextVar – appends a string to an existing value of a context variable. If there is no
existing value, only the appended string will be the value of the context variable.
● uMGetContextVar – returns all context variables matching a given filter. If no filter is
provided, all context variables are returned.
LESSON SUMMARY

Unit 6
Lesson 5
Implementing Automatic Approve/Decline
LESSON OVERVIEW
In this lesson, you will learn how to implement automatic approve/decline of role requests.
LESSON OBJECTIVES
Automatic Approve/Decline
To evaluate if certain assignments should be automatically approved or declined, normally
you would need additional information to make a proper decision. With the help of the PVO,
you can access various attributes related to the user receiving the assignment (for example,
the SUBJECT), to the role or privilege being assigned, the context, if any, as well as the
properties from the link table. Access to these attributes is granted using pre-defined prefixes
as shown in the figure, PVO Event Tasks.
Figure 47: PVO Event Tasks
Programmatic Processing of Approvals

Programmatic processing of approvals is performed using the internal u-function
uIS_Approval:
● The u-function uIS_Approval has the following definition:

- uIS_Approval(Int Operation, String AdditionalParams, Int ApprovalID, Int Approver,
[String Reason], [String ValidFrom], [String ValidTo]);
● You can find approval information in the following views:

- idmv_approvals_basic
- idmv_approvals_ext
The function supports a number of operations related to the approval. Some of the common
ones are as follows:
● Approve (1)
● Decline (2)
● Delegate (3)
● Add approver (4)
● Remove approver (5)
Operations like add and remove approver, and delegate, require additional input
(AdditionalParams) with the mskey of the entry which is targeted.
Dynamic Calculation of Approvers

Dynamic calculation of approvers is possible using the PVO with the following pre-requisites:
● A preprocess is needed, which sets the approvers on PVO

● The approval task is configured to retrieve approvers from the PVO
LESSON SUMMARY

Unit 6
Learning Assessment
1. What are the prerequisites for using a process in another package?

X A The process should have at least one Action Task
X B The process should be of the type Regular
X C The process should be public
X D The process should work with PVOs
X E The process should work with context variables
X F The process should adhere to the naming convention of IdM for public objects
2. What is the difference between a switch and a conditional task?

X A They have different options for setting a condition
X B They have different result handling events
X C They could have different number of exit branches
X D They always have exactly one default exit branch
3. Which event task should be used if you want to have an approval for particular privilege/
role?
X A Validate Modify Validity
X B Add
X C Validate Add
X D Validate Remove

4. Which process should be defined on repository type level if you do not want to always
assign the ONLY privilege alongside backend system privileges to start provisioning?
X A Connection expiration
X B Provisioning
X C Validate Add
X D No Master Process
5. Which of the following are valid exit branches of an approver task?

X A Timeout
X B Escalation
X C Approve
X D Decline
6. Which attribute of the PVO contains the approvers for the requested assignment?
X A SUBJECT.MSKEYVALUE
X B MX_APPROVERS
X C LINK.LinkAssigner
X D TARGET.MSKEY
7. What is the purpose of the context variable #MxLinkReference?

X A Contains the link audit ID
X B Contains the link valid from and valid to
X C Contains the parent link task ID
X D Contains a unique reference to the link table

Unit 6
1. What are the prerequisites for using a process in another package?

X A The process should have at least one Action Task
X B The process should be of the type Regular
X C The process should be public
X D The process should work with PVOs
X E The process should work with context variables
X F The process should adhere to the naming convention of IdM for public objects
2. What is the difference between a switch and a conditional task?

X A They have different options for setting a condition
X B They have different result handling events
X C They could have different number of exit branches
X D They always have exactly one default exit branch
3. Which event task should be used if you want to have an approval for particular privilege/
role?
X A Validate Modify Validity
X B Add
X C Validate Add
X D Validate Remove

4. Which process should be defined on repository type level if you do not want to always
assign the ONLY privilege alongside backend system privileges to start provisioning?
X A Connection expiration
X B Provisioning
X C Validate Add
X D No Master Process
5. Which of the following are valid exit branches of an approver task?

X A Timeout
X B Escalation
X C Approve
X D Decline
6. Which attribute of the PVO contains the approvers for the requested assignment?
X A SUBJECT.MSKEYVALUE
X B MX_APPROVERS
X C LINK.LinkAssigner
X D TARGET.MSKEY
7. What is the purpose of the context variable #MxLinkReference?

X A Contains the link audit ID
X B Contains the link valid from and valid to
X C Contains the parent link task ID
X D Contains a unique reference to the link table

UNIT 7 Context-Based Assignments
Lesson 1
Defining Context 137
Lesson 2
Creating Guided Activity Forms 141
Lesson 3
Provisioning Context Toward Backend Systems 145
Lesson 4
Assigning Automatic and Conditional Context 149
UNIT OBJECTIVES
● Define a Context in SAP Identity Management

● Create guided activity forms to request privileges
● Provision context towards back-end systems
● Assign automatic and conditional context

Unit 7: Context-Based Assignments

Unit 7
Lesson 1
Defining Context
LESSON OVERVIEW
In this lesson, you will learn how to define context.
LESSON OBJECTIVES
Basic Assignments
Figure 48: Basic Assignments
Assignments in SAP Identity Management link a person to an authorization, which is a

privilege or role. Each authorization can be assigned to one or more people, or not assigned at
all.

Context-Based Assignments
Figure 49: Context-Based Assignments
Context-based assignments involve three entries – a person, a role or a privilege, and a

context. The purpose of context-based assignments is to reduce the number of roles. To any
role or privilege assignment it is possible to add a reference to a given context that limits the
validity of the assignment to that specific context. A context may be any meaningful attribute,
which impacts the authorizations that a person will receive based on it, for example, a region,
project, or organizational unit.
Context-based assignments reduce the number of roles or privileges required to map the
authorizations or rights in the external (back-end) system. For example, a company that has
1,000 stores and 20 roles per store has a total of 20,000 role entries. Using context-based
assignments, the total number of entries is only 1,020, which is 1,000 contexts + 20 roles.
Figure 50: Context Behavior
Context Type
Each type of context must be created as a separate entry type, for example Store. Each
context is defined as an entry with this entry type. For example, if the context type is Store,
each store location is defined as an entry with this entry type.

Lesson: Defining Context
The specified context follows the inheritance of the assignment. If a role is assigned with a
given context, then all inherited roles and privileges are also assigned in the same context.
Context types are defined based on the need of the project. Each role or privilege have a
defined set of legal contexts. This set is stored in the privilege under attribute MX_CTX_TYPE.
When an assignment is made, only contexts of the specified context types can be in the
assignment.
MX_CTX_TYPE can be set either on roles, privileges, or repository types.
Context Types
Many different context types can be defined including the following:
● Factory
● Store
● Project
● Location
LESSON SUMMARY


Unit 7
Lesson 2
Creating Guided Activity Forms
LESSON OVERVIEW
in this lesson, you will learn how to create guided activity tasks.
LESSON OBJECTIVES
Guided Forms
Figure 51: Guided Tasks
Most of the forms in SAP IdM are created with one atomic step or operation, for example,
assignment of access or update of master data. However, guided activity forms have multiple
steps organized in a wizard-like UI. When context is available, they are used for assignments
of role or privileges.
Guided Task — Assignment Request

Configuration parameters for guided tasks include the following:
● Entry type (usually MX_PERSON) has the following steps:
1. Request context (optional)

- Context type (none, specified entry type, allow user select)
- Multiple contexts (yes, no)
- Mandatory context (yes, no)
2. Request role or privilege
- Entry type (MX_ROLE, MX_PRIVILEGE)
- Multiple assignments (yes, no)
3. Add validity and reason (optional)
- Ask for validity (yes, no)
- Ask for reason (mandatory, optional, none)
4. Confirm
If you do not want to use Guided tasks but want to assign the context automatically
with a job or an action task, you can specify the context, as shown in the figure, Context
Assignment from the Runtime, and the figure Assignment with Illegal Context Type.
Figure 52: Context Assignment from the Runtime
Figure 53: Assignment with Illegal Context Type
To make an assignment including a context, the role or privilege must have the entry type of
the context object as a legal context type. Set the MX_CTX_TYPE on the entry to the entry
type you want to use as context.

Lesson: Creating Guided Activity Forms
Every role and privilege which you want to assign with a context must have the MX_CTX_TYPE
set. If you attempt an assignment with a context entry, where the entry type of the context
entry is not defined in the MX_CTX_TYPE:
● If this is a direct assignment, an error is returned.
● If this is an indirect assignment, this is silently ignored, and you will not get the inherited
role/privilege
Once assigned, MX_CTX_TYPE is rarely removed or changed. However, if you must do this,
note that there is no automatic reconciliation process started. You must ensure that all
affected users are marked as dirty, so that the reconciliation process picks and cleans them.
LESSON SUMMARY


Unit 7
Lesson 3
Provisioning Context Toward Backend
Systems
LESSON OVERVIEW
In this lesson, you will learn how to provision context towards back-end systems.
LESSON OBJECTIVES
Context Towards Back-End Systems

Context-based assignments in IdM correspond to a single authorization. The way the context
is handled during provisioning of the assignment depends on the backend system. There are
three options for handling context-based assignments based on the backend system:
● Backend systems that can identify contexts: Send the user, authorization, and context
(triplet) to the back-end system
● Backend systems that cannot identify contexts:
- Convert the triplet to single authorization in the backend system.
- Use the context to define different backend systems to send the authorization to.

Sending Triplet to the Back-End System
Figure 54: Setup of People, Store Locations, and Privileges
If the back-end system can identify the context, then no conversion is needed. You can send
the following objects to the target system:
● User
● Context
● Privilege
Note:
Only a few systems currently support this, for example, Active Directory.

Lesson: Provisioning Context Toward Backend Systems
User, Authorization, and Context Conversion
Figure 55: Triplet Conversion to Backend Authorization
Note the following when converting users, authorizations, and context:
● The following is sent to the target system:

- User
- Authorization (translated from privilege and context)
● One of the following authorizations must be available for each possible combination in the
backend system:
- LV-Manager
- LV-Supervisor
- WDF-Manager
- WDF-Supervisor
Depending on how assignment is done, there might be two different solutions on how to
assign context-based privileges:
● Using privileges: Generate one privilege for each global authorization, for example,
Manager or Supervisor. Then, based on the context assignment, create a mapping to the
backend authorizations.
● Using business roles: Assign all backend authorizations to a business role with the proper
context, for example, Walldorf or Las Vegas. Then, assign the business role to the user with
needed context, for example, Waldorf or Las Vegas. Only the one that matches the
privileges are assigned. The rest are silently ignored.

Context for Provisioning to Different Backend Systems
Figure 56: Context for Provisioning to Different Backend Systems
● Each context is stored as a different system.

● All systems have the same privileges.
● The context defines the system where the information is sent. Here is the data sent to the
backend system:
- User
- Authorization
LESSON SUMMARY

Unit 7
Lesson 4
Assigning Automatic and Conditional Context
LESSON OVERVIEW
In this lesson, you will learn how to assign automatic and conditional context.
LESSON OBJECTIVES
Context-Relevant Entry Types and Attributes
Figure 57: Context-Relevant Entry Types and Attributes
Automatic Context
Automatic context is for automatically calculating, in runtime, if a requested assignment
without context assigns its privileges with or without context based on context-automatic
values assigned to a person and the automatically-assign policy of the privileges:
● Privileges have an attribute, MX_CTX_AUTO_POLICY, that defines the autoassign policy

- It can be configured on the privilege or inherited from the repository type.
- Defines the rules that apply when assigning a privilege with context:
■ None: Never add context, for example, assign privilege without context.

■ If missing: Only add the context if not part of the request assignment already.
■ Always: Always try to assign with context regardless of the requested context.
● The autoassign policy does not apply to any other entry types than MX_PRIVILEGE.
● Alternatively, the MX_PERSON entry type has an attribute, MX_CTX_AUTO_VALUES, that
holds references to one or more context values.
Country-Based Assignment
Figure 58: Example - Automatic Context with Country-Based Assignment
The user attribute MX_CTX_AUTO_VALUES holds the country-context values for the user.
These are automatically added to assignments. Consider the following scenario, as shown in
the figure, Example - Automatic Context with Country-Based Assignment:
● MX_CTX_AUTO_VALUES has country-context values for the user.

● MX_CTX_AUTO_POLICY is either 'If missing' or 'Always'.
● MXREF_MX_PRIVILEGE is requested for assignment without context.
● The requested privilege is assigned as many times as there are context values in the
requested person's attribute MX_CTX_AUTO_VALUES.
● If the context-values assigned to a person change, the assignment is updated
automatically.
Automatic Context Example
Figure 59: Example - Inherited Automatic Context

Lesson: Assigning Automatic and Conditional Context
The figure, Example - Inherited Automatic Context, shows an example of inherited automatic
contexts. In the example, all roles and privileges in the diagram have a properly set,
MX_CTX_TYPE, that enables assignment of the country context.
● Role 1 (R1) is requested for assignment without context.
● Role 3 (R3) is a child to Role 1 (R1). It also has no context assigned because it inherits the
context from Role 1
● Depending on the Privilege 1 (P1) autopolicy, the following scenarios are possible:
- None: P1 is assigned without context.
- If missing: Context value US is added to P1 because the role is requested for
assignment without context and the user has the context value US in the context auto
values attribute.
- Always: Context value US is added to P1 because the policy implies that it is always
added and the user has the context value US in the context auto values attribute.
Conditional Context
The purpose of conditional context is to handle a privilege assignment when the assignment is
requested with context.
● The scenario is handled through the attribute MX_CTX_AUTO_VALUES of the privilege:

- The requested context is assigned if it is in the list of context values for this attribute.
- If no context values are listed in MX_CTX_AUTO_VALUES of the privilege, then any
context value is accepted.
- The attribute acts as a whitelist for the privilege context assignment, for example, if it is
empty, then any context is accepted; if it contains only listed entries, then only what is
listed is accepted.
● When assigning a context value that is not in the listed values of MX_CTX_AUTO_VALUES
but there are defined context values in MX_CTX_AUTO_VALUES of the privilege, the
following occur:
- Direct assignments return an error.
- Inherited assignments are silently ignored.

Conditional Context
Figure 60: Example - Conditional Context
The figure, Example - Conditional Context, shows a use case. In this example, we assume that
both the role and privilege are set to Country
● Role assignment with context value “Norway” is requested.

● The assignment contains three privileges. Each has different context values assigned to
their MX_CTX_AUTO_VALUES.
● The only privilege assigned to the user matches the requested context.
● The other two privileges are silently ignored because the requested context is not on their
whitelists.

Lesson: Assigning Automatic and Conditional Context
Inherited Conditional Context Assignment
Figure 61: Inherited Conditional Context Assignment - Example
The figure, Inherited Conditional Context Assignment - Example, shows the following when
business roles are requested with context:
● Role 2 (R2) is requested for assignment with context value US.

● Role 3 (R3) and Role 4 (R4) inherit the context value from R2.
● Privilege 1 (P1) inherits context value US. It has no values in the attribute
MX_CTX_AUTO_VALUES. Thus, it enables any context.
● Privilege 2 (P2) inherits context value US. It matches an already-defined
MX_CTX_AUTO_VALUES with the same context value of US.
● Privilege 3 is not assigned to the user. Its list of values in MX_CTX_AUTO_VALUES does
not contain the context value US (it contains DE).
LESSON SUMMARY


Unit 7
Learning Assessment
1. When creating a new context entry type, how do you create the context values?
X A Programmatically using a To Identity Store pass
X B Entering the values in the Context tab
X C Creating a form that creates the values
X D Adding them to the auto-values of the MX_PERSON object
2. What type of contexts are available?

X A General context
X B Conditional Context
X C Automatic context
X D Combination of conditional and automatic context
3. Which entry types support the MX_CTX_TYPE attribute by default?

X A MX_PERSON
X B MX_CTX_AUTO_VALUES
X C MX_ROLE
X D MX_PRIVILEGE

4. When requesting a context for a privilege, the privilege is assigned even if the conditional
context does not contain the context from the assignment. (Assume that the person has
no context auto-values defined.)
X A Yes
X B No
X C Depends on the context whitelist of the privilege

Unit 7
1. When creating a new context entry type, how do you create the context values?
X A Programmatically using a To Identity Store pass
X B Entering the values in the Context tab
X C Creating a form that creates the values
X D Adding them to the auto-values of the MX_PERSON object
2. What type of contexts are available?

X A General context
X B Conditional Context
X C Automatic context
X D Combination of conditional and automatic context
3. Which entry types support the MX_CTX_TYPE attribute by default?

X A MX_PERSON
X B MX_CTX_AUTO_VALUES
X C MX_ROLE
X D MX_PRIVILEGE

4. When requesting a context for a privilege, the privilege is assigned even if the conditional
context does not contain the context from the assignment. (Assume that the person has
no context auto-values defined.)
X A Yes
X B No
X C Depends on the context whitelist of the privilege

UNIT 8 Advanced SAP IdM Topics
Lesson 1
Configuring the Virtual Directory Server (VDS) 161
Lesson 2
Managing Passwords with SAP IdM 173
Lesson 3
Explaining the Reporting Tools 177
Lesson 4
Debugging Entries 183
Lesson 5
Running Housekeeping Procedures 185
Lesson 6
Implementing Hybrid Scenarios 187
UNIT OBJECTIVES
● Configure the VDS

● Manage passwords with SAP IdM
● Explain the reporting tools
● Enable the entry trace for debugging
● Configure the schedule for housekeeping procedures
● Explain the role of SAP IdM in hybrid scenarios

Unit 8: Advanced SAP IdM Topics

Unit 8
Lesson 1
Configuring the Virtual Directory Server (VDS)
LESSON OVERVIEW
In this lesson, you will learn how to configure the Virtual Directory Server (VDS).
LESSON OBJECTIVES
VDS Overview and Architecture

Virtual Directory Server
Figure 62: Virtual Directory Server
SAP NetWeaver Identity Management Virtual Directory Server can logically represent
information from a number of disperse directories, databases, and other data repositories in a
virtual directory tree. Different users and applications can, based on their access rights, get a
different view of the information.
Features like namespace conversion and schema adaptations provide customers with a
flexible solution that can continually grow and change to support various demands from
current and future applications and demands for security and privacy without changing the
underlying architecture and design of data stores like databases and directories.

Virtual Directory Server Architecture
● Uses a Java GUI for the configuration (1)

● The information provided in the Java GUI is stored in configuration XML files (2)
● When the server is started, it read the configuration file and listens on a specified port
● If the configuration is changed, while the server is running, the configuration should be
reloaded
● Clients (3) connect to the inbound connector for the appropriate client protocol
● The LDAP protocol (4) is part of the VDS Kernel (6). It is the natural language of VDS.
● If a different protocol is used, then it is transformed using the extensible transformation
framework (5) to the internal (LDAP) format.
● Client requests are performed on data sources (9). To extend the number of accessible
data sources, VDS uses a connector framework (7).
● The information from the client request is passed to the methods in the connectors as
parameters. Then they perform the request to the data source using the appropriate API
(8) – e.g. JDBC.
Virtual Directory Server as an LDAP Client/Server
● The Virtual Directory Server can act as a server for incoming LDAP or SPML requests.
● The Virtual Directory Server can act as a client when accessing its back-end data sources.
● Both the client and the server can be configured to use SSL when accessing LDAP data.
Virtual Trees
The core functionality of the Virtual Directory Server is joined in the concept of virtual trees. A
virtual tree provides a structure that combines data sources with user groups and rules that
are used when processing the requests submitted from the clients.
The Virtual Directory Server always creates one virtual tree, but you can define more than
one, if necessary. This could be the case if you want clients to access the same server and
port number using the same starting point, but either give different clients different views
(structure) of the same data source, or even connect to different data sources.
● One user group may be associated with only one virtual tree
● Data sources and rules are available to all virtual trees
● The virtual tree can contain two node types:
- Static – do not reference any data source. Used to build the structure of nodes for the
tree starting points
- Data source – underlying objects are retrieved from the data source
● The structure of a virtual tree must comply with the LDAP standard (e.g. only one level with
attribute o=, which can be followed by one or more ou=)
● A node’s qualified name consists of the name of all nodes above the node in the virtual tree
including the node itself (e.g. o=data,cn=john smith)

Lesson: Configuring the Virtual Directory Server (VDS)
● When running VDS as a server, you can access it as any other LDAP server. The server
configuration can be run also in test mode. In this case the data sources are accessed
through the internal tree, which is simply a representation of the data source in LDAP
structure, where each data source has its own DN. The internal tree itself has the DN
o=internal. (e.g. ou=ds_<unique ID of source>,o=internal)
Processing of LDAP Requests
Figure 63: Processing of LDAP Queries
The following processes handle the request:
● Attribute names are converted from the client attributes to the internal attributes (1)
● The request is cleaned using rule configurations. They define which attributes are allowed
and all others (e.g. not allowed) are cleaned (2)
● The remaining attributes are converted according to the data source configuration (3)
● There follows a new attribute clean-up, according to the specified data source (4)
● The same is applied to the filter attributes (5)
● The converted request is processed using the defined methods for the appropriate
connector (6)
● Due to the applied filters, it might happen that either the attribute or filter part of the
request become “empty”. In this case the request is not carried out and an error message
is returned to the client.
Example of VDS Request Processing
● The data source is an SQL database

● The attribute part should be converted to the SELECT statement criteria
● The filter part should be converted to the WHERE clause in the SQL query

● ldap://<computer>:<port number>/c=no?sn,cn, telephoneNumber?sub?(|

(givenName="j*)(sn=n*))
● Assuming the data source does not support the givenName attribute, then:
- SELECT TOP 50 sn, cn, telephoneNumber FROM testdata where ( sn like 'n*' );
- The query is executed because the condition for the filter is OR. If it was AND, it would
have been rejected due to the absence of the givenName attribute.
- The size limit of the SELECT statement is something which depends on the SQL
database and can be configured additionally. (It should not be omitted, since it could
return an extremely large set of data.)
Configuration Deployment
Figure 64: Web Service Deployment
When you deploy the configuration, you specify the server name and port number that the
clients will use to access the server.
Support of Two Deployment Modes
● LDAPserver (default) (main_listener)

- Additional deployments are allowed if you need to support several access points (e.g.
with and without SSL)
● Web service for SPML v1.0 (running on SAP NetWeaver Java server)

VDS Use Cases

HCM Integration Use Case
Figure 65: HCM Integration Use Case
When connecting an SAP HCM system to SAP Identity Management, the identity data is
exported from the SAP HCM system and imported into the Identity Store. For this, the Virtual
Directory Server is used as the common interface for processing the data. You can therefore
use the export functions in SAP HCM that are available for exporting data to an LDAP
directory. This data is then imported into a staging area before being replicated into the
productive identity store. Once the data is in the productive identity store, it can be
provisioned to the connected systems.
In order to establish the integration, certain prerequisites should be met:
● VDS should be installed, configured properly and running

● The user exporting the data from HCM should have the following roles assigned:
- SAP_HR_LDAP_EXTRACTION (execution of data extraction)
- SAP_HR_LDAP_PREPARE_EXTRACTION (needed for attribute mapping)
● An LDAP Connector to VDS should be configured in the SAP HCM system
● A decision should be made on how to assign a user account name in SAP IdM to an
employee coming from HCM

Integration with SAP GRC Access Control
Figure 66: Integration with SAP GRC Access Control
The SAP Identity Management GRC integration consists of a set of processes in SAP IdM and
a configuration in the Virtual Directory Server that enables the use of SAP Access Control for
risk validation before user provisioning. Using this solution, SAP Identity Management can
execute provisioning to multiple target systems which are controlled by SAP Access Control
to ensure compliance according to the rules implemented here.
Possible Landscape Configurations

Based on the type of provisioning scenarios, two landscape configurations are possible:
● Centralized provisioning: This is a scenario where SAP Identity Management is the only
provisioning system, responsible for provisioning both the assignments that require and
do not require compliance checks to the target systems
● Distributed provisioning: This is a scenario where the provisioning is performed both by
SAP Identity Management and SAP Access Control

Figure 67: Centralized Provisioning
Figure 68: Distributed Provisioning
SAP Identity Management Processes Related to SAP GRC

There are two types of processes when it comes to obtaining the result from SAP GRC Access
Control Risk Analysis in SAP IdM:
● AC Validation – Risk Analysis Only – the validation result is obtained through a

synchronous call to GRC/AC system. This process does not wait on the result of other
GRC related processes such as risk mitigation. Thus, the result of the risk mitigation is not
synced in SAP IdM. Also keep in mind that risk analysis result might take long depending
on the number of privileges and their dependency rules. This might lead to timeouts.

● AC Validation – the result can be obtained based on the defined result handling option
(polling or AC callback)
Result Handling Options

Whenever a request to SAP Access Control is sent by the SAP Identity Management, further
action depends on the results of SAP Access Control's request processing, i.e. which
privileges are approved, and which are not. Two different approaches to handling a request-
processing result exist and only one of them can be active at a time.
● Polling - Identity Management performs the appropriate web service request, polling the
SAP Access Control for the result continuously at a particular interval (which is
configurable). This result handling scenario is fail-safe.
● Event-based (AC Callback Service) - Instead of polling for the result, Identity Management
is informed about the status of the request when the processing is done. The information
about this is sent by GRC (SAP Access Control) by calling a web service deployed on SAP
NW Java (GRAC_EXIT_FROM_IDM_WS) and Identity Management is waiting for this call.
Only one call is made, which makes this result handling scenario more vulnerable (not fail-
safe) as this one call may be lost (e.g. due to network issues)
Which of the two behaviors is active is configurable with a set of constants on the GRC10
repository within SAP IdM.
In the centralized provisioning scenario, the process executes a synchronous call to the GRC
system, which obtains the risk result immediately. No use of result handling scenarios is
needed. Those apply only to the distributed provisioning scenario.
Figure 69: GRC with Exit Service/Callback Service

Figure 70: GRC with Polling Mechanism
Business Role Synchronization

The enhanced integration between SAP Identity Management 8.0 and SAP Access Control
(for GRC solutions) 12.0 or higher allows you to synchronize business roles between both
systems before user provisioning.
● GRC is the leading system for business roles

- Reads all relevant privileges from SAP IdM
- Use the privileges to build business roles
- SAP IdM specific privileges (e.g. MX_PRIV:* are not read)
- Created business roles in GRC are loaded back in SAP IdM with a dedicated Initial Load
job.
● Business roles in GRC are created for a dedicated environment (e.g. Development, Test,
Production)
- If a business role is created for all environments, SAP IdM will load three business roles
(e.g. <business role name_PRD>, <business_role name_TST> and <business role
name_DEV>
- In SAP IdM there are three attributes, which define business roles loaded from GRC:
Attribute Description
MX_AC_MAINTAINED Indicates that a role is created and main-
tained in the GRC system
MX_AC_ENVIRONMENT Specifies the GRC provisioning environ-
ment

MX_AC_ROLEID Holds the role name as it is retrieved from

the GRC system
● Certain attributes are locked in SAP IdM to avoid desynchronization between the two
systems. You should not modify these:
- DISPLAYNAME
- DESCRIPTION
- MX_AC_ENVIRONMENT
- MX_AC_ROLEID
- MXMEMBER_MX_PRIVILEGE
Provisioning Initiation Options

There are two provisioning initiation scenarios, depending on which system initiates the
provisioning (only one of the two should be active at any one time):
● SAP IdM-initiated provisioning - Identity Management performs the appropriate web

service request, polling the SAP Access Control for the result continuously at a particular
interval (which is configurable). This result handling scenario is fail-safe.
● GRC-initiated provisioning - GRC initiates the access request and triggers the provisioning
to target systems, while SAP Identity Management is performing the actual provisioning to
the target systems (e.g. they are connected to SAP IdM). In this scenario GRC and SAP
IdM should have a configured business role synchronization (e.g. using a shared role
model)
Figure 71: Overview of All GRC Integration Scenario Combinations
VDS as an LDAP Gateway

The Virtual Directory Server can act as a LDAP gateway to information stored in corporate
applications and relational databases as well as any other data source that includes an API
interface.
● VDS can perform value adding features including:

- Attribute mapping
- Value conversion

- Filtering
- Access Control
- Join
- Logging
- Using a fail-over server
Figure 72: LDAP Enabling of an SQL Source
Figure 73: Publishing Identity Data

Encryption and Keys.ini File
Figure 74: Encryption and Keys.ini File
IdM can encrypt and hash attribute values.
● The Keys.ini file contains information about the following:

- Encryption keys
- Encryption and hash algorithms
● VDS and IdM need the same set of encryption keys.
● The VDS GUI checks the parameter KEYS_INI_FILE in .vdssettings for the path or the
folder specified with the environment variable VDS_HOME.
● For configurations deployed on SAP NetWeaver Java, the location is retrieved from the
Java properties of the application.
LESSON SUMMARY

Unit 8
Lesson 2
Managing Passwords with SAP IdM
LESSON OVERVIEW
In this lesson, you will learn how to manage passwords with SAP IdM.
LESSON OBJECTIVES
Password Management with SAP IdM

Usually password management is a self-service task in SAP IdM which allows users to change
their passwords for all target systems in which they have accounts. However, it is also
possible to allow for administrative management of the password – for example, through the
Manage tab of the standard SAP IdM UI (delegated management). Additionally, end users
might even have anonymous access to tasks for resetting their domain password, if the
domain controller is connected to SAP IdM as a target system.
The password reset process consists of three steps:
● Identify – the user will be asked for a unique identifier (could be MSKEYVALUE or other
unique attribute)
● Verify identity – the user should answer some pre-defined questions, to which only he/she
knows the answer
● Set password – a new password is set for the user, either as manual input or generated by
the system.
Password reset may fail due to various reasons (e.g. complexity of password, user locked in
target system, repeated password from history, etc.). Such failed attempts are logged.
The password reset form should be configured to call a Password reset failed process.
Parameters, like defining a minimum number of validation answers or a number of
authentication questions that should be displayed for the user, need to be defined also.
The password reset form should also be referenced from the identity store.

Figure 75: Password Management
Figure 76: Password Authentication
Initial and Productive Passwords

Note the following differences in initial and productive passwords:
● Initial password
- Target system would require the user to change the password on first login
- If no password is provided, some target systems will disable login with password
● Productive password
- Target systems require SSL connection in order to set productive passwords
- To set a productive password use the attribute “ProductivePwd” with the value “X”
Password Attributes
The following attributes are related to password management:

Lesson: Managing Passwords with SAP IdM
● MX_PASSWORD
- Stores hashed password
- Used by the IdM UI for password input
- One central password for all connected target systems
● MX_ENCRYPTED_PASSWORD
- Used for password provisioning and synchronization
If password provisioning is enabled, the UI encrypts and writes to

MX_ENCRYPTED_PASSWORD when MX_PASSWORD is changed.
If a custom attribute is used for the password, it must be stored as an encrypted attribute.
LESSON SUMMARY


Unit 8
Lesson 3
Explaining the Reporting Tools
LESSON OVERVIEW
In this lesson, you will learn how to explain reporting tools.
LESSON OBJECTIVES
Reporting Overview
IdM Reporting Options
The following options are available to create IdM reports:
● HTML reports
- Generates static HTML reports from data available in IdM
- Uses SQL queries to define the resulting data set
- Uses MX_REPORT entry type
- Result is stored as a binary in the database
● BW reporting
- IdM data can be replicated to SAP BW using a data transfer job from IdM
- After the initial load, it is recommended to set up a delta load to avoid long-running jobs
- BW can generate reports based on replicated data
- Good option if BW is already in use for reporting purposes
● SAP Lumira or SAP Analytics Cloud
- Can be used to connect directly to the SAP IdM database and build dashboards for self-
service reporting
HTML Reports
Reports that successfully extract information from IdM are visible in the View Reports tab.
● On the Attributes tab of the form, define the following:

- Entry type to be reported on
- Select the checkbox for the Report form
● Attach process on submit of the report form to generate the report:

- Use MX_REPORT as the entry type on the destination tab

- Receive the MSKEY of the entry which will be reported on in the attribute
MX_REPORT_ENTRY
- Use the MSKEYVALUE of the created report to populate values from SQL
- Write a script to format the HTML report
- Store the values as binary data in MX_REPORT_RESULT
- Use MX_REPORT_FORMAT to set the reporting file format
BW Reports
Note the following about SAP Identity Management and BW reporting:
● Object types (can be extended):

- Person (State and History)
- Privilege (State and History)
- Role (State and History)
● Report types:
- Content-based reporting (person attributes or role memberships)
- Time-based reporting (state on given date or changes within period)
● Aggregations: The number of assignments between object types
● Basic auditing data: Who changed what
● Authorization concept with three roles:
- Administrator: SAP_BW_IDM_REP_ADMIN – Sees all entries requested by the query
- Manager: SAP_BW_IDM_REP_MANAGER – Sees only the identities and corresponding
assignments for which he/she is a manager in SAP IdM (e.g. MX_MANAGER)
- Object owner: SAP_BW_IDM_REP_OWNER – Sees only the entries for which he/she is
an owner in SAP IdM (e.g. MX_OWNER)

Lesson: Explaining the Reporting Tools
Architecture
Figure 77: Architecture
Note the following about the reporting architecture:

● IdM pushes data into BW (via Virtual Directory Server)
● Job is provided for initial load and delta loads
● Virtual Directory Server acts as a Web Service Client
● Job triggers further processing in BW (Process Chain) – attribute sorting, transformations,
assign attributes to InfoProviders
Figure 78: Person Details on a Specific Date

Figure 79: Person History
Lumira Reporting
SAP Identity Management Analytical Reports using SAP Lumira
You can run SAP Identity Management analytical reports using SAP Lumira. SAP Lumira
includes the following components:
● SAP Lumira desktop

Visualize large volumes of data without sacrificing performance, security, or scale.
Maximize data knowledge across the enterprise.
● SAP Lumira server
Business users can analyze real-time data using the latest visualization technologies.
Processes large volumes of data and reduce time to insight.
● SAP Lumira cloud
SAP Lumira Cloud helps you visualize large volumes. Users can discover hidden insights
using mobile devices or in browser.
Figure 80: SAP Lumira Sample Report

Lesson: Explaining the Reporting Tools
SAP Lumira Report Features

SAP Lumira includes the following report features:
● Employees and roles

- Report that contains a table with all employees and their business roles
- Reports are accessible in a browser
● Geographical distribution of employees
- Extend the previous report with information about the number of employees per
country
- Add the employee name to table with user details
● Statistics about roles and filtering
- Enhance the report with details about how many employees have a given business role
- Provide possibility to filter all the information based on country and/or business role
● Systems and privileges
- Provide information about the systems in the landscape and the users that have access
to those systems
- User details, including assigned privileges, their validity, when they were modified and
information about the type of assignment (for example, direct or indirect) as well as the
system to which those privileges belong
- Provide capabilities to filter based on system (repository) and/or employee and/or
privilege type (direct/indirect)
Figure 81: SAP Lumira Landscape
Data Extraction, Manipulation, and Visualization

Note the following about data extraction, manipulation and visualization:
● Connection

- Direct connection to SAP IdM DB

- System user with permissions to execute queries
● DB interfaces — DB views that are delivered as part of SAP IdM
● Data extraction — Standard SQL queries
● Data manipulation — Information is retrieved and manipulated in datasets inside the SAP
Lumira desktop (self-service reporting)
● Data visualization — Information is shown in visualization objects and created inside the
SAP Lumira desktop
Data Refresh
You can refresh data in the following ways:
● Automatic
- Schedule data extraction from the DB
- Schedule data publication to SAP Lumira cloud
● Manual
- Manual data extraction from SAP Lumira desktop
- Manual publication of the refreshed DataSets to SAP Lumira cloud
LESSON SUMMARY

Unit 8
Lesson 4
Debugging Entries
LESSON OVERVIEW
In this lesson, you will learn how to debug entries in SAP IdM.
LESSON OBJECTIVES
Entry Trace
Entry Traces
The purpose of an entry trace is to follow the processing of a single entry. Entry traces can be
enabled from the Admin UI. An entry trace includes the following:
● Traced information
- Writing attributes
- Internal operations
- Conditional tasks such as SQL queries
- Switch tasks
- Script log messages (uErrMsg, uWarning, uInfo)
- Dispatcher operations
- Time
- PVOs
● On database level, the views containing the traced information are:
- Core data — idmv_trace_basic
- User friendly format — idmv_trace_data
LESSON SUMMARY


Unit 8
Lesson 5
Running Housekeeping Procedures
LESSON OVERVIEW
In this lesson, you will learn how to run housekeeping procedures in SAP IdM.
LESSON OBJECTIVES
Housekeeping Procedures
Housekeeping Procedures
Note the following about housekeeping procedures:
● Periodic tasks and scheduling

- Delete old log entries: System logs, job logs, and dispatcher logs
- Check for time restricted attributes: Pending values to be applied and expired
attributes
- Reconcile dirty entries
- Several hidden procedures
● Executed by dispatcher:
- Control which dispatcher is responsible for housekeeping
● Customizable parameters
- Control how much old data to keep
LESSON SUMMARY


Unit 8
Lesson 6
Implementing Hybrid Scenarios
LESSON OVERVIEW
In this lesson, you will learn how to implement hybrid scenarios.
LESSON OBJECTIVES
Identity and Access Management as a Service from SAP

SAP Identity Management can be combined with other SAP products in the cloud to provide a
seamless hybrid IAM solution for the customers.
The solutions include:
● SAP Cloud Platform Identity Provisioning

- Automatically sets up user accounts and authorization
- Optimized for SAP cloud applications
- Reuses existing on-premise and cloud user stores
● SAP Cloud Platform Identity Authentication
- Simple and secure access to web-based applications
- Password policies, Multi-factor and risk-based authentication
- On-premise and cloud user store integration
- Easy onboarding via self-services
● SAP Cloud Platform Identity Access Governance
- Access analysis
- Role design
- Access certification
- Access requests

Identity and Access Governance in a Hybrid Landscape
Figure 82: Identity and Access Governance in a Hybrid Landscape
In a hybrid landscape, SAP IdM plays a very important role, being the on-premise user store
which controls and triggers all provisioning operations for cloud and non-cloud systems. In
combination with on-premise SAP Access Control and the cloud IAG product, it offers a full
range of security services needed for an advanced Identity and Access Management solution.
LESSON SUMMARY

Unit 8
Learning Assessment
1. What are common use cases for the Virtual Directory Server?
X A SAP HCM integration
X B LDAP Gateway for SAP Identity Store
X C SAP IdM Gateway for the cloud
X D SAP GRC Access Control integration
2. What is the purpose of the attributes MX_ENCRYPTED_PASSWORD and

MX_PASSWORD?
X A They are used to store the user password in SAP IdM
X B They are used for password provisioning
X C They are used only in productive password setup
X D They are temporary attributes, which are deleted after password provisioning
3. Which software products can be used to create IdM reports?

X A SAP IdM
X B SAP Lumira
X C SAP ASE
X D SAP BW

4. Where can you enable entry traces for a particular identity?

X A From the admin UI
X B From the standard UI
X C From the developer studio
X D From the NetWeaver Administrator panel
5. What are some of the common housekeeping procedures?

X A Delete old log entries
X B Reconcile dirty entries
X C Check for pending values and expired attributes
X D Initiate attestation
6. Which SAP product in the cloud allows provisioning to SAP cloud applications?
X A SAP Cloud Platform Identity Authentication
X B SAP Cloud Platform Identity Provisioning
X C SAP Cloud Platform Destination Service
X D SAP Cloud Connector

Unit 8
1. What are common use cases for the Virtual Directory Server?
X A SAP HCM integration
X B LDAP Gateway for SAP Identity Store
X C SAP IdM Gateway for the cloud
X D SAP GRC Access Control integration
Correct. SAP HCM integration, LDAP Gateway for SAP Identity Store, and SAP GRC
Access Control integration are common use cases for the Virtual Directory Server.
2. What is the purpose of the attributes MX_ENCRYPTED_PASSWORD and

MX_PASSWORD?
X A They are used to store the user password in SAP IdM
X B They are used for password provisioning
X C They are used only in productive password setup
X D They are temporary attributes, which are deleted after password provisioning
Correct. These attributes are used to store the user password in SAP IdM and for
password provisioning.
3. Which software products can be used to create IdM reports?

X A SAP IdM
X B SAP Lumira
X C SAP ASE
X D SAP BW
Correct. SAP IdM, SAP Lumira, and SAP BW can be used to create IdM reports.

4. Where can you enable entry traces for a particular identity?

X A From the admin UI
X B From the standard UI
X C From the developer studio
X D From the NetWeaver Administrator panel
Correct. You can enable entry traces for a particular identity from the admin UI.
5. What are some of the common housekeeping procedures?

X A Delete old log entries
X B Reconcile dirty entries
X C Check for pending values and expired attributes
X D Initiate attestation
Correct. These are all common housekeeping procedures.
6. Which SAP product in the cloud allows provisioning to SAP cloud applications?
X A SAP Cloud Platform Identity Authentication
X B SAP Cloud Platform Identity Provisioning
X C SAP Cloud Platform Destination Service
X D SAP Cloud Connector
Correct. SAP Cloud Platform Identity Provisioning allows provisioning to SAP cloud
applications.

Adm - Idm 920

Uploaded by

Copyright:

Available Formats

Adm - Idm 920

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Adm - Idm 920

Uploaded by

Copyright:

Available Formats

ADM920

SAP Identity Management (SAP

© 2022 SAP SE or an SAP affiliate company. All rights reserved.

American English is the standard used in this handbook.

This information is displayed in the instructor’s presentation

Related or Additional Information

User interface control Example text

Window title Example text

© Copyright. All rights reserved. iii

vii Course Overview

1 Unit 1: SAP Identity Management (SAP IdM)

3 Lesson: Describing SAP Identity Management

39 Lesson: Creating Forms

55 Lesson: Creating Jobs

73 Unit 4: SAP IdM Connections to Other Systems

75 Lesson: Connecting to SAP S/4HANA On-Premise

85 Unit 5: Privileges, Business Roles, and Dynamic Groups

87 Lesson: Assigning Privileges

111 Unit 6: SAP IdM Processes and Workflows

113 Lesson: Creating Processes

© Copyright. All rights reserved. v

137 Lesson: Defining Context

159 Unit 8: Advanced SAP IdM Topics

161 Lesson: Configuring the Virtual Directory Server (VDS)

vi © Copyright. All rights reserved.

© Copyright. All rights reserved. vii

● Explain the main purpose and functionalities of SAP Identity Management

© Copyright. All rights reserved. 1

2 © Copyright. All rights reserved.

SAP Identity Management (IdM) Positioning

Figure 1: SAP Portfolio

© Copyright. All rights reserved. 3

- Confirming valid assignments (attestation)

Main Challenges and Business Drivers

Figure 2: Business Drivers

Enterprise landscapes tend to be heterogeneous by nature, which could lead to scenarios

Figure 3: Identity Lifecycle

4 © Copyright. All rights reserved.

● Maintaining identity data

High Complexity Challenges

© Copyright. All rights reserved. 5

● Difficult or impossible to obtain an overview of all employees:

Security Risk Challenges

● Employees leaving the organization

High Maintenance Cost Challenges

● Many manual operations

6 © Copyright. All rights reserved.

● SOX - Sarbanes-Oxley Act

SAP Identity Management: Solution Overview

Figure 4: Solution in a Nutshell

● Central management of identities throughout the system landscape

Central Identity Store

© Copyright. All rights reserved. 7

Figure 5: IdM Functional Components

8 © Copyright. All rights reserved.

Components of SAP Identity Management

Figure 6: SAP Identity Management Components Overview

© Copyright. All rights reserved. 9

Figure 7: SAP Identity Management Core Components