Additional Blogs by Members
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

Enforcing Data Ownership in SAP NW Identity Management

Former Member
‎08-14-2008 11:33 AM

The key of a central identity management is a consistent and "complete" data pool containing all necessary attributes, that are needed to control and support processes around the management of the relevant identites for a company.

This blog shows, how to maintain and enforce the ownership rules of identity attributes coming from various systems with SAP NetWeaver Identity Management.


The following systems / applications have been used in this blog
  • SAP NetWeaver Identity Management 7.0 SP02 Patch 2
  • MS SQL Server 2005 Database
Knowledge / experience in the following area(s) is helpful:
  • SAP NW Identity Management Knowledge
  • Basic SQL knowledge

Scenario description

The following picture gives an overview about the little scenario, that has been implemented for this blog to enable the system to enforce data ownership rules.


As one can see on the picture, we assume that we have four different repositories - three source and one target repository:

  • Source Repository: File based repository 1: REPFILE01
  • Source Repository: File based repository 2: REPFILE02
  • Source Repository: The Workflow component: REPWORKFLOW
  • Target Repository: File based repository 3: REP03TARGET

All four repositories have been created in the Management Section of the configured database in the Admin UI.



To make sure, that the workflow is assigned the created workflow repository, navigate to the workflow tab of the relevant identity store and select the created workflow repository from the drop down list. Only the repository, that have been created from a the workflow repository template are displayed in the drop down list:



