Difference of Source Tab of To_Identity_Store Pass in Job and Action Task

[former_member431321]

Hi all,

The source tab of some Passes like to-identity-store or to-database is different when it is in Job and Action Task.

Can anyone tell me why it is?

<Source Tab in To Identity Store in a Job>

<Source Tab in To Identity Store in a Action Task>

********************************************************************************************

Below is my situation.

********************************************************************************************

One of customer requirement is as follows;

When an employee change his/her team, business role for old team will revoked and business role for new team will be assigned. When this happen, customer want to delete all direct assigned privileges from ERP, BI and SSM system.

So I could write a sql to select required privileges as follows;

SELECT MCASSIGNEDDIRECT, MCTHISMSKEYVALUE, MCOTHERMSKEYVALUE from idmv_link_ext where MCTHISMSKEYVALUE = '12219044' AND mcassigneddirect =1 AND (MCOTHERMSKEYVALUE LIKE '%ROLE:ERPDEV%' OR MCOTHERMSKEYVALUE LIKE '%ROLE:BIDEV%');

t will give result like this

<this user have 2 direct assigned privs only for BI>

So what I thought is to create a process and link the process as a event process of Modify Attribute Process of MX_FS_OGRANIZATIONAL_UNIT_ID.

But because this <To Identity Store> pass have different style that .. I am stuck.

...

Can any one help this?

Any comment welcome.

regards

dongsu

[former_member431321]

Hi Arterm,

in our environment, {D}<PRIV:ROLE:BIDEV:206010>|<PRIV:ROLE:BIDEV:ZCQG_EIS_052>

works.

thank you.

dongsu

[alexanderbrietz · Accepted solution]

Hi Dongsu,

the difference between normal jobs and jobs as part of an action task is part of SAP IdM and has been there at least with 7.2 also.

With jobs you need to select the source of objects that is being processed on destination.

With action task jobs the source is already defined because there is always a single object being processed. Therefor there is no need to select a source. It's either a commonly used object like MX_PERSON or a pending value (MX_PENDING_VALUE) with a reference to the original object.

To achieve the above mentioned action I would recommend to use a script and use the MSKEYVALUE of the processed object to generate the required result. For example you can return the MSKEYs of the directly assigned privileges and use them in the destination of your toIS-Pass with MXREF_MX:PRIVILEGE = {D}$FUNCTION.your_script(%MSKEYVALUE%)$$. Please test this thoroughly to avoid unwanted effects! E.g. when your script returns empty value (""), all privileges will be deprovisioned! If no value is found you need to return NULLATTR to avoid unwanted deprovisioning.

HTH

Regards,

Alex

[former_member431321 · Accepted solution]

Hi

Thank you very much.

We created the pass like below.

We found that the pass works when MXREF_ME_PRIVILEGE = {D}<PRIV:ROLE:BIDEV:206010>|<PRIV:ROLE:BIDEV:ZCQG_EIS_052>

So we made script which return like <PRIV:ROLE:BIDEV:206010>|<PRIV:ROLE:BIDEV:ZCQG_EIS_052> as below.

Basically it works.

But some direct PRIVs are not deleted.

We found that PRIVs acquired from Initial Load job shows this behavior.

The Privs we assigned manually are deleted successfully.

When we delete the PRIVs manually in Web UI, it is deleted successfully.

I can not understand this behavior until now.

Do you have an idea on this?

regards,

dongsu

[alexanderbrietz · Accepted solution]

Hi Dongsu,

can you provide the result of an SQL query for the two different privileges? Just a plain select * from idmv_link_ext where mcthismskeyvalue = <PERSON> and mcothermskeyvalue = <PRIVILEGE>.

Are there pending values for these persons in your system? Or anything other pending e.g. approval?

Regards,

Alex

[former_member431321 · Accepted solution]

Hi Alexander,

The difference between PRIVs deleted successfully or not is ValidFrom and ValidTo values.

When the PRIVs do not have ValidFrom and/or ValidTo values, it is deleted easily.

But when the PRIVs have ValidFrom and/or ValidTo values and we want to delete them through pass,

we have to specify the ValidFrom and ValidTo values as below.

{D}{ValidFrom=yyyy-mm-dd!!ValidTo=yyyy-mm-dd}<PRIV:ROLE:BIDEV:206010>|{ValidFrom=yyyy-mm-dd!ValidTo=}<PRIV:ROLE:BIDEV:ZCQG_EIS_052>

We modified script to handle it and it works now.

.

Thank you very much.

dongsu.

[Steffi_Warnecke · Accepted solution]

That issue with the valid dates is a bug I had my fun with at the beginning of the year, too. I created a workaround in the "Delete ABAP user" workflow to strip all privileges for that repository of the valid from/to dates, because otherwise the account could not be deleted, because the privileges could not be removed.

.

The fun never stops with IDM. ^^

.

Regards,

Steffi.

[devaprakash_b]

Hi Dongsu,

As mentioned in this post, you can remove the assignments by calculatng the directly assignmend privileges to user via script

[former_member431321]

Thank you very much Deva.

Do you have any idea on the additional problem I faced which I commented on Alexander's answer?

regards,

dongsu