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.
2. The modify task fires.
On newer version of SAP Provisioning Framework 7.2 there is checked of “User context variables”.
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.
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.
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.
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.
- SAP Managed Tags:
