Developing Java-AddOns for SAP IdM is a mighty instrument to enhance the usability and the functionality of SAP NetWeaver Identity Management. In this blog series we will show how to connect to SAP IdM out of a java. There will be two parts in this series.

AddOns for SAP NW IdM: Part I - Creating a java connection to the identity store via SPMLThe first part provides a view on the java application and the connection to the SAP Virtual Directory Server (VDS) via SPML.

Part II: The second part provides a detailed view on the necessary configuration of the SAP Identity Center and Virtual Directory Server.

The following systems / applications have been used in this blog

• Virtual Directory Server 7.0
• Identity Center 7.0

• SAP NW Identity Management knowledge
• Java and JavaScript knowledge

Introduction

In the last blog we have designed a Java application as an IdM AddOn to access data of the identity store. The pre-configured templates from SAP for the Virtual Directory Server and the Identity Center are used in this blog to extend them to our needs. Main focus is on the Identity Center to get the requests and start specific tasks, e.g. to map the received data to target entries and propagate these changes afterwards to our AddOn.

Configuring the VDS

My colleague Steffen Baumann will soon explain the VDS configuration for accessing the identity store in a blog. With this configuration, you are able to access any entries and attributes of the Identity Store in a flexible way. You could also use the pre-configured Template Identity Services.

In addition, you need a web service, which receives SPML requests from our AddOn and forwards them to the IC. For deploying the web service you need an application server like Tomcat or Web AS Java in NW IdM 7.1. Select Deployments -> web service deployments in the VDS tree afterwards. You can either use SPML1 or SPML2.

With the Web Service Client of the VDS you can test the web service before continuing with the configuration of the IC.

Understanding Identity Services in the IC

This blog is based on the Identity Services Provisioning Framework, which has to be imported and configured. The necessary steps for the IC are explained in the last few pages of the Identity Services Tutorial. You can test the Identity Services via SPML requests of the VDS Web Service Client.

The MX_ASYNC_REQUEST Entry Type

As a result you will get tasks which receive the SPML requests from the VDS to add, modify or delete certain entries in the Identity Store. The content of the request is in an own entry type, MX_ASYNC_REQUEST, which has to contain all possible attributes of the target entry types and some more attributes for the type of the request, which start with MX_ASYNC_... Without async requests, the requests would be directly on certain entries. Main benefit of the Identity Services task structure is one single point for controlling the exchanged data before mapping it to the target entry type with specific rules for each attribute.

E.g. we add two new privileges (SAP_TST_XI_DISPLAY_USER, SAP_TST_XI_MONITOR) for the existing person Jessica Baker. Therefore, you would send a new MX_ASYNC_REQUEST with a modify request via VDS to the Identity Center:

There have to be more attributes of MX_PERSON in MX_ASYNC_REQUEST, if they need to be changed. You could also send all attributes in the request and they are overwritten, if the have changed.

The Identity Services Task Structure

If you went through the Configuration Guide, the task “Process ASYNC Request” is called on every ADD event for MX_ASYNC_REQUEST. Based on the attribute MX_ASYNC_ORIG_OPERATION, different tasks are called. In our case we need a closer look at the MODIFY of the switch task, where the task “On ASYNC Modify!” maps the attributes of the request to MX_PERSON.

There is the function testEmpty called for every attribute to prevent deleting attributes, which are not in the request. If you want to delete an attribute, it needs to have the value “!!DELETEME!!”. For handling multivalue attributes like MXREF_MX_PRIVILEGE, you need to extend this function, which will be explained later on.

Have also a look at the ADD and DELETE tasks. In case of DELETE, the entry is only disabled, which could be changed to a real delete. The ADD task is similar to the MODIFY task, but doesn’t need the testEmpty function for the attributes.

In our case we use the task structure of the Identity Services for MX_PERSON. But there are no restrictions in the architecture and you could also use it for other target entry types. The attribute MX_ASYNC_OBJECTCLASS is written in the entry type field of the destination tab. That’s why we map all possible attributes with the attributes of the target entry types.

Extending Identity Services in the IC

We can extend the Identity Services in the IC to fit our needs. Some examples are described below.

Removing old MX_ASYNC_REQUEST

For stability and monitoring reasons it is not recommended to re-use the same MX_ASYNC_REQUEST with a MODIFY event on the entry type. That’s why with every new request an MX_ASYNC_REQUEST is created. After a while there is a huge amount of these entries. Usually we would use the storage options of the attributes and set it to a number of revisions or days, but there is no possibility to set the storage for entry types. We could either delete the MX_ASYNC_REQUEST after every mapping or on demand. Even after removing requests we still have information about the historical values and modify time in the target entry types.

Before we delete the request after every mapping, we can write relevant content of the request to an other database for a backup. Passwords etc. shouldn’t be extracted in this case. If you like, you can create an action task below MODIFY and use a To Database Pass. Map relevant attributes in the table via the destination tab.

