How is an object in the IC linked to the corresponding object in a target system?

[Former Member]

Hi,

I am new in SAP NW IDM and I try to understand some basic concepts. I haven't found anything when searching.

How does SAP NW IDM establish a link between objects in IC and objects in target / source systems?

From other IDM tools I am used the concept of storing a link, an ID, an association or whatever you name it of the target system objects in the identity store. This link, ID, association, etc. is used as an access key to the object in the target system for all further commands after creation like modify, rename, delete.

So I expect when creating an object in the target system on success the adapter returns a target system specific unique object identifier (e.g. for AD the GUID, for generic LDAP the FDN, for SAP USER the Username/Bapiname, etc.) which then is stored as the link, ID, association, etc.

I haven't seen this concept in SAP NW IDM neither by investigation the IC schema nor by finding something in other documentations.

Can someone explain how SAP NW IDM finds the right object in the target system to perform the commands and which attribute is used to store this link.

Thanks

Thomas

[Former Member · Accepted solution]

Hi Thomas

This is done using the dynamic schema (its not part of the default).  Whenever you add a connected system, the Initial Load process creates an attribute ACCOUNT<rep.Name> where rep.Name is the name of the system you just connected.  On a live system you might have:

ACCOUNTADDOMAIN

ACCOUNTLDAP

ACCOUNTECCPROD

ACCOUNTECCTEST

etc

By default, this stores the account name of the target system object.  You could, if you really wanted to, change it to store some other identified (like AD Guid) but it would involve some work on the provided provisioning framework to make sure it was all in sync.

Hope that helps

Peter

[Former Member]

Hi Thomas,

as discussed before, the account-specific attributes are written to the identity the way Peter described it. From my point of view this is the worst approach to do this, account-objects per target-system account would be a better solution: for each account there's a reference in the identity to the account-object. But unfortunately, the provisioning framework doesn't support this approach.

best regards

Matthias

[Former Member]

I have to check the dynamic schema stuff but the approach sounds weired to do this on an initial load. When I create a new Identity after initial load what's happening than?

Anyhow it seems to be possible to to this in the provisioning framework somehow so I will have to figure out. I would have assumed that the adapter will return some kind of unique idntifier becaus ethe adapter developer should know the target system and it's way to identify objects there. But for adapters I start another thread

Thanks

Thomas

[terovirta]

Thomas Liebeck wrote:
I have to check the dynamic schema stuff but the approach sounds weired to do this on an initial load. When I create a new Identity after initial load what's happening than?
Anyhow it seems to be possible to to this in the provisioning framework somehow so I will have to figure out. I would have assumed that the adapter will return some kind of unique idntifier becaus ethe adapter developer should know the target system and it's way to identify objects there. But for adapters I start another thread

When you create new identity after initial load and assign rights in IdM to be provisioned to the target system, the provisioning framework will create the user (and assign rights) to the target system, and mark the provisioning complete by assigning the account-attribute for the user.  Other actions take place in the product core stored procedures to maintain IdM's internal "book-keeping" that are not visible in MMC, the audits and maintaining the link table/views.

The provisioning process/workflow can be found in the folder "provisioning framework / core" and it is easy enough to understand and learn from.

The unique identifier by default is the MSKEYVALUE (unique id of any object/entry in IdM) and that is mapped to the what ever identifier field the target system has. The standard connectors (AS Java, AS ABAP and LDAP/AD) don't return anything that developer in MMC could access.

[terovirta]

Matthias Bartel wrote:
as discussed before, the account-specific attributes are written to the identity the way Peter described it. From my point of view this is the worst approach to do this, account-objects per target-system account would be a better solution: for each account there's a reference in the identity to the account-object. But unfortunately, the provisioning framework doesn't support this approach. 

The object would help, you could store stuff like

1) different passwords for each system

2) different mx_password disabled value for each system

3) easier way to setting the different validity period for each system than the account privilege validity period

4) different mx_disabled value for each system...

[Steffi_Warnecke]

Well, those points can be achieved by creating attributes for each of the repositories (e.g. mx_passworddisabled_rep1, mx_passworddisabled_rep2). So it is possible now, but with a little more work.

Regards,

Steffi.

[Former Member]

Hi Thomas,

You can refer to the SAP IDM Configuration Guide for more information.

Its helps to understand how SAP IDM connects (through Repository Constants) to target systems and how the attribute mappings can be done.

Also refer to Identity Store Schema - Technical reference for detailed information on the attributes. Which can be mapped to the target system based on your requirement.

But, the attribute mappings that come with the provisioing framework of SAP NW IDM are more than enough to start working with. You can enable/disable the attributes which you don't want to do provision to the target system.

All the best,

Thanks,

Krishna.