As you can see in the Power Point Slide shown above, each of the three Source repositories have to be configured as a leading system for specific attributes:


  • REPWORKFLOW
    • Description
    • Displayname
    • Attribute 5
  • REPFILE01
    • Attribute 1
    • Attribute 2
  • REPFILE01:
    • Attribute 3
    • Attribute 4

    • Later on, we will synchronize data from all three repsoitories and observe the behaviour of the system.

    Configuration of Attribute Ownership

    The configuration of the mentioend attribute ownership has to be done in the attribute configuration dialog of your identity store. Therefore navigate to "Identity Store Schema" section of your identity store and select "Properties" from the context sensitive menu of the specific attribute.

    For the weblog, the following attributes have been created:

    • ISV_ATTRIBUTE1
    • ISV_ATTRIBUTE2
    • ISV_ATTRIBUTE3
    • ISV_ATTRIBUTE4
    • ISV_ATTRIBUTE5
    Additionally, the standard attributes DISPLAYNAME and DESCRIPTION have been used for this weblog


    In the attribute configuration dialog which opens now, navigate to the "General" tab and select the specific repository as "owner repository". Select "Silent Ignore" for "Conflict Handling" (For more information about the conflict handling please consult the help pages within in the Admin UI. Last but not least select "Log conflicts to system log". This results in log entries as soon as an attribute, which has already been set by a synchronization job of the owner repository, should be updated from a repository different from the defined owner repository).



    This step has to be repeated for all seven attributes, which are part of the scenario








    Prepare Data and configuration for scenario execution

    As described above, we work with three source repositories. For the two file repositories, we use CSV files on the local disk of the SAP NW IDM system. (If you need more information on how to configure the File repositories, please refer to the documentation or the several tutorials, which are provided with the installation of the SAP NW IDM system):

    REPFILE01

    MSKEYVALUE;DESCRIPTION;DISPLAYNAME;Attribute 1;Attribute 2;Attribute 3;Attribute 4;Attribute 5
    1;Test Entry 1 - SDN Blog on Data Ownership Rep 1;Test Entry 1 - Displayname;Repository 1 - Attribute 1 - Entry 1;Repository 1 - Attribute 2 - Entry 1;Repository 1 - Attribute 3 - Entry 1;Repository 1 - Attribute 4 - Entry 1;Repository 1 - Attribute 5 - Entry 1
    2;Test Entry 2 - SDN Blog on Data Ownership Rep 1;Test Entry 2 - Displayname;Repository 1 - Attribute 1 - Entry 2;Repository 1 - Attribute 2 - Entry 2;Repository 1 - Attribute 3 - Entry 2;Repository 1 - Attribute 4 - Entry 2;Repository 1 - Attribute 5 - Entry 2
    3;Test Entry 3 - SDN Blog on Data Ownership Rep 1;Test Entry 3 - Displayname;Repository 1 - Attribute 1 - Entry 3;Repository 1 - Attribute 2 - Entry 3;Repository 1 - Attribute 3 - Entry 3;Repository 1 - Attribute 4 - Entry 3;Repository 1 - Attribute 5 - Entry 3
    4;Test Entry 4 - SDN Blog on Data Ownership Rep 1;Test Entry 4 - Displayname;Repository 1 - Attribute 1 - Entry 4;Repository 1 - Attribute 2 - Entry 4;Repository 1 - Attribute 3 - Entry 4;Repository 1 - Attribute 4 - Entry 4;Repository 1 - Attribute 5 - Entry 4
    5;Test Entry 5 - SDN Blog on Data Ownership Rep 1;Test Entry 5 - Displayname;Repository 1 - Attribute 1 - Entry 5;Repository 1 - Attribute 2 - Entry 5;Repository 1 - Attribute 3 - Entry 5;Repository 1 - Attribute 4 - Entry 5;Repository 1 - Attribute 5 - Entry 5
    6;Test Entry 6 - SDN Blog on Data Ownership Rep 1;Test Entry 6 - Displayname;Repository 1 - Attribute 1 - Entry 6;Repository 1 - Attribute 2 - Entry 6;Repository 1 - Attribute 3 - Entry 6;Repository 1 - Attribute 4 - Entry 6;Repository 1 - Attribute 5 - Entry 6


    REPFILE02
    MSKEYVALUE;DESCRIPTION;DISPLAYNAME;Attribute 1;Attribute 2;Attribute 3;Attribute 4;Attribute 5
    3;Test Entry 3 - SDN Blog on Data Ownership Rep 2;Test Entry 3 - Displayname;Repository 2 - Attribute 1 - Entry 3;Repository 2 - Attribute 2 - Entry 3;Repository 2 - Attribute 3 - Entry 3;Repository 2 - Attribute 4 - Entry 3;Repository 2 - Attribute 5 - Entry 3
    4;Test Entry 4 - SDN Blog on Data Ownership Rep 2;Test Entry 4 - Displayname;Repository 2 - Attribute 1 - Entry 4;Repository 2 - Attribute 2 - Entry 4;Repository 2 - Attribute 3 - Entry 4;Repository 2 - Attribute 4 - Entry 4;Repository 2 - Attribute 5 - Entry 4
    5;Test Entry 5 - SDN Blog on Data Ownership Rep 2;Test Entry 5 - Displayname;Repository 2 - Attribute 1 - Entry 5;Repository 2 - Attribute 2 - Entry 5;Repository 2 - Attribute 3 - Entry 5;Repository 2 - Attribute 4 - Entry 5;Repository 2 - Attribute 5 - Entry 5
    6;Test Entry 6 - SDN Blog on Data Ownership Rep 2;Test Entry 6 - Displayname;Repository 2 - Attribute 1 - Entry 6;Repository 2 - Attribute 2 - Entry 6;Repository 2 - Attribute 3 - Entry 6;Repository 2 - Attribute 4 - Entry 6;Repository 2 - Attribute 5 - Entry 6
    7;Test Entry 7 - SDN Blog on Data Ownership Rep 2;Test Entry 7 - Displayname;Repository 2 - Attribute 1 - Entry 7;Repository 2 - Attribute 2 - Entry 7;Repository 2 - Attribute 3 - Entry 7;Repository 2 - Attribute 4 - Entry 7;Repository 2 - Attribute 5 - Entry 7
    8;Test Entry 8 - SDN Blog on Data Ownership Rep 2;Test Entry 8 - Displayname;Repository 2 - Attribute 1 - Entry 8;Repository 2 - Attribute 2 - Entry 8;Repository 2 - Attribute 3 - Entry 8;Repository 2 - Attribute 4 - Entry 8;Repository 2 - Attribute 5 - Entry 8

    For displaying the created entry type for modification in the workflow UI, create a web enabled task with the following settings. Please note, that none of the above described attributes of the scenario have the "Read-Only" flag set.



    In order to load the data from the given CSV files, you need to create specific jobs to load data from the files. If you want to load data from files autoamtically as soon as a file has changed, you need to create External Event Handlers (Event Agents and Services). Although we have set up the scenario using External Event Handlers, we only show the configuration of the jobs in ths weblog. Please refer to the documentation or tutorials for more information on configuring and activating External Event Handlers.


    The Job to load data from REPFILE01 contains two passes. The first pass reads the data from the CSV file into a temporary database table:





    The second pass reads the data from the temporary database table into the identity store. Please make sure, that you also specify the correct repository in the configuration of the second pass:




    Now you can repeat the steps for the creation of the Job and the two passes for the file repository REPFILE02.


    Scenario Execution

    Reset the content of the identity store at least for entries of the entry type you created for this scenario. In my case this was the entry type ISV_WEBINARCLASS. Afterwards, when you login to the workflow UI you should find no objects, when you navigate to the workflow task, that has been created in one of the above steps.




    Now execute the job, to load the data from REPFILE01. Afterwards, you should see 6 entries (Entry 1 - 6) in the workflow UI.



    If you select Entry 3 for example, you see, that you now can modify all attributes, except the ones, for which repository REPFILE01 has been defined as owner repository.



    Now execute the job, to load the data from REPFILE02. Afterwards, you should see 8 entries (Entry 1 - 😎 in the workflow UI, since entry 3 - 8 have been loaded from the second file repository now. Now in addition to attribute 1 and 2 als attribute 3 and 4 cannot be modified any more in the workflow, since now those attributes have been populated from the assigned owner repository.




    In addition you can observe, that the values of attributes 1 and 2 have not been changed by loading data from repository 2 since they already have been loaded from their owner repository.



    Now we modify the Displayname, the Description and Attribute 5 directly in the workflow UI



    Afterwards, please navigate to the CSV file for REPFILE01 and modify the file as follows ... REPFILE01 (New Version)

    MSKEYVALUE;DESCRIPTION;DISPLAYNAME;Attribute 1;Attribute 2;Attribute 3;Attribute 4;Attribute 5
    1;Test Entry 1 - SDN Blog on Data Ownership Rep 1;Test Entry 1 - Displayname;Repository 1 - Attribute 1 - Entry 1;Repository 1 - Attribute 2 - Entry 1;Repository 1 - Attribute 3 - Entry 1;Repository 1 - Attribute 4 - Entry 1;Repository 1 - Attribute 5 - Entry 1
    2;Test Entry 2 - SDN Blog on Data Ownership Rep 1;Test Entry 2 - Displayname;Repository 1 - Attribute 1 - Entry 2;Repository 1 - Attribute 2 - Entry 2;Repository 1 - Attribute 3 - Entry 2;Repository 1 - Attribute 4 - Entry 2;Repository 1 - Attribute 5 - Entry 2
    3;Test Entry 3 - SDN Blog on Data Ownership Rep 1 - MODIFIED!!!;Test Entry 3 - Displayname - MODIFIED!!!;Repository 1 - Attribute 1 - Entry 3 - MODIFIED!!!;Repository 1 - Attribute 2 - Entry 3 - MODIFIED!!!;Repository 1 - Attribute 3 - Entry 3 - MODIFIED!!!;Repository 1 - Attribute 4 - Entry 3 - MODIFIED!!!;Repository 1 - Attribute 5 - Entry 3 - MODIFIED!!!
    4;Test Entry 4 - SDN Blog on Data Ownership Rep 1;Test Entry 4 - Displayname;Repository 1 - Attribute 1 - Entry 4;Repository 1 - Attribute 2 - Entry 4;Repository 1 - Attribute 3 - Entry 4;Repository 1 - Attribute 4 - Entry 4;Repository 1 - Attribute 5 - Entry 4
    5;Test Entry 5 - SDN Blog on Data Ownership Rep 1;Test Entry 5 - Displayname;Repository 1 - Attribute 1 - Entry 5;Repository 1 - Attribute 2 - Entry 5;Repository 1 - Attribute 3 - Entry 5;Repository 1 - Attribute 4 - Entry 5;Repository 1 - Attribute 5 - Entry 5
    6;Test Entry 6 - SDN Blog on Data Ownership Rep 1;Test Entry 6 - Displayname;Repository 1 - Attribute 1 - Entry 6;Repository 1 - Attribute 2 - Entry 6;Repository 1 - Attribute 3 - Entry 6;Repository 1 - Attribute 4 - Entry 6;Repository 1 - Attribute 5 - Entry 6


    ... and afterwards execute the job to load the File assigned to repository 1 again. You should see the following result now:

    • Displayname, Description and Attribute 5 have still the values given in the workflow UI
    • Attribute 3 and Attribute 4 did not change and still have the values from file assigned to repositor 2
    • Only Attribute 1 and Attribute 2 got updated with the changed values of the file assigned to repositor 1


    Summary

    This example showed, how it is possible to enforce Data Ownership on an attribute level within the identity center when synchronizing data from different sources which contain the same type of information.

    Popular Blog Posts