SAP Identity Management

2 Posts authored by: Ivar Ness

Background

A consultant asked me about the inner working of group assignment functionality in the SAP provisioning framework 7.2 and why we are using the MX_GROUP + MX_PRIVILEGE coupling and so on.

 

So I decided it might be worth sharing it with the bigger audience and put it in a blog, after all it is non-trivial stuff and perhaps one of the more complex parts of the SAP Provisioning Framework in 7.2.

 

Anyway it been quite some time since I took on task of starting of the SAP Provisioning Framework 7.2 and it has been progressing quite a bit since then, but still the main concepts still remains pretty much the same.

 

Many of concept changes from the 7.1 framework and 7.2 actually stems from the early Notes Framework.

 

Both the way driving events by privilege assignments and dealing with modify events and group handling where first tested out in the Notes framework. Other concepts such as validation tasks roots back to origin from the GRC framework, where the need for checking assignments head of provisioning was introduced.

 

In 7.1 SAP Provisioning framework as you might know the add member task was used for this and approvals while provision was done by provision tasks, this meant dealing with rollback in case of erroneous assignment and there also would exist a time slot where you had the privilege before it was assigned in the backend.

 

There were already new features in the product for dealing with these issues so basically the 7.1 framework was growing old and not closely enough integrated with development to take early adoption for new upcoming features. So a new 7.2 SAP Provisioning framework was called for.

 

Following benefits we considered as the motivator factor for the 7.2 SAP Provisioning Framework

 

 

Main benefits

  • Proper privilege handling (you don't get privileges before you are entitled to the them

                      7.1 : rollback on privilege events 

                 vs 7.2 : pending privileges

  • Universal framework that handles complicated wait-for logic for you          
  • Hook-ins, gives new framework implementer and foundation to build on.   
  • Better visualization of what goes on.

                7.1 :  Used entry type events triggering firing, and static scripts that hard set attributes 

                7.2 :  Used a layer out task structure. Avoiding the hidden events in scripts.

  • Maintainability: less dependencies between frameworks and underlying 3rd party frameworks controlled by plugin points
  • Less hardwired. Provisioning triggering relates to privileges not entry types and attributes.

        Making it friendly to co-exist with other independent provisioning solutions that does not acquire entrytype or attribute triggering.

 

Of course there been many significant feature down the road since then such as group of privilege that was particularly important to avoiding bottleneck of assignment provisioning in 7.1. Todays context concept, attestation and advanced approval just to mention a few.


Group assignments

But today I wanted to focus on the group assignments.

In AS Java and also the Notes connector (now part of SAP Provisioning Framework), we use MX_GROUP object which is coupled with a group privilege.

 

Basically the nature of MX_GROUP is that it does not have modify events, it considered a container object.

 

If you are somewhat familiar with the SAP Provisioning framework 7.2 you know that there are account privileges (PRIV:<REP>:ONLY) for each repository,

and perhaps you also is aware that there is an internal privilege PRIV:SYSTEM:<rep> that is assigned as a result of account assignment.

The account privilege controls provisioning and deprovisiong to the repository while the system privilege controls modify events.

The event task are by default inherited from repository,

so all privileges except system privileges will disable the modify event by explicitly setting the MX_MODIFY_TASK to -1.

And likewise the PRIV:SYSTEM:<rep> will disable all event task except the modify task (which is inherited, hence not specified on the privilege).

 

The same applies for MX_GROUPs, you assign an account privilege to a group and it gets created in the repository and obtains the system privilege.

In addition however it is assigned a group privilege (PRIV:<REP>:GROUP:<IDENTIFIER> that controls the assignment of membership.

 

So given that you have an MX_GROUP with account and system privilege assigned. There is two ways of assigning members to the group.

1)     1)  Either you assign the user as a member of the group,     or        2)  you assign the group privilege to the user

 

 

So let’s take it step by step.

 

1. You assign a member to a group

This causes MXREF_MX_GROUP attribute to be updated on the user (with mskey of the group).

Since the user has the PRIV:SYSTEM:<REP> privilege and this privilege has the modify attribute MXREF_MX_GROUP enabled this will trigger a modify event in the provisioning framework.

 

modify_attribute.png

 

2. The modify task fires.

On newer version of SAP Provisioning Framework 7.2 there is checked of “User context variables”.

 

  context_variable_on_tasks.png

This enables the generation of MX_EVENT* context variables for the sessions, a prerequisite in newer framework for detecting modification event.

(Basically you can halt the execution by deselecting a job on a task in the task there, pick up the audit id from provision queue, and you can see these audit variables)

While we before used SAP_CHANGENUMBER to track these changes this is much safer and faster approach.

 

3. Update of the group privilege.

 

The task “process modify type” set context variable for different operations, and the conditionals evaluates them.

 

