SAP NetWeaver Identity Management: How To Determine Business Roles Proposals in Workflows
…By Evaluation of Controlling Attributes of the Managed Identities
In this blog, we will improve a common business roles scenario by proposing business roles based on the controlling attributes of the business roles and of the requester. After the economic background, we will do the implementation in SAP NW IdM, by doing a bit of preparation, creating an approval task structure and implementing the ranking. The following scenario uses a data model, which will be different in each company. One strength of SAP NW IdM is its flexibility, which helps you to adapt the scenario to your requirements. You will get some hints to adapt and extend this scenario in your environment.
Knowledge / experience in the following area(s) is helpful:
- Basic SQL knowledge
- JScript knowledge
- SAP NW Identity Management knowledge
Handicaps in Common Scenarios…
One of the main benefits of Identity Management is giving permissions to various systems for an employee with one or few business roles. These roles are usually for a position, a short project or a work area. In workflows with employee-self-services, the business roles can be requested from the employee and approved by his manager.
In reality, companies need hundreds of business roles for different areas. The employee needs to know which business role to request and the manager needs to know what to approve. Both cannot always understand the technical privileges behind. They also can get confused by the naming of the roles, because of a different understanding from the people who created the business roles.
…And Finding a Way Out of this Dilemma
One way out of this dilemma is to propose business roles automatically for the employee, who only needs to select some areas, which he will be working for in future, instead of choosing a specific role. The approver can review these roles afterwards, before he approves. There’s also a possibility to limit proposed roles and do some other improvements, which will be topic of my next blog.
The request of the employee and the business roles can have some attributes in common, like organisational unit, main area of work and duty. In addition, the employee could also select systems he needs to access. Afterwards, SAP IDM does a relevance ranking in background and does a proposal for the most appropriate business role/s.
Let’s get Technical – Create and Assign Attributes
You can either define attributes or chose existing ones (e.g. organisational unit, main area of work, duty and systems) for the relevance ranking. If you like to select more than only one value for each attribute, e.g. for the attribute “system”, you can select the checkbox “multivalue attribute”. The following screenshots show the creation of the first attribute “ISV_ORGANISATIONAL_UNIT”.
For this blog, we define some values in the “Attribute values” tab by just adding them. In a productive environment, we would use SQL queries instead or link to other entry types via MXREF-/MXMEMBER-Attributes, which get data from source systems or are maintained in the workflow.
Use MultiSelect instead of SingleSelect for the “Presentation”, if you have selected the checkbox “multivalue attribute” in the storage tab.
We link each attribute in the tab “Entry types” with MX_PERSON and MX_ROLE, so that we can maintain our attributes for both entry types.
Repeat the last steps for your different attributes. We need to create one more attribute, called “ISV_REQUEST_ROLE”, which contains the requested role. In the tab “Entry types” it is linked to MX_PERSON. Use following values for the “Storage” tab:
Create Business Roles and Employees
Create two ordered/unordered task groups for new business roles and employees. You find some examples in the web enabled tasks of the SAP Provisioning Framework, provided with newer releases of SAP NW IdM. Or you already have similar tasks, which you can modify.
In the tab “Options”, enable the tasks and make them a public task.
In the tab “Attributes”, select MX_PERSON for the first task group and MX_ROLE for the second task group. Select “This task creates a new entry”. Select common attributes like MSKEYVALUE and DISPLAYNAME and your new created attributes (except ISV_REQUEST_ROLE).
You can add your administrator in the tab “Access control” to access the task group it in the workflow.
Afterwards, you can log into your workflow component (e.g. http://localhost/Workflow/index.php). Create two employees in your workflow – one for requesting and one for approving. Create some business roles in your workflow and assign your new attributes. The task group for creating business roles could look like this:
Create the Approval Structure and Tasks
Till now we can relate employees and business roles with our new attributes. It is time to create our approval structure. It will have one task for requesting business roles and one task for approving them. The other action tasks will run in background. This is how your tasks will look like:
On top, you create a new folder in your identity store. Below, you create a new task group, e.g. “ISV – Request Business Role”. The “Attributes” tab should look similar to the following one (don’t list ISV_REQUEST_ROLE). You could select some of your new attributes to read only, e.g. if they are set through SAP HCM or to restrict the requested roles.
In the “Access control” tab, add the following information to have a self-service for every logged-in user.
The task group will look like this:
Now we create the action task “Get Roles of Area” (“Action Task” -> “Empty Job”) for the script and come back to this later.
Create the approval task “Approve Employee Request” on the same level as the action task before. Use the same attributes as in the task group for the request. Then, set your new attributes (ISV_ORGANISATIONAL_UNIT etc.) to read only and list ISV_REQUEST_ROLE and MX_ROLE with deselected read only. Choose a Manager in the tab “Approval”. In my next blogs, I will show you some advanced techniques in giving access control.
In the end, the approver will see a similar approval task with the chosen attributes and the suggested business role/s. He can also see the business role/s the requester had before:
If the request is approved, we will copy the requested role to the already assigned roles (MXREF_MX_ROLE). Afterwards, the requested roles can be deleted. Create an action task “ApproveRole” (“Action Task” -> “Empty Job”). Below, create a pass “To Identity store”. In the “Source” tab, select MX_PERSON. In the “Destination” tab, type in the following data or use the right mouse to save some time.
Afterwards, enable both, task and job and select a dispatcher for the job. Use the same procedure for the action task “DeleteRequestRole” for declining. The destination tab is different to the one before: Don’t use the attribute MXREF_MX_ROLE.
If you like, you can also send eMail notifications. Create an action task “Notification” with help of the wizard. Inside the pass is a VB-Script, which needs an SMTP server to send the notifications.
Implement the Ranking
Now as the structure is finished, we need a script, which gets our attributes of the requesting employee and gives back the MSKEY of the most appropriate business role/s.
The MSKEY is the UniqueID in SAP NW IDM for each entry in the identity store. In your database, you can have a look at the view MXIV_SENTRIES to see the entries or use the monitoring component. This will help you later on for the SQL queries.
Navigate to Management -> Global scripts -> Jscript and create “isv_getBRolesOfAreas”. Click OK and go back to your Task “Get Roles of Area”. Link your global script in “Scripts” below the job. Afterwards, create a “To Identity store” pass and select MX_PERSON in the “Source” tab. Call your new script in the “Destination” tab for the attribute ISV_REQUEST_ROLE:
Right-click to insert the function and the attributes. Separate the input parameters with “!!” for the script: $FUNCTION.isv_getBRolesOfAreas(%ISV_ORGANISATIONAL_UNIT%!!%ISV_WORKING_AREA%!!%ISV_SYSTEM%!!%ISV_DUTY%)$$
It will look like this for your attributes you get as input parameters:
var parElements = Par.split(“!!”);
var orgUnit = parElements;
SAP NW IdM has a query builder, which builds the query for you. You find it in “to Identity Store” passes in the “Source” tab, when you select “use identity store”. In the query builder, select your attribute, e.g. “ISV_ORGANISATIONAL_UNIT”, and filter it with a sample value. Use the operator “AND” for “MX_ENTRYTYPE” and select the filter “MX_ROLE”.
Try the query in the database with sample values. You will get back the MSKEY of the roles. Afterwards, you can use the SAP NW IdM built-in function “uSelect” in the script to execute the query. For multivalue attributes, you need to loop through the multivalues and split them with “|”.
There are several ways to do this, e.g. by looping through the array and counting the matches. Just search in the internet to get some samples. If you find different roles with the same rank, use “|” between them for the return.
Give back the role/s with most matches. It will look like this with your custom variable:
Pimp up your Business Roles Proposals
Now that you’ve implemented the business roles proposal, you can pimp up the scenario.
Like mentioned before, in a productive environment we would fill the values of the attributes from source systems. We would either use SQL queries or reference to other entry types via MXREF-/MXMEMBER-Attributes. E.g. you could get organisational units from SAP HCM by using SAP PI. My colleague Steffen Baumann explains more about this in his blogs, beginning with How To synchronize data from SAP HCM to SAP NetWeaver Identity Center using SAP PI (Part I).
With SAP NW IdM it’s possible to use several steps in the approval workflow, with questions for the requester getting more specific, based on the answers before.
For the approver, it would be helpful to show the reason for the chosen business roles and to show some lower ranked roles. These informations are all in your script. You only need a seperate attribute for MX_PERSON and get these informations from the script. Therefore, store these informations in job variables and access them in your new attribute.
You could also make the script more generic to use it with other or more attributes without modifying it. Just use flexible arrays and some loops.
Finally, I will show you some advanced techniques for giving access control in my next blogs.
You can contact me if you’re interested in the whole script. I also want to thank Christoph Reckers for his contribution to this article.