Custom Approval Objects with SAP Identity Management
Another great advantage of SAP Identity Management is that it is possible to extend the schema to own needs. With this you can create your own custom entry types and attributes. In this blog this is used to create two entry types. The first entry type will be for requests (ISV_REQUEST). The second one will be used after the requests are approved (ISV_PENDING_VALUE). This second entry type contains values which will be added to a person object as part of an approval process at a given time. The construct is similar to the existing Pending Value Object (PVO).
The following systems / applications have been used in this blog:
- SAP NetWeaver Identity Management 7.1 SP4
- MS SQL Server 2005 Database
Knowledge / experience in the following areas are necessary / helpful:
- IdM Schema in general (Custom Entry Types and Attributes)
- Workflow / Approval in general
Imagine you have several processes in your company, which include approving new users or deactivation for existing ones. I will focus on these two use cases in this blog.
You retrieve any needed information and begin to implement the processes in the IdM. As it is no good idea to let normal users create person objects, one might think about using a request instead. This is due to security issues a better option. If normal users create persons this could easily be used to have access to information normal users should never have to. Using a standard PVO will not work because of the administrators have the knowledge to set up the SAP roles and AD specific attributes like Terminal Server Profile Path in the approvals. See the next chapter about for details.
After coming up with the solution to create a new entry type for requests, it is possible to let the user enter the data for the new employee and the approvers to complete the needed information. After everything is done, you can create a new person object. E-Mail notifications can be sent during the process to the requester, approvers and the manager of the new employee.
For the time dependant deactivation you will also need an entry type for that. One could also use the standard PVO for that but if you want to do some special work the standard PVO just will not work.
Advantages in using own Approval Objects
For information about the standard PVO refer to the Identity Store Schema (link above).
One of the advantages of the standard PVO is the built in functionality of time dependant applying. If you want to use your own approval objects, this functionality has to be built up by your own.
Yet, there are some disadvantages of the PVO. The attributes of a PVO cannot be changed in approval tasks. So there is no possibility to change the data given in further approval steps. But this is sometimes crucial for the daily work of administrators / key users which approve the requests.
Another downside is that the PVO is applied internally and then moved to the history. If you want to do more with a pending object than just applying one value of the PVO will not work. If you want several attributes to be changed or special provisioning, I suggest using your own Request / Pending Value object construct.
For this you will need two new entry types already mentioned. The ISV_REQUEST object will handle the requests and approvals and the ISV_PENDING_VALUE will do the PVO part.
The request may contain every attribute your MX_PERSON object has like first name, surname, account information, roles, etc. You can also retrieve information from the person the request was filed upon.
In addition to these, the pending object will also contain the same attributes of the PVO like valid date, attribute name and value. Yet, the pending does not need every attribute of the request like the information about the approvals or not relevant attributes for the applying of the pending.
In combination these two entry types overcome the disadvantages of the standard PVO. Also they can be adapted individually to your needs without manipulating MX entry types or their behavior.
The infrastructure for your own Pending Value can easily be set up using tasks and jobs in the Identity Center. The UI and approval tasks retrieve all needed information. The rest is done automatically in some post processing tasks.
The own Pending Value has also an advantage in post processing after applying the pendings. You can call tasks which handle the setting of attributes and do some special provisioning actions.
Usage of the Custom Request Object
Using requests you can deal with all information and roles for a new or existing person before writing these to a person. In this part I will show you how the Custom Request Object can be used to file requests for a new user and deactivation.
Requesting a new user
A request in the UI for a new user might look like this:
After the user completes the requests and presses the “Request new user” button, the post processing can begin. For example this can be:
- Setting up general request attributes
- Mailing the user and administrators / key users
- Checking on existence of the desired username
- Setting the requester
Setting up general request attributes
|var newMskeyvalue = “REQUEST:USER:” + desiredUsername + isv_generateTimestap()
uIS_SetValue(mskey, isId, “MSKEYVALUE”, newMskeyvalue);
Please note that the variables isId and desiredUsername have to be set up properly. The mentioned script for timestamp generation is optional. Just use another small script to retrieve the actual date and parse it into what you want. An advantage of setting up a timestamp is that you can search for the date the request was sent.
With another script you can set up the requester. Showing the requester in the approval tasks is a really nice feature for the administrator / key users.
Mailing the user and administrators / key users
For the mailing you have to set up several tasks and scripts. Best practices are text or ini files to store the text templates. In these templates you can use “variables” to fill in the actual values of the request. An example might be __FIRSTNAME__. You need a script that fills in these variables to whatever the user entered.
Here an example of a mail. The replaced variables are red framed.
Checking on existence of the desired username
The desired username should be checked on existence before the request is even approved. You could also use the unique option of an attribute (Validation tab) but then you would have to store this at the persons, too.
There are advantages and disadvantages of doing this, alsodepending on your company’s solution. One of the disadvantages is that you have to maintain every namechange (old and new name!) or else there might be problems in the future mixing up persons. Another might be the reconciliation with your end systems (SAP, AD, …) if you still allow users to be added in special cases. Also you have to overcome the problem of storing the username in the request and the person at the same time. Or at least until the request is moved to history.
In this case I will focus on the option to not use the unique attribute. To ensure that there is no existing user with the same username, simply use a script with a uSelect() on the database:
|SELECT COUNT(*) FROM MXIV_SENTRIES WHERE AttrName = ‘MSKEYVALUE’ AND Searchvalue = ‘” + desiredUsername + “‘”|
If there are zero rows, everything is fine and the username can be returned as is. In the other case you have to ensure that the administrators change the username. To enforce the changing in the UI it is a good idea to use a regex validation on the field in the approval tasks. To ensure that the username is really unique you can loop around in a several approval task until the username is entered as a unique name.
After all the post processing is done the administrators / key users have to approve the new user. Using the approval tab you can set up who should approve this request.
In this example the mail address has been generated using the format firstname.lastname@example.org.
The approver has the possibility to change the username and the other information. Yet, you can handle this to your own company’s needs
The SAP Roles tab shows the two attributes for privilege and roles which the approver can choose due to the entered further information of the user.
After all approvals are done you can create the user using a ToIdentityStore pass. Afterwards mail the manager that a new user was created. Depending on how you hand over the password, you can implement this as needed. The easiest way during implementation is sending it in the mail to the manager.
The request for deactivation shall be time dependant so that a user can file the request long before the deactivation should take part.
This process will not only use the ISV_REQUEST but also use the ISV_PENDING_VALUE for the time dependant processing. How this Pending works is described in the next chapter. Yet, before the pending you have to set up the request firs, which is quite simple. Just let the requester enter these things:
- The user which should be deactivated
- The date on which the deactivation should be
- A reason for the deactivation
The post processing after filing the request can be similar to the one for user creation.
The approval may look like this:
After the approving is done an ISV_PENDING_VALUE is created automatically. The Pending is created similar to the normal PVO.
Usage of Custom Pending Value Object
The custom pending value is used to hold the pendings until the day they should approved. This is similar to the PVO. Remember, the PVO could be used, too, but will not work when you not only want to apply one value but have to do more work like special provisioning.
You now set up the processing of the Pending Value. There are two parts:
- A job which is scheduled every night and applies the Pending Values
- Tasks which are called from this job
The Apply Pending Value Batch-Job
The first thing you have to do is gathering information which Pendings in your system are ready to be applied. This is still very close to the PVO. You have to retrieve the following values:
- The Pending Values which shall be applied today
- The person which shall be deactivated for each Pending Value
After that you have to write the Pending Value to the person the request was filed upon. In this case the pending value is the MX_LOCKED attribute with a value of 1 indicating the lock.
From this point on there may be other things to be processed, like mailing the requester, manager, user or doing some special provisioning actions. For the deactivation process it could be needed to remove all groups and roles from the person, depending on your existing processes.
For only one type of pendings (e.g. deactivation or name change) you could do this in the job itself. But if you want to set up more than one type I suggest using tasks. Post processing requests like name change or reactivation might be trickier to handle. Especially when you have to divert more than one case, a task structure is more flexible than a job in the Job folder. For these processes running provisioning tasks is just fine.
The last thing you have to do is to delete the Pending Values which were applied before. Simply call a ToIdentityStore pass with the changetype delete on the MSKEYVALUE of the Pending Values.
Possible task structure of the post processing
As the post processing of the deactivation in this case is quite simple this could also be done in the job above. Yet, I want to call a task “Delete roles and privileges” from the job. Also it is possible to do the post processing time dependant. Let’s say the roles and groups shall be deprovisioned not directly but a whole month later. Simply call the task with the parameters you want.
If you want to set up your processes involving every user in your company you can do this by extending the given schema. Two objects for requests and pendings will be enough to handle any processes you have. The first collects all data from users and administrators / key users independent from all existing persons in the IdM until approval of the request. The latter handles time dependant processes like name change or deactivation.