In this case, since the MXREF_MX_GROUP was changed the operation flag will be set, and the ‘Update group privilege’  task will run.

 

The ‘Update group privilege’ task will for each member of the group assign the group privilege.

 

If you have a bunch of users in the group they will already have this privilege so nothing will happened, for the newly added group members however the group privilege assignment will fire of a provision event.

 

modfy_update_group_privilege.png

 

4. Provisioning by group privilege.

If it has been a nested group assignment (AS Java) you would now go in the MX_GROUP switch,

but since this is a persons and not an account privilege assignment you follow to the plugin execution of 4. Exec plugin – Assignment User Membership.

Firing of the plugin task of the repository. Basically how that works is that the task “inherits” the repository from the privilege (group privilege) and

the execute plugin task obtains the plugin task through the repository hook variable as a runtime resolution. And execute a basic provision on the hook.

The execute plugin task and hook task utilizes the wait-for/after concept to halt further execution in the task tree until the plugin task completes.

 

execute_assignment.png

After having executed the respective backend operation. The assignment type is checked.

Since we are dealing with group it has to ensure MX_GROUP and MX_PRVILEGE is in sync on the user.

So it will update the MX_GROUP with the members, meaning the MXREF_MX_GROUP is updated on the user.

Since this is a multi-value reference attribute it will re-trigger the Modify task in step 3.

However the user will already have the group privilege now so it will not re-trigger.

 

Alternatively,

if you assign a group privilege to a user  you basically start the process at step 4 directly.

 

In SAP Provisioning Framework 7.2 v2.

The process is the same, but since the v2 is embedded in Java (with the advantage of improved speed)

The detection of MXREF_MX_GROUP in modify happens inside the Java code.

 

version2_assignment.png

 

And the assignments evaluation happens in the Split conditional and you are redirected to the MX_PERSON_ASSIGNMENT.

And the conditional : Person after Assignment provisioning deals with the assignment type evaluation etc.

 

version2_assignment2.png

I decided to jump to it and give this SDN blogging a try, sharing some insigth and thoughts on Identity Management. For this blog I wanted to take a look at user deletion. Which as you may know is often a complicated process; systems may have different requirements on how user deletion should be handled, which in consequence means you may have to clean up the assigments. So all the users privileges and inherited privielges for roles need to be dealt with.

You may know in 7.1 that if you deleted a user this would immediately delete the user and you would not have any mx_person object for doing the cleanup process on. So the concept of inactive was introduced. The inactive entry would work seemingly like a delete user where delete events where fired. Inactive entries are however only viewable with special views and for tasks processing you need to be enabled the 'use inactive entries' option .This creates extra context switching of the views which in turn does not boost up performance. Also since user deletion requires inactive views and account removal does not you basically have to duplicate the deprovisioning workflow to handle this properly or add some additional logic for context switching (...and handle it "poorly", as you still need use inactive entries on tasks) .

Fortunately in 7.2 deletion works perhaps as deletion should worked in first place. Delete operation is now a pending delete process.Pending delete requires no special views nor context switching so it is much faster, and there no need to duplicate the deprovisioning workflow.So how to do it? just as always, delete the user with a toIdentityStore passs w/changetype=delete.The different is now that events will be fired for deprovisioning of assignments. The user will be in pending delete state and remain so until the fired events complete processing.

UIDeleteTask.png

Basically I just want to delete the user. This will kicks of pending delete.

StopJob.png

We are expecting deprovisioning task in the framework to execute, so lets disable the first available job to do some inspections.

UIDeletion.png

Go!!

The user had two privileges initialy (forgot screenshot) PRIV:NOTES:ONLY (23) and the PRIV:SYSTEM:NOTES (22)

Inspection1.png

Looking at the entry table and link table.We only see one privilige, because the PRIV:SYSTEM:NOTES only has modify task it was immediately unlinked.The entry has mcEntryState 3 meaning pending delete. On the link table we see the mcLinkState 2 on PRIV:SYSTEM:NOTES, which means deleted. And no mcDelAudit set. (no deprovisioning task fired)But for PRIV:NOTES:ONLY it is still in linkState 0 and mcDelAudit is set.Looking at this audit we see the deprovisioning task in the provisioning  framework has fired.

Inspection_audit.png

And the provisioning queue our disabled job is set ready-to run. We can enabled it and complete the deprovisioning against the backend.As soon as the workflow has been executed, the entry will be copied to the old values and deleted.

prov_queue.png

My conclusion:

For 7.2 pending delete should be your default option for user deletion. It is faster and requires less implementation.Audit information is of course preserved in old tables, so the only reason for not doing pending delete would be if you need to reactivate the user at a later point. But even then, you do not get back your assigments so you might perhaps be better of extracting the user info and still use pending delete.

Actions

Filter Blog

By author:
By date:
By tag: