how to reconcile identity data

7/31/2019 How to Reconcile Identity Data

1/71

SAP NetWeaver

How-To Guide

How to... Reconcile Identity Data

Applicable Releases:

SAP NetWeaver Identity Management 7.1

Topic Area:

Security and Identity Management

Capability:

Identity and Access Management

Version 1.0

April 2010


2/71


3/71

Document History

Document Version Description

1.00 First official release of this guide


4/71

Typographic Conventions

Type Style Description

Example Text Words or characters quotedfrom the screen. These

include field names, screen

titles, pushbuttons labels,

menu names, menu paths,

and menu options.

Cross-references to other

documentation

Example text Emphasized words or

phrases in body text, graphic

titles, and table titles

Example text File and directory names and

their paths, messages,

names of variables and

parameters, source text, and

names of installation,

upgrade and database tools.

Example text User entry texts. These are

words or characters that you

enter in the system exactly as

they appear in the

documentation.

Variable user entry. Angle

brackets indicate that you

replace these words and

characters with appropriate

entries to make entries in the

system.

EXAMPLE TEXT Keys on the keyboard, for

example, F2 or ENTER.

Icons

Icon Description

CautionNote or Important

Example

Recommendation or Tip


5/71

Table of Contents

1. Business Scenario............................................................................................................... 12. Background Information ..................................................................................................... 13. Prerequisites ........................................................................................................................ 14. Reconciliation ...................................................................................................................... 2

4.1 Reconciliation Overview ............................................................................................... 24.2 Technical Details of Reconciliation Procedure ............................................................. 3

4.2.1 Sample Reconciliation Job............................................................................... 34.2.1.1 ReadLocalJavaUsersFromSource ......................................... 34.2.1.2 ReadLocalJavaUsersFromIdS ............................................... 54.2.1.3 LocalJavaUsersMissingInIdS ................................................. 74.2.1.4 LocalJavaUsersMissingInBackend......................................... 84.2.1.5 LocalJavaUsersDifferent ........................................................ 9

4.2.2 Limitations of the Sample Job ........................................................................ 104.3 Extended Reconciliation Jobs .................................................................................... 11

4.3.1 Extended Reconciliation for AS ABAP ........................................................... 124.3.1.1 BeginHTML ........................................................................... 144.3.1.2 ReadABAPUsersFromSource .............................................. 154.3.1.3 CreateDelta_ABAPUsers ..................................................... 164.3.1.4 ReadABAPUsersFromIdS .................................................... 184.3.1.5 User Inconsistencies ............................................................ 194.3.1.6 CreateDelta_UserToRolePrivilegeAssignment .................... 264.3.1.7 ReadABAPRoleAssignmentsFromIdS ................................. 294.3.1.8 Role Assignment Inconsistencies......................................... 314.3.1.9 CreateDelta_UserToProfilePrivilegeAssignments ................ 354.3.1.10 ReadABAPProfileAssignmentsFromIdS .............................. 374.3.1.11 Profile Assignment Inconsistencies ...................................... 39

4.3.2 Extended Reconciliation for AS Java ............................................................. 434.3.2.1 BeginHTML ........................................................................... 444.3.2.2 ReadLocalJavaUsersFromSource ....................................... 454.3.2.3 ReadLocalJavaUsersFromIdS ............................................. 464.3.2.4 User Inconsistencies ............................................................ 474.3.2.5 ReadJavaRolesAndAssignments ......................................... 554.3.2.6

CreateDelta_UserToRolePrivilegeAssignment .................... 56

4.3.2.7 ReadJavaRoleAssignmentsFromIdS ................................... 58


6/71

4.3.2.8 Role Assignment Inconsistencies......................................... 594.3.3 Other systems ................................................................................................ 63

5. Report Examples ............................................................................................................... 645.1 AS ABAP .................................................................................................................... 645.2 AS Java ...................................................................................................................... 64


7/71

How to Reconcile Identity Data

April 2010 1

1. Business Scenario

SAP NetWeaver Identity Management is used to consolidate identity data which is typically spread

across various systems. With the Identity Center component a central storage the so called identity

store - is available which holds all identity information in one central place. This enables you to use

this data for reporting and auditing purposes as well as identity source of truth for the systems in your

landscape.

Typically administration in the various connected systems continues to some extent for data which

actually should be managed by the Identity Management system, e.g. role assignments. This leads to

potential data inconsistencies of the identity store and the (backend) system data. The process of

identifying the inconsistencies as well as cleaning them up is referred to as reconciliation.

Besides that, the reconciliation process can also be used to identify inconsistencies between the

identity store and a system which is to be connected to the identity management landscape in the

future. In this case only the inconsistencies will be identified without cleaning them up. The report

which is created will reveal how big the differences between the systems are with respect to themanaged data.

2. Background Information

SAP NetWeaver Identity Management 7.1 comes with a job template for reconciliation which is called

AS Java (LDAP) - Reconciliation. Thisjob and its implementation concept will serve as the

foundation for the reconciliation procedure described in this guide.

3. PrerequisitesThis guide is suitable for SAP NetWeaver Identity Management 7.1.

It is assumed that you are familiar with the basic concepts of the Identity Center component of SAP

NetWeaver Identity Management as well as the provisioning framework provided with it.

You find further background information here:

Identity Management homepage on SDN

http://www.sdn.sap.com/irj/sdn/nw-identitymanagement

Central Note for SAP NetWeaver Identity Management 7.1

https://service.sap.com/sap/support/notes/1253778

Additional Materials file(ZIP 15 KB)
http://www.sdn.sap.com/irj/sdn/nw-identitymanagementhttp://www.sdn.sap.com/irj/sdn/nw-identitymanagementhttps://service.sap.com/sap/support/notes/1253778https://service.sap.com/sap/support/notes/1253778http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/d0711705-8323-2d10-31a2-e9de2a8aee24http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/d0711705-8323-2d10-31a2-e9de2a8aee24http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/d0711705-8323-2d10-31a2-e9de2a8aee24https://service.sap.com/sap/support/notes/1253778http://www.sdn.sap.com/irj/sdn/nw-identitymanagement


8/71


April 2010 2

4. Reconciliation

In this chapter you will first get an overview about the reconciliation process before you learn about

technical details of implementing the procedure.

4.1 Reconciliation Overview

A reconciliation process comprises the following steps

Read the relevant information from the source/target system

Read the relevant information from the identity store

Compare the information and calculate the differences

Based on the identified differences perform defined actions

Typical information which is read from the systems are user attributes and assignment of permissions

(Roles, etc.)

The actions which should be taken range from pure documentation to automatic clean-up of the

inconsistencies.

In this guide we focus on how to find out the differences and create a report containing the relevant

information. This could then be used by an administrator to trigger a process to clean up the

inconsistencies. If an automatic procedure is required it will be straightforward to create clean-up tasks

which perform the desired actions based on the inconsistencies found by the process.

The reconciliation process involves reading of a potentially very large amount of data since all relevant

information in all connected systems needs to be compared with the data in the central Identity Store.

The frequency of executing this process should therefore be handled with care. Typically a frequency

of 1 execution per month should be sufficient.


9/71


April 2010 3

4.2 Technical Details of Reconciliation Procedure

The reconciliation process as depicted here makes heavy use of the delta mechanism in the Identity

Center component. This helps to reduce the DB writing operations to a minimum.

4.2.1 Sample Reconciliation Job

The Identity Center comes with a sample reconciliation job template which we use for creating more

advanced reconciliation functionality. It is called AS Java (LDAP) Reconciliation.

4.2.1.1 ReadLocalJavaUsersFromSource

This pass reads the user information from the local AS Java users (UME PRIVATE_DATASOURCE)

using the FromSPML connector.


10/71


April 2010 4

The destination tab shows only a subset of attributes as active. Here only those attributes should be

activated (not commented) which are considered relevant for the reconciliation process.

Important

Make sure that the attribute names, the order as well as the format of the attribute valuescorresponds to the task which reads the same information from the Identity Store(ReadLocalJavaUsersFromIdS)

On the delta tab the checkbox for Generate delta onlyis activated. This means that the data which is

read from the AS Java is not written to the temporary table as configured on the Destinationtab but

rather only considered for the delta creation. The delta creation involves the calculation of a fingerprint

which takes all the active attributes configured on the Destinationtab into account. This fingerprint is

written into the table Logentriesand will be used when identifying missing objects as well as

differences.


11/71


12/71


April 2010 6

Also on the delta tab the checkbox for Generate delta onlyis activated. This means as for the pass

ReadLocalJavaUsersFromSourcethat the data which is read from the Identity Store is not written to

the temporary table as configured on the Destinationtab but rather only considered for the delta

creation and therefore the fingerprint calculation which is written into the table Logentries.


13/71


April 2010 7

4.2.1.3 LocalJavaUsersMissingInIdS

This pass uses a SQL statement to identify the users which exist inside the AS Java system but not in

the Identity Store.

The SQL statement essentially reads all entries from the Logentriestable which belong to either the

Identity Store or the AS Java system and in this result set it identifies the items which only exist for the

AS Java system.

On the Destinationtab a filename is configured where all the found entries are written.


14/71


April 2010 8

4.2.1.4 LocalJavaUsersMissingInBackend

Similar to the pass LocalJavaUsersMissingInIdS, this pass uses a SQL statement to identify the users

which exist inside the Identity Store but not in the AS Java system.

Again, On the Destinationtab a filename is configured where all the found entries are written.


15/71


April 2010 9

4.2.1.5 LocalJavaUsersDifferent

This pass uses a SQL statement to identify all users which exist in both the AS Java system as well as

the Identity Store but differ on an attribute level.

This SQL statement again reads from the Logentries table and selects all entries which exist in both

systems but with a different fingerprint. This indicates that the attribute values are different within the

systems.

On the Destinationtab a filename is configured where all the found entries are written.


16/71


April 2010 10

4.2.2 Limitations of the Sample Job

The described sample job provides a very good basis for reconciliation jobs. Especially the provided

SQL statements for finding the differences based on information in the Logentriestable provide a solidfoundation for any reconciliation process.

Nonetheless there are some things missing:

Differences in role/permission assignments

Reconciliation for e.g. AS ABAP, LDAP directories

Detailed reports about the actual attribute differences

This can be achieved very easily based on the provided sample report and the procedure will be

described in the remainder of this guide.


17/71


April 2010 11

4.3 Extended Reconciliation Jobs

As described above, reconciliation is typically a scheduled activity which runs e.g. once per month.

This is in order to identify possible inconsistencies across various backend systems. Based on thedifferences identified, responsible people are informed and potentially a defined cleanup process is

started.

This chapter explains extended reconciliation jobs for AS ABAP as well as for AS Java (connected to

an LDAP directory). You candownload(ZIP 15 KB) the examples to this guide.

In order to use them extract the archive to a folder on your disk. Then browse to any of your job

folders in the Identity Management MMC, choose NewRun job wizard and then select one of the

extracted job templates.
http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/d0711705-8323-2d10-31a2-e9de2a8aee24http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/d0711705-8323-2d10-31a2-e9de2a8aee24http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/d0711705-8323-2d10-31a2-e9de2a8aee24http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/d0711705-8323-2d10-31a2-e9de2a8aee24


18/71


April 2010 12

4.3.1 Extended Reconciliation for AS ABAP

The example reconciliation job for AS ABAP as described in this chapter and provided together with

this guide will identify user differences between the central Identity Store and the AS ABAP system aswell as differences in role and profile assignments. These differences will be written into an HTML

report which could be sent to the responsible people.

Note

Instead of writing the information to a report the found inconsistencies could also be usedfor kicking off automatic cleanup tasks. This can easily be done by

a.) Replacing the toASCIIpasses which are used to writing the inconsistencies to a filewith e.g. a toSAPpass which immediately overwrites the information in AS ABAP withthe information from the Identity Store.

b.) Using a toGenericpass which kicks off a provisioning task for the user (similar to the

Initial Provisioningjobs) by calling the function sap_provisionUser.

The procedure is similar to the one in the sample job and consists of following steps:...

1. Read user information from AS ABAP

2. Create delta information for AS ABAP users

3. Read user information from Identity Store

4. Calculate user inconsistencies (i.e. missing users, different attributes)

5. Create delta information for AS ABAP role assignments

6. Read AS ABAP role assignments from Identity Store

7. Calculate role assignment inconsistencies (i.e. missing/unexpected assignments)

8. Create delta information for AS ABAP profile assignments

9. Read AS ABAP profile assignments from Identity Store

10. Calculate profile assignment inconsistencies (i.e. missing/unexpected assignments)

In addition to these steps the job also contains some passes which are responsible for the HTML

layout of the report which will be generated.


