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:
| Attribute | Example | Comment |
| MSKEYVALUE | bce91bd0-cac3… | Generated unique identifier from the VDS for the MX_ASYNC_REQUEST |
| MX_ASYNC_MSKEYVALUE | 00900044 | MSKEYVALUE of the target entry |
| MX_ASYNC_OBJECTCLASS | MX_PERSON | Name of target entry type |
| MX_ASYNC_ORIG_OPERATION | MODIFY | ASYNC original operation: ADD, MODIFY or DELETE. There are different tasks for each operation |
| MXREF_MX_PRIVILEGE | SAP_TST_XI_DISPLAY_USER | Either MSKEY or Name, depends on implementation |
| ... | ... | ... |
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.
- SAP Managed Tags:
