Additional Blogs by Members
cancel
Showing results for 
Search instead for 
Did you mean: 
Former Member
0 Kudos

This blog will introduce you to the different types of validations that are shipped with the SAP Identity Management and what you have to do to use these validations. We will take a look at the “standard” input validations with Regex and will compare them with the possibilities of creating own validation classes in Java with the extension framework. This blog will give you an overview on the use cases and guidance how you select the appropriate use case for your input validations. At the end we will take a excursion to the future which shall give you a glimpse on possibilities in regards of validations with upcoming releases of the SAP Identity Management. Furthermore we outline the topic of features that would be nice to have in further releases. The scenarios contained in this blog are based on existing projects and are not fictitious.


The following systems / applications have been used in this blog:
•    SAP NetWeaver Identity Management 7.1 SP04
•    Oracle Database

Knowledge / experience in the following areas are necessary / helpful:
•    IdM Schema in general (Custom Entry Types and Attributes)
•    Programming in Java 1.4.2

 

Input validation – why?


Input validations are needed to ensure that an application will perform its processes with correct and useful data. These input validations in SAP IdM can be written with regular expressions on the one hand. On the other hand via validation programs in which the rules and conventions for the input validations are implemented. These input validations will check the input date on its correctness and validity. Input Validation is not only reading and comparing input data with the existing rules - input validation can also contain automated adjustments to imported and checked data. Input validations will increase your data quality and prevent wrong data to be entered into the program.

 

Regex vs. Extension Framework

Validations in SAP Identity Management are mostly implemented with a regex expression in the respective attribute. This is definitely the fastest and easiest way to validate an attribute value in SAP Identity Management. If you open an attribute in the Identity Center you will see a tab called “Validation”. In this tab you can insert a regular expression in the input field “Regex”(red framed in the following picture).

 


You can validate the values of attributes with all the possibilities of regex expressions. With this kind of validation it is not possible to validate an attribute which depends on another attribute in the Identity Center. The regular expression refers only to the same attribute for which it is defined. This fact limits the flexibility and possibilities of the regular expression validation in the SAP Identity Management a lot.
As opposed to this the input validation with the SAP Extension Framework will be much more flexible and allows you much more possibilities to validate your data in the SAP Identity Management. Validation with the SAP Extension Framework means the programming of validation classes in the programming language Java. These validation classes will be deployed to the Java Engine and embedded in the task which should be validated. So the best way to see the differences between those input validation methods is to take a look at some use cases.

Use cases for input validations

 

Validate passwords with a regular expression in SAP Identity Management.

Simple attribute value check with Regex Expression


In the first use case we want to check a password which must have at least four characters, not more than eight characters, must include at least one capital letter, one lower case letter and one numeric digit. These are the rules for this validation scenario. This kind of validation can be used e.g. for password fields which have to include passwords within the given security restrictions. This kind of validation can be solved with a simple regex expression and does not need the effort of creating the landscape for the validation with the SAP IdM Extension Framework. There is no need for some extended validations with the extension framework. For this kind of validation it is enough to insert a validation definition as displayed below.



 

 

A password like ‘Test1234’, ‘A1bc’ or ‘123456Df’ will match with the restrictions from the regular expression above. But a password like ‘Test’, ‘1234DB’ or ‘abcd13’ will not match with this regular expression. So as you can see the “standard” attribute validation of the SAP Identity Management is sometimes efficient enough for simple attribute validations and it is not necessary to create validation classes with the Extension Framework to achieve the same result. But this kind of validation in the SAP Identity Management is limited as already mentioned. In the next step we will take a look at a more complex validation with SAP Identity Management. Not only the validation possibilities are limited but also the way to show the user what is wrong with the given input data. In this variant it’s not possible to influence the error messages.

 

Multi-attribute validation with SAP Extension Framework


For more complex validations in the SAP Identity Management it is necessary to use the Extension Framework. To use this for input validation you have to prepare your environment. For more information please take a look into the Extension Framework Document in the SDN. There you will find all information about the configuration and preparing the system which is necessary for using the framework. In this use case we will check a “validFrom” date which is the entry date and the “validTo” date which represents the leave date of an external employee. This scenario is often used for creation of external employees because in most cases the leave date of these persons is known.



 


So in the onSubmit() method in the “TaskProcessingAdapter” class it is necessary to loop over the given attribute list and check whether the current attribute is MX_VALIDTO or MX_VALIDFROM. If one of these attributes matches with the current attribute in the loop you can get the value by calling the method getAttributeValues().

It is possible with the extension framework to validate two or more attribute data from a task dependent on each other. There are a lot of possibilities for input validation in SAP Identity Management. But one further advantage of the validation with the SAP Extension Framework is the kind of error messages which can be shown in the SAP Identity Management UI. It is possible to throw your own messages. These messages can also be multilingual.

The thrown IdmExtensionException will not include the error message text, it includes a language key. This language key will be written into the language translation table. This table contains also the language codes which represent the language of the message e.g. “EN” and the message itself. So the message will be taken from the translation table in that language the user is logged in. That enables your validation error message to be multilingual.
Also the properties in validation classes can be configured in the SAP Visual Admin without changing the implemented Java code. This can be done by using the global properties in the Enterprise Application Module in the SAP NetWeaver Developer Studio.





"For example: the leave date of a new person, which should be created may not be further in the future than two years." For the calculation in the code you will have a constant like “Period=2”. As an example: One of the specialty departments wants to set this period up to three years. In such cases you would have to modify, build and deploy the Java code on to the target system over and over again. With the global properties the employees in the specialty department can go into the Visual Admin and change the constant from two up to three, restart the application and the new period will be used in the validation class.
With this kind of input validation it is much more extensive than with the “standard” SAP Identity Management validation on attributes with a regular expression. But in the next step we will learn, that there is much more possible than only validating attributes in the so called TaskProcessingAdapter class.

 

Validation on data outside current data by using e.g. JDBC connection


For the last use case we will increase the level again. The use case remains almost the same. We still use the task for creating a new external employee. Now, in addition to the previous scenario we want to select a company and a responsible for this particular employee. So the validation rule is that the responsible needs to have the same company code as the company selected for the external employee. As you can see the problem is that for those attributes we will get only the MSKEY as attribute value. That is a unique key e.g. 123456. But this problem can be solved. We will establish a JDBC connection from this Java class to the Identity Center database and retrieve the company codes by executing an SQL query.

 



This use case shows us, that it’s also possible to connect to the Identity Center database to retrieve data needed for the input validation in the TaskProcessingAdapter class. Also the connection to third party systems is possible.

 

Current limitations


Features like to pre-filling attributes in a task would be very nice for further releases because there are much more possibilities than in the recent version. Also the modification of the attribute values in Service Pack 4 is not possible until now. You can only read out the attribute values, validate them and display some validation messages to the UI. To change values will present you another possibility. E.g. you have a number field which must have a size of eight. So you validate this attribute value and get an input data like “234589”. You can put some leading zeros in front of the number to get a size of eight.
I hope that this article has shown you what is possible using input validations in the SAP Identity Management and when to use the right input validation method.

Link to similar blog: The specified item was not found.