19/71


April 2010 13


20/71


April 2010 14

4.3.1.1 BeginHTML

The first pass in this job initializes the HTML file which will serve as reconciliation report. The pass will

create a new file with a name consisting of the AS ABAP repository as well as a timestamp. It will write

the HTML header including some style information.


21/71


April 2010 15

4.3.1.2 ReadABAPUsersFromSource

This pass reads the information from the AS ABAP system using a FromSAPpass. In case of using

the Business Suite Integration scenario the procedure is the same except that the pass

FromSAPIdentityneeds to be used instead since this will retrieve additional information through the

BADI interface on the AS ABAP.

In this example only logonId, first name, last name, e-mail address as well as the assignments are

retrieved from the AS ABAP system.

Note

You have to adapt the attribute list according to your requirements. Attributes whichshould be part of a consistency check should be added here.

Important

Please make sure that you keep the number of attributes as low as possible in order to

ensure usability of the generated reports. In addition the number of attributes will have aperformance impact since it influences the amount of data written to the temporarydatabase tables as well as to the Logentriestable.

This pass does not have any Deltaconfiguration which is a slight difference to the example job

described above. For AS ABAP role assignments are always retrieved through the user objects and

stored in a sub-table during the load. This means we cannot easily use the delta mechanism for

storing the delta on role and profile assignments as we require later on. In addition we want to avoid

reading the same objects twice from AS ABAP within one reconciliation process.


22/71


April 2010 16

4.3.1.3 CreateDelta_ABAPUsers

This pass is responsible for creating the delta information for the user objects in AS ABAP.

The Sourceof this pass reaches out to the temporary database table which has been filled in theprevious pass.

It will retrieve the relevant user attributes (as in 4.3.1.2) and simulate a write to another database

table. The writing is only simulated due to the Delta configuration. Here the checkbox Generate delta

onlyis activated which results in this behavior.


23/71


April 2010 17

Important

The delta of the To Database pass does not take the first item into account. Thus thelogonuidappears in two lines.In addition please make sure that the attribute names, the order as well as the format ofthe attribute values correspond to the task which reads the same information from theIdentity Store (see 4.3.1.4).


24/71


April 2010 18

4.3.1.4 ReadABAPUsersFromIdS

In this pass the relevant user information is retrieved from the Identity Store. The writing to the

temporary database table is yet again simulated due to the enabled Generate delta onlyoption

Important

As described above, please make sure that the attribute names, the order as well as theformat of the attribute values corresponds to the task which reads the same informationfrom AS ABAP (see 4.3.1.3).


25/71


26/71


April 2010 20

On the Destinationtab you write the user Ids to the HTML file.

Middle1UserInconsistencies_htmlIn this pass you create some static HTML which closes the table for the users missing in the identity

store and opens a new table with a header for the users which are only available inside the Identity

Store.


27/71


28/71


29/71


30/71


31/71


April 2010 25

EndUserInconsistencies_html

With this pass we close the HTML table for the user inconsistencies.


32/71


April 2010 26

4.3.1.6 CreateDelta_UserToRolePrivilegeAssignment

Above we filled the delta database with information about users from Identity Store and AS ABAP.

Typically, the most important requirement for reconciliation jobs is to ensure that users do not have

unknown permissions in a target system. This could for example happen through manual

administration.

This pass retrieves the information from the temporary database table which has been written by the

pass ReadABAPUsersFromSource(see 4.3.1.2)

With this pass the role assignment information is also added to the delta database. You can use a

feature in the delta mechanism which allows you to use a combination of two attributes. This is done

by using the separator !! in the value of the first attribute.

In this case

%refid%!!$FUNCTION.getPrivilegeName(%$rep.$NAME%||ROLE||%roleAssignments%)$$

Where

%refid%: this is the user Id in the system

Function: The function retrieves the system-specific name of the role (the representation inside

the Identity Store contains an additional namespace which needs to be removed)

Here the code of the function:

// Main function: getPrivilegeName

function getPrivilegeName(Par){

// Par has following format:

// %$rep.$NAME%||||

// Input value contains time dependent assignment of a

user:

// {VALID_FROM=2007-12-01!!VALID_TO=2008-12-01}SAP_XI_ADMINISTRATOR


33/71


April 2010 27

// Output needs to be in format:

// PRIV:ROLE:NSP000:SAP_XI_ADMINISTRATOR in case role is aready

active

// or// PRIV:ROLE:NSP000:SAP_XI_ADMINISTRATOR (VALID_FROM=2007-12-01) in

case role is not active yet

var privilege;

var parameters = Par.split("||");

var repository = parameters[0];

var privilegeType = parameters[1];

var assignment = parameters[2];

if (assignment.charAt(0)== '{') {

var endTimeStr = assignment.indexOf("}");

if (endTimeStr != -1 ) {

privilege = "PRIV:" + privilegeType + ":"+ repository + ":" +

assignment.substring(endTimeStr+1);

var firstEqual = assignment.indexOf("=");

var startTimeString =

assignment.substring(firstEqual+1,endTimeStr-firstEqual-1);

var timeparts = startTimeString.split("-");

var startDate = new Date(timeparts[0],timeparts[1],timeparts[2]);

var now = new Date();

if (startDate > now) {

privilege = privilege + " (VALID_FROM=" + startTimeString +

")";

}

}

else {

UserFunc.uErrMsg(1,"invalid time pattern: " + assignment);

}

}

else {

UserFunc.uErrMsg(1,"invalid time pattern " + assignment);

}

return privilege;

}


34/71


35/71


April 2010 29

4.3.1.7 ReadABAPRoleAssignmentsFromIdS

This pass will write the assignment information as available inside the Identity Center into the delta

table.

On the Destinationtab two functions are used in order to fill the delta key properly. Both are separated

by !! in order to store the assignments correctly in the delta table:

getIdsAttributeFromMSKEY(): this function reads the value of a specified attribute from a

defined object. In this case we read the ACCOUNT attribute in order to have a proper matching

even when the MSKEYVALUE and the ACCOUNT attribute differ.

getMSKEYVALUEFromExtMSKEY: this function retrieves the MSKEYVALUE attribute out of the

value extmskey returned by the SQL query of this pass.

The extmskey has the format MSKEYVALUE (MSKEY)


36/71


April 2010 30

Yet again the option Generate delta onlyis activated. Therefore the temporary database table will not

be filled with information. Only the delta database will be filled.

Here the code of the two functions:

// Main function: getIdsAttributeFromMSKEY

function getIdsAttributeFromMSKEY(Par){

//Par in format ||AttributeName


var mskey = parameters[0];

//get attribute value

var attrValue = uIS_GetValue(mskey, 0, parameters[1]);

if (attrValue.indexOf("!ERROR") >= 0) attrValue = "n/a";

return attrValue;

}

// Main function: getMSKEYVALUEFromExtMSKEY

function getMSKEYVALUEFromExtMSKEY(Par){

var extMSKEY = Par.split(" ");

return extMSKEY[0];

}


37/71


April 2010 31

4.3.1.8 Role Assignment Inconsistencies

This set of passes calculates the differences concerning role assignments between AS ABAP and the

Identity Store.

BeginRoleAssignmentInconsistencies_html

With this pass we create the HTML header for the data about role inconsistencies.

ABAPRoleAssignmentsMissingInIdS_html

On the Sourcetab of this pass we use the SQL statement from above in order to find the role

assignments which are available inside the AS ABAP system but not reflected in the Identity Store.

It is essentially the same SQL statement as in the sample pass LocalJavaUsersMissingInIdS(see

4.2.1.3). You only need to adapt the names of the delta keys:

sapr1%$rep.$NAME%user sapr1%$rep.$NAME%ra


Other than that the SQL statement is identical

Note

As you can see here you can use the SQL statements as they are for various purposes.The only thing you need to ensure is that you use the correct delta keys.


38/71


April 2010 32

On the Destinationtab the identified information will be written into the HTML document. In order to

split the information in the delta key you have two functions available which come with the provisioning

framework for SAP systems.

sap_findPrimaryDeltaObject(): gets the first part of the delta (before the separating !!)

sap_findSecondaryDeltaObject():gets the second part of the delta (after the separating !!)


39/71


April 2010 33

MiddleRoleAssignmentInconsistencies_html

With this pass we close the table for the missing assignments inside the Identity Store and create the

HTML header for the table with the data about the missing role assignments in the AS ABAP system.

ABAPRoleAssignmentsMissingInBackend_html



It is essentially the same SQL statement as in the samle pass LocalJavaUsersMissingInBackend(see




Other than that the SQL statement is again identical


40/71


April 2010 34

On the Destinationtab the identified information will be written into the HTML document as above. In

order to split the information from the delta key you have two functions available which come with the

provisioning framework for SAP systems.




41/71


April 2010 35

4.3.1.9 CreateDelta_UserToProfilePrivilegeAssignments

Above we filled the delta database with information about users from Identity Store and AS ABAP.

This pass retrieves the information about ABAP profile assignments from the temporary databasetable which has been written by the pass ReadABAPUsersFromSource(see 4.3.1.2)

With this pass the profile assignment information is also added to the delta database. Here again the

feature is used which allows you to use a combination of two attributes as delta key. This is done byusing the separator !! in the value of the first attribute.

In this case %refid%!!$PRIV:PROFILE:%$rep.$NAME%:%profileAssignments%

Where %refid%: this is the user Id in the system and the second part is the MSKEYVALUE of the

profile inside the Identity Store.


42/71


April 2010 36

The screenshot of the Deltatab shows the delta key which consists of the user Id as well as the

assigned role with !! as separator. This will make sure that every assignment will be represented as a

separate entry in the delta database.


43/71


April 2010 37

4.3.1.10 ReadABAPProfileAssignmentsFromIdS

This pass will write the profile assignment information as available inside the Identity Center into the

delta table.










44/71


April 2010 38




45/71


April 2010 39

4.3.1.11 Profile Assignment Inconsistencies

This set of passes calculates the differences concerning profile assignments between AS ABAP and

the Identity Store.

BeginProfileAssignmentInconsistencies_html

With this pass we create the HTML header for the data about profile inconsistencies.

ABAPProfileAssignmentsMissingInIdS_html

On the Sourcetab of this pass we use the SQL statement from above in order to find the profile




sapr1%$rep.$NAME%user sapr1%$rep.$NAME%pa



Note



46/71


April 2010 40




sap_findPrimaryDeltaObject(): gets the first part of the delta (before the separating !!) sap_findSecondaryDeltaObject():gets the second part of the delta (after the separating !!)


47/71


April 2010 41

MiddleProfileAssignmentInconsistencies_html


HTML header for the table with the data about the missing profile assignments in the AS ABAP

system.

ABAPProfileAssignmentsMissingInBackend_html

On the Sourcetab of this pass we use the SQL statement from above in order to find the profile


It is essentially the same SQL statement as in the samle pass LocalJavaUsersMissingInBackend(see






48/71


April 2010 42






EndHTML

This pass finalizes the HTML document.


49/71


April 2010 43

4.3.2 Extended Reconciliation for AS Java

The example reconciliation job for AS Java as described in this chapter will identify user differences

between the central Identity Store and an AS Java system as well as differences in role assignments.These differences will be written into an HTML report which could be sent to the responsible people.

Note

Instead of writing the information to a report the found inconsistencies could also be usedfor kicking off automatic cleanup tasks. This can easily be done by

a.) Replacing the toASCIIpasses which are used to writing the inconsistencies to a filewith e.g. a toSPML pass which immediately overwrites the information in AS Java withthe information from the Identity Store.

b.) Using a toGenericpass which kicks off a provisioning task for the user (similar to theInitial Provisioningjobs) by calling the function sap_provisionUser.

The procedure is basically as in the sample job and consists of following steps:...

1. Read user information from AS Java

2. Read user information from Identity Store

3. Calculate user inconsistencies (i.e. missing users, different attributes)

4. Read AS Java role assignments

5. Create delta information for AS Java role assignments

6. Read AS Java role assignments from Identity Store

7. Calculate role assignment inconsistencies (i.e. missing/unexpected assignments)

In addition to these steps the job also contains some passes which are responsible for the HTML

layout of the report which will be generated.


50/71


51/71


April 2010 45

4.3.2.2 ReadLocalJavaUsersFromSource

This pass reads the user information from the AS Java system using a FromSPML pass.

In this example only logonid, first name, last name, and e-mail address are retrieved from the AS Javasystem.

Note

You have to adapt the attribute list according to your requirements. Attributes whichshould be part of a consistency check should be added here.

Important

Please make sure that you keep the number of attributes as low as possible in order toensure usability of the generated reports. In addition the number of attributes will have aperformance impact since it influences the amount of data written to the temporarydatabase tables as well as to the Logentriestable.

