7.2 Context Based Provisioning

[Former Member]

Hi Folks,

I'm working with context based role assignment, new in 7.2 and I've completed the config I thought necessary and the behaviour I'm seeing is not what I expected.

Use case

We have users who are either in AD2003 or AD2008 as we are currently migrating from one to the other. The users and groups from both 2003 and 2008 are loaded through the standard AD load from AD2003 and AD2008, both of which are defined as repositories and so the groups exist as normal IdM privileges. If a user is in 2003, I should assign them groups in 2003, if a user is in 2008, I should assign them groups in 2008. We don't want to set up business roles for 2003 and business roles for 2008. So, what we would like to do is when we assign a business role and, based on an attribute of the user, only the appropriate privileges are provisioned.

Expected Solution

This sounds like an ideal use of context based provisioning - tag the AD2003 privileges with context "AD2003", tag the AD2008 privileges with context  "AD2008", then stick them both in the role. Tag the user with either the AD2003, or AD2008 context based on a job that reads which directory they are in. Then when we assign the role, IdM will see that the role has a context, compare the context on the user with the context on the privileges and only provision the necessary privilege! Alas it doesn't seem that simple. So my first question is, is this a valid use case for Context? Hopefully or will be able to answer that.

The next question is, if that is valid, where have I gone wrong in implementing it. So, what I've done is:

Define the context

I created a context "UEX_STATE" (It's the UEX project that is doing the migration) and I gave it 2 values "2003" and "2008".

Role

I've created a role and added to privileges as below.

ROLE:BUSINESS:HELP

     --> PRIV:GROUP:AD2003:Help-Access

     --> PRIV:GROUP:AD2008:Help-Access

I assigned the context type (MX_CTX_TYPE) of "UEX_STATE" to my Role ROLE:BUSINESS:HELP

Privileges

I assigned the context type (MX_CTX_TYPE) of UEX_STATE to both privileges (PRIV:GROUP:AD2003:Help-Access and PRIV:GROUP:AD2008:Help-Access)

I assigned the context value (MX_CTX_CONDITIONAL) of "2003" to PRIV:GROUP:AD2003:Help-Access

I assigned the context value (MX_CTX_CONDITIONAL) of "2008" to PRIV:GROUP:AD2008:Help-Access

I left the "Strategy for Auto-Assigned Contexts" to blank

Identity

On the identity I assigned the context value (MX_CTX_AUTO_VALUES) of "2003".

The Magic ... Or Not

I then assigned the business role in the normal UI task with the logic that the context is on the person and so I didn't need to use a context guided procedure.  What I found happened were both privileges were provisioned. This is what I would expected to happen, if the context did nothing, and hence my confusion.

So my question is, has anyone got this to work, and if so, what am I doing wrong?

Thanks in advance,

Ian

[Former Member · Accepted solution]

Hi,

It seems like you've got the roles and privileges configured correctly.  I've not used auto-assign contexts though.  What happens if you assign this role with a context based assignment task, does it work?

Regards,

Chris

[Former Member · Accepted solution]

Hi Chris,

Thanks for the response, I will try the assignment through a context task, where I assume I should try assigning with a context and without, as the user already has it?

Cheers,

Ian

[Former Member]

Hi Daniel,

This is confusing display issue that I'm facing also when I use context-based assignments on privileges with a Master Privilege defined.

"Conditionnal Assignments" with "If Missing" (on Privileges) are only well displayed into the WebUI right after you have the Master Privilege assigned.

Until Master Privilege is not assigned (as for Approvals steps), display socks and shows all privileges even if there have "conditionnal" defined on other contexts.

I hope SAP will correct this soon,

Ben

[Former Member]

Hi,

So, I did some simplification to the testing, and instead of having 1 privilege from each repository, I picked 2 privileges from AD2003, but flagged one as 2003 and one as 2008. I then followed Chris's advice, I removed the context from the person and did some testing with the Context Guided Task.

I found that the process worked fine with one oddity. Even though only the privilege with the correct context was provisioned, both privileges showed up in MXREF_MX_PRIVILEGE on the person record. I guess this is now because there is a status table behind the scenes to show that although it is there, it is not actually provisioned to the person.

Now I went back to testing the scenario I wanted, where the context is attached to the user and  I changed each of the privileges "Strategy for Auto-Assigned Contexts" to 1 - "Missing". The context was then picked up when the role was assigned and the provisioning worked exactly as expected, with only the desired privilege being provisioned. Great news!

So, I went back to testing with 2 repositories, by adding a 2008 privilege into my business role and tested again, and this time, not so great. The 2 privileges in 2003 still worked fine, with only the one with the correct context being triggered, however the 2008 privilege was also triggered and set at pending. This is because the user does not have an account privilege for AD2008, as by definition they don't exist in there. My assumption was if I assigned an account privilege, this 2008 privilege would decide it shouldn't be assigned and "disappear", but until the provisioning starts, this can't happen.

I'll update this question later once I have concluded, but for now, it looks like an OSS message to see if the Context check can be moved to before the account privilege check.

Thanks to Chris for the help, and any other thoughts welcome.

Cheers,

Ian

[Former Member]

Hi Ian,

yes, that oddity is there for performance reasons.  They designed it that way so that there would not have to be a calculation on provisioning, but when the assignment was made.  That way for additional actions on the user, they won't have to recalculate what the user should have.

Has positive and negative consequences.  I believe that development is reviewing if there are any possible improvements to this.

One additional question.  How do you have your ABAP system privileges configured?  Are you using the master privilege "No Master Task" or do you have it added to your business role.  If it's added to your business role, add the MX_CTX_TYPE but leave MX_CTX_CONDITIONAL blank.  See if that fixes this issue.

Regards,

Chris

[former_member190695]

Hi Ian,

Try to add the business role in the following syntax:

{CTX=<2008>}<ROLE:BUSINESS:HELP>

Regards,

Ridouan

[Former Member]

HI Chris,

Thanks for the insight into the thinking behind the solution, I'll wait to see what response I get about the options from SAP formally as to me, not being able to use this effectively to selectively provision to a repository is a big limitation.

To answer your question, we are currently assigning Account privileges (PRIV:<REP_NAME>:ONLY), which are the master privileges on our "real" privileges explicitly for this testing, but will put them in the role model later. I'm confused by your suggestion though, as if I left MX_CTX_CONDITIONAL blank on my privileges, how would IdM know which privileges from the role to provision as I though it used this to determine that by comparing it with the auto context on the user?

Thanks,

Ian

[Former Member]

Hi Ridouan,

Thanks for this, I'll give it a go tomorrow and let you know.

Cheers,

Ian

[Former Member]

Hi,

If you leave MX_CTX_CONDITIONAL blank but fill in MX_CTX_TYPE on the privilege, I believe it will provision it no matter what, if the context type is selected.  It's effectively all contexts for that type.  It's been since SP3 when I did this though, so it may not work that way any more.

Regards,

Chris