master account privilege in contextbased assignments

[former_member239804]

Hi,

I'm currently running into an issue where account privileges get assigned multiple times which triggers multiple notification mails for the same account, although it was already assigned & created the first time.

The situation is that we include master account privileges inside the roles along with the regular privileges.

The roles can only be assigned with a context, which will determine wich privileges should be assigned along with the master account privilege that should always be assigned.

For this reason the master account privilege also has the MX_CTX_TYPE attribute set for it being assigned as part of the role.

If we add multiple contextbased role-assignments (for roles including the same master account privilege) to the same person it will result in the master account privilege being assigned multiple times, each time with the specific context given for each assignment.

What would be the most standard way of solving this?

We're running IdM 7.2 SP5 with SAP provisioning framework.

In the picture below you can see what the UI shows in MX_ASSIGNMENT.

In this case I've assigned the same role twice with another context, this would represent someone having a teamlead role for two different departments.

Hope this illustration helps.

Regards,

Wim.

[former_member239804 · Accepted solution]

For those wondering what the outcome is:

I decided to use the repository settings to automatically assign master account privileges. (screenshot added below)

R, Wim.

[Former Member · Accepted solution]

Hi Wim,

Have you tested an assignment of a role with multiple privileges from the same repository. If yes - how many times was the "no master task" triggered? Was it only once because of "grouping" settings?

Regards

Rytis

[former_member239804 · Accepted solution]

Hi Rytis,

I think I know the issue you are reffering to.

The master task was indeed triggered multiple times.

I didn't investigate it to the bottom, but my interpretation is that the master task is triggered every time when a privilege for that repository is assigned and the master privilege isn't completely assigned/provisioned yet.

In the end the status of all is what you want it to be, but perhaps a bunch of unnecessary processing has taken place for the master privilege.

The latter typically when assigning multiple privileges of the same repository at the same time.

About grouping, I didn't change any settings after creating ABAP repositories from the standard templates.

In addition to this during the process of investigating I added a conditional task in the beginning of the master task to assign the master privilege only once.

This only has the advantage that the logs don't fill up with multiple entries for assigning the same master privilege.

In the audit trail you can still find that the conditional task is run through multiple times.

I don't exactly remember all details but that should be about it.

Should you have a specific query, I don't mind looking it up in our setup.

Or if you have other insights, I would like to hear them.

Regards,

Wim.

[former_member2987]

Wim,

Take a look at this thread:

http://scn.sap.com/thread/1936476

Regards,

Matt

[former_member239804]

Matt,

thanks for your reply.

I also saw that thread, but in my opinion this is more in the make-it-custom department. (create task and link to every not-master-privilege)

It sure is an option I will keep in mind, but I hope to hear that there is something more standard.

I expect that even more since we're only using everything standard/basic.

I kind of hope to hear that I should enable something to make it work.

The drawback of the scenario described in this thread for me is:

1. it's not possible to create accounts without assignments nor preserve assignments and delete the account and reinstate account with assignments afterwards.
2. the account privilege will always be assigned/provisioned if a privilege is assigned, hence the account privilege is just a technical thing which has no meaning left to show in the interface nor assign separately nor add in any rolemodel.

Besides the fact that you would or would not want/need those things.

I think it's clear and clean to have an account as privilege which offers the most flexibility to any desired implementation.

Regards,

Wim.