It will retrieve the relevant user attributes and simulate writing to another database table. The writing is

only simulated due to the Delta configuration. Here the checkbox Generate delta onlyis activated

which results in this behavior.


52/71


April 2010 46

4.3.2.3 ReadLocalJavaUsersFromIdS

In this pass the relevant user information is retrieved from the Identity Store. The writing to the

temporary database table is yet again simulated due to the enabled Generate delta onlyoption

Important

As described above, please make sure that the attribute names, the order as well as theformat of the attribute values corresponds to the task which reads the same informationfrom AS Java (see 4.3.2.2).


53/71


April 2010 47

4.3.2.4 User Inconsistencies

The next passes in the reconciliation job are about putting the identified inconsistencies into an HTML

report.

BeginUserInconsistencies_html

Here you create some static HTML which creates a table header.

LocalJavUsersMissingInIdS_html

This pass is similar to the pass LocalJavaUsersMissingInIdS(see 4.2.1.3) of the sample reconciliation

job.

On the Sourcetab use exactly the same SQL statement as the sample pass.


54/71


April 2010 48

On the Destinationtab you write the user Ids to the HTML file.

Middle1UserInconsistencies_html

In this pass you create some static HTML which closes the table for the users missing in the identity

store and opens a new table with a header for the users which are only available inside the Identity

Store.


55/71


April 2010 49

LocalJavaUsersMissingInBackend_html

This pass is similar to the pass LocalJavaUsersMissingInBackend(see 4.2.1.4) of the sample

reconciliation job.

On the Sourcetab use exactly the same SQL statement as the sample pass.

On the Destinationtab you write the user Ids as well as the MSKEYVALUE to the HTML file.

In order to get the MSKEYVALUE you need a simple function (getIdsAttributeFromAccount) which

retrieves the MSKEYVALUE attribute of a specific entry based on the value of the account attribute

(see above):


56/71


57/71


April 2010 51

On the Destinationtab we will not only write the user Id into the file but also a selected set of attributes

which will make it easier for the person looking at the report to identify the differences.

We will again use the function getIdsAttributeFromAccount from the previous pass. In addition

we require an additional function which in this example retrieves the attribute value via SPML from the

AS Java system.


58/71


April 2010 52

// Main function: getAttributesViaSPML

function getAttributesViaSPML(Par){

//Par in format ||AttributeName


var account = parameters[0];

var attrString = parameters[1];

var spmlUser = uGetConstant("rep.HTTP_AUTH_USER");

var spmlPwd = uGetConstant("rep.HTTP_AUTH_PWD");

var spmlProtocol = uGetConstant("rep.HTTP_PROTOCOL");

var spmlAppHost = uGetConstant("rep.APPLICATION_HOST");

var spmlPort = uGetConstant("rep.HTTP_PORT");

var spmlUrl = spmlProtocol + "://" + spmlAppHost + ":" + spmlPort +

"/spml/provisioning";

var myClient = new Packages.org.openspml.client.SpmlClient();

myClient.setUsername(spmlUser);

myClient.setPassword(spmlPwd);

myClient.setUrl(spmlUrl);

req = new Packages.org.openspml.message.SearchRequest();

req.setSearchBase("SAPprincipals");

var attrList = new java.util.Vector();

attrList = Packages.com.sap.idm.ic.Util.splitString(attrString, ",");

req.setAttributes(attrList);

var f = new Packages.org.openspml.message.Filter();

var ufTerm = new Packages.org.openspml.message.FilterTerm();

ufTerm.setName("logonname");

ufTerm.setOperation("equalityMatch");

ufTerm.setValue(account);

var ofTerm = new Packages.org.openspml.message.FilterTerm();

ofTerm.setName("objectclass");

ofTerm.setOperation("equalityMatch");

ofTerm.setValue("sapuser");


59/71


April 2010 53

var topfTerm = new Packages.org.openspml.message.FilterTerm();

topfTerm.addOperand(ufTerm);

topfTerm.addOperand(ofTerm);

topfTerm.setOperation("and");

f.addTerm(topfTerm);

req.setFilter(f);

var resp = new Packages.org.openspml.message.SearchResponse();

resp = myClient.searchRequest(req);

if (resp.isFailure()) {

uErrMsg(2, resp.getErrorMessage());

return "";

}

var results = new java.util.Vector();

results = resp.getResults();

var sres = new Packages.org.openspml.message.SearchResult();

sres = results.get(0);

var attributes = new java.util.Vector();

attributes = sres.getAttributes();

var aValue;

if (attributes == null) {

aValue = "n/a";

} else {

var attribute = new Packages.org.openspml.message.Attribute();

it = attributes.iterator();

while (it.hasNext()) {

attribute = it.next();

aValue = attribute.getValue();

}

}

return aValue;}