To remove the request, we use a To Database Pass in an action task afterwards. In the destination tab you can call the stored procedure mc_reset_ids_mskey with the MSKEY of the request as parameter.

Be aware that the screenshot shows the call of the procedure in MS SQL and not Oracle. After testing you can link the two tasks also below ADD and DELETE.

You could also delete MX_ASYNC_REQUEST on demand. Copy the job of the last action task to a job folder. In the Source tab you can build an SQL query to fetch certain MX_ASYNC_REQUEST. Otherwise you could set the action task below a workflow task (ordered task group) to delete selected requests.

After the tasks of the Identity Services, the mechanisms of the SAP Provisioning Framework are called, e.g. based on a modify event on MX_PERSON.

Propagate Changes from the Identity Center

Until now we only receive requests via Identity Services and provision them with the SAP Provisioning Framework. But after the provisioning or in the case of errors the AddOn from blog 1 should get information about the status. There are different ways to do this.

The AddOn itself could search for the entries in the Identity Store after a specified time and check if relevant attributes are set, e.g. the generated ACCOUNT attributes while provisioning. For instance the search could be realised with a SPML request via VDS directly on the MSKEYVALUE of Jessica Baker (00900044). Problem is to get status information in detail.

Another possibility is to call a web service of the AddOn, when important steps are performed or error occur in the IC. This web service could check the entries afterwards or inform the responsible administrator in case of errors. You need to integrate these calls in the SAP Provisioning Framework. Following screenshot shows the call after a modify event on MX_PERSON.

In our case we use a To Generic Pass to call a JavaScript, which calls the web service via a Java class. The MSKEY, SAP_CHANGENUMBER and MX_ENTRYTYPE are forwarded.

My colleague Dominik Trui has published a How to use custom classes in the SAP NetWeaver Identity Management, which can help you to realize an own web service call - probably in a more elegant way than shown above.

Enabling Modifies on Multivalue Attributes

For a modify on single value attributes the earlier explained testEmpty function works well. But if you want to change a multivalue attribute like MXREF_MX_PRIVILEGE, we should write a new function. Important to know is that existing privileges are not compared with the new ones of the request by default to be added, deleted or kept. You need to have experienced knowledge of the Identity Center to implement one of the following alternative steps, which are based on the type of multivalue requests you send.

New multivalue attributes are usually added and not compared o the existing ones. Alternatively, we could delete and add privileges in the same request by just replacing the existing ones, e.g. with the prefix {R} in the Destination Tab of the Pass Move to People for MXREF_MX_PRIVILEGE. With this prefix, a lot of provisioning jobs in the SAP Provisioning Framework would be started, even if nothing changes, because the IC first deletes all privileges, before adding them all again. In this case, the request needs to contain all new and existing privileges. For deleting certain privileges instead, we could use the prefix {D}. Either the logic about the privileges, which have to be deleted, is in a script or there are two attributes in the requests, one for adding and one for deleting. Have a look in the IC help for further explanation about {R} and {D}.

In our case, we send all existing or new assigned privileges in every SPML request, because our AddOn from the first blog also holds the existing privileges and doe doesn’t need to mark certain privileges to be deleted.

For instance we want to add privileges (SAP_TST_XI_DISPLAY_USER, SAP_TST_XI_MONITOR) for Jessica Baker. If she has existing privileges, we would also send them via every SPML request. If another privilege has been deleted in the AddOn, it is not longer in the SPML request. The script compares the existing values with the new values by looping through them and adds or deletes values where necessary. If you call the script in the Move to People pass for the multivalue attribute MXREF_MX_PRIVILEGE, you could use the prefixes {A} and {D} in front of the output parameter to add or delete attributes.

We decided to call the script twice for the same attribute with slightly different parameters for either adding or deleting values.

Summary

In this blog we began with the configuration of the VDS based on Identity Services to receive and forward the SPML requests of our IdM AddOn, which has been explained in the first part of this blog series. The Identity Center gets the SPML requests in an own entry type of the identity services framework, which also does the mapping to the target entry type. The existing possibilities are first explained in detail for our use case. Afterwards, we extended the Identity Services to handle a high amount of requests, to propagate changes from the Identity Center to our AddOn and to enable modifies on multivalue attributes.

…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%)$$

Now let’s begin with the script. You find a lot of resources for JavaScript in the internet and the SAP NW IdM help provides you with samples for its built-in functions, which you can access with a right-click in scripts. While the execution, you can write text to the Job Log with the built-in function "uErrMsg".

It will look like this for your attributes you get as input parameters:

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 “|”.

You get the MSKEY of the roles seperated with "!!" from your SQL query. First use the JavaScript split() method again to create arrays and afterwards use the concat() method for all arrays.

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.