Delete Role Assignments directly from an ABAP System

[former_member2987]

Hi folks!

I'm working on a synchronization job and I have a particular challenge, delete Roles assigned to a user in the ABAP System.

Our use case is this: IDM is regarded as the authoritative source and as such if the user has a privilege in IDM, it should be in the backend.  Easy enough!

However if the privilege is not in IDM but is in the back-end, it needs to be removed.  Is there a way to do this in IDM? From what I saw in the Framework, we are assuming that the role already exists in IDM.

I suppose the work around would be to assign and then remove the matching privilege in IDM, but I really don't like that at all, for a number of reasons.

I looked in the business suite and plain ABAP portions of the framework.  I'll take a more detailed look and also check the RDS, but I get the feeling this will be a toughie.

Thanks for your help!

Matt

[Former Member · Accepted solution]

Hi Matt ,

I believe new Internal Function "uIS_SetDirty" will resolve this issue . Please see documentation for this Internal Function below .

•   Sets a given entry "dirty" to be picked up by the scheduled procedure for reconciliation. This mechanism can be used for the entry types MX_PERSON, MX_PRIVILEGE, MX_ROLE, MX_GROUP, MX_DYNAMIC_GROUP.
• If an MX_PERSON entry is set dirty, this entry is marked dirty and all assignments will be reconciled. If an entry of one of the other (container) entry types is marked dirty, its member entries are marked dirty and will be reconciled.

If you find a user who has access in backend System (ABAP) but not in IDM , you can set that user to a Dirty Entry by using this Internal Function "uIS_SetDirty".

Please check whether this help ,

Thanks ,

Jerry George

[Former Member]

Hello Matt,

so you want to remove local administrated role?

If the object really is to undo the local administration, I would do this:

• Create a batch job, the passes would be a FromSAP, a ToGeneric and one/two ToSAP
• At first a cleaning pass (the ToGeneric one) which fixes all incorrect assigned privs (re-add directly or remove, depends on what you want/need). The source tab query and destination tab script have to be written though (I guess that is the most time consuming part of the job during implementation)
• The pending privs have to be considered in the provisioning script (I would prefer our own written script over the SAP delivered anytime)
• Copy the Read ABAP pass for users. Remove everything but the logonuid and the role assignments (profile assignments only if needed, too). Maybe use a different table name like sap<repName>userAssignRecon. If the system is very large, this pass has to be optimized filters
• Copy the role provisioning pass from the in-use plugin (SAP or adjusted one) and adjust it like this:
• Source tab query: A query which selects all mskeys of users that have more assigned in the sap table as in the link view. Using the Identity Store so everything of the identity is selected
• Destination tab: Remove the profiles as you haven't mentioned them. If needed I would do the same for profiles as for the roles in a second pass with the profileAssign table.

Best regards

Dominik

[former_member2987]

Dominik,

Interesting, nice total concept as it mirrors my sync design.  The issue is how do I remove the roles in the ABAP system assigned to a user that don't exist in IDM as corresponding privileges to the same user?

I'm hoping Jerry's idea of using the uPrivReconcile function will do the trick.

Matt

[former_member2987]

On further reflection, I don't think uPrivReconcile will work.  Consider the arguments for the function:

0: Reconcile only failed assignments.

1: Reconcile failed and declined assignments.

This does not cover my need, which is when they only exist in the back end.

ugh!

[Former Member]

Hi Matt,

internal function uIS_RepairEntry can be used for a mskey .

It would do reconciling and rebuilding of all assignments for this entry but for all repositories.

Regards,

Pradeep

[normann]

Hello Matt,

you can directly remove single roles if you use ToSAPIdentity instead of ToSAP. By doing that you can provision delta and thus also just remove single roles.

Only restriction is that ABAP system needs to be of certain version (Business Suite) - see note 1469551.

Regards

Norman

[Former Member]

Hi Matt ,

As part of the Sync Job if we find mismatches for the user , we can call an ADMIN type Job for synchronization . We can call the function uIS_PrivReconcile() or any reconcile internal functions to get the roles -> Back end system sync .

When ever we have a back end sync , system will sync user-> Role Relationship , with only problem being it will invoke sync for all repositories

Thanks ,

Jerry George

[former_member2987]

Jerry,

That makes the most sense.  I'll be looking into this in more detail, but I think it's the way to go.

Matt

[terovirta]

How do you find the mismatches in first place? In a job that you execute per each repository? Then you should have a list of valid privileges per the repository per user available readily from IdM and could send them to the backend. Similar to what the Plugin # 4 does for AS ABAP.

regards, Tero

[former_member2987]

Tero,

I looked at this and was concerned by the fact that the script was concerned with pending privileges.

Matt

[Steffi_Warnecke]

Hello Matt,

did I understand correctly: you have a user in IdM, who has an account in the ABAP backend. And you have assigned ABAP roles to this user via IdM. Now - for some reason - the user has more ABAP roles in the backend than he has in IdM. And now you want to remove those roles in the backend, that IdM knows nothing about for that user (so that he has the same roles in IdM and the backend). Is that right?

Why don't you just trigger the provisioning of the roles for that repository for those users? Since IdM will always send ALL roles of the user to the backend where the current roles will be unassigned and the send will be assign, it should be ok?

But maybe I don't understand what you're problem here is.

Regards,

Steffi.

[former_member2987]

Steffi, that's exactly the use case.  We have some very dirty data that we need to clean up.

Ongoing reconciliation allows us to make sure that only authorized changes (those done from IDM) are kept in the system and any direct back end changes are removed. I think solution will take care of this.

Thanks for your thoughts!

Matt