60/71


April 2010 54

EndUserInconsistencies_html

With this pass we close the HTML table for the user inconsistencies.


61/71


April 2010 55

4.3.2.5 ReadJavaRolesAndAssignments

This pass reads the roles from the AS Java system using a FromSPML pass and stores the role

assignment information in a sub-table.

This pass does not have any Deltaconfiguration. The delta will be created in the next pass.


62/71


April 2010 56

4.3.2.6 CreateDelta_UserToRolePrivilegeAssignment

This pass retrieves the role assignment information from the temporary database table which has

been written by the pass ReadJavaRolesAndAssignments(see 4.3.2.5)

With this pass the role assignment information is also added to the delta database. You can use again

the feature in the delta mechanism which allows you to use a combination of two attributes. This is

done by using the separator !! in the value of the first attribute.

In this case

$FUNCTION.sap_removeSPMLPrefix(%username%)$$!!$FUNCTION.replaceSPMLPrefixWithPrivileg

ePrefix(%refid%||%$rep.$NAME%)$$

Where

%username%: this is the SPML user Id in the AS Java system

%refid%: this is the role Id in the AS Java system

Function sap_removeSPMLPrefix: comes with the SAP Provisioning Framework.

Function replaceSPMLPrefixWithPrivilegePrefix: The function replaces the SPML prefix of the

role in the AS Java system with the Identity Store prefix.

Here the code of the function replaceSPMLPrefixWithPrivilegePrefix:

// Main function: replaceSPMLPrefixWithPrivilegePrefix

function replaceSPMLPrefixWithPrivilegePrefix(Par){


var replaceString = "PRIV:ROLE:" + parameters[1] + ":";

return parameters[0].replace(/SPML\.SAPROLE\./, replaceString);

}


63/71


April 2010 57

The screenshot of the Deltatab shows the delta key which consists of the MSKEYVALUE of the user

as well as the assigned role with !! as separator. This will make sure that every assignment will be

represented as a separate entry in the delta database.


64/71


April 2010 58

4.3.2.7 ReadJavaRoleAssignmentsFromIdS

This pass will write the assignment information as available inside the Identity Center into the delta

table.












65/71


April 2010 59

4.3.2.8 Role Assignment Inconsistencies

This set of passes calculates the differences concerning role assignments between AS Java and the

Identity Store.

BeginRoleAssignmentInconsistencies_html

With this pass we create the HTML header for the data about role inconsistencies.

JavaRoleAssignmentsMissingInIdS_html


assignments which are available inside the AS Java system but not reflected in the Identity Store.






Note



66/71


April 2010 60







67/71


April 2010 61

MiddleRoleInconsistencies_html


HTML header for the table with the data about the missing role assignments in the AS Java system.

JavaRoleAssignmentsMissingInBackend_html


assignments which are available inside the AS Java system but not reflected in the Identity Store.

It is essentially the same SQL statement as in the sample pass LocalJavaUsersMissingInBackend

(see 4.2.1.4). You only need to adapt the names of the delta keys:





68/71


April 2010 62






EndHTMLThis pass finalizes the HTML document.


69/71


April 2010 63

4.3.3 Other systems

The passes used in the two examples for AS ABAP as well as AS Java can be used as reconciliation

foundation also for other types of configurations as well as other types of systems.The approach of using the delta mechanism to identify differences based on the three variations of the

SQL query (as introduced above) can be used universally:

Identifying missing entries/assignments in Identity Store

Identify missing entries/assignments in backend system

Identifying entries which are different

There is no need to modify the queries. You only need to ensure that the delta information is correctly

filled.


70/71


April 2010 64

5. Report Examples

5.1 AS ABAP

5.2 AS Java


71/71

www.sdn.sap.com/irj/sdn/howtoguides

how to reconcile identity data

Documents