Customized logic using customized rules and a customized generator

You can use a combination of a customized rule and a customized generator to add customized logic for generating passwords.

Using standard password rules might not always be helpful or even wanted at all. You might prefer a single customized password rule to generate compliant passwords. You might use a standard set of password rules to define password policies. When you want to avoid standard rules, that preference must be known to the IBM Verify Identity Governance administrator.

Mixing customized rules with a customized generator might have unforeseen implications. For example, a customized password generator implementation might be sufficient to generate valid passwords, and thus a password policy might not be required at all.

Using a customized rule might preclude the authors of password policies from using some or even all standard password rules that might be incompatible with the customized rule. However, to achieve the wanted effect, authors of customized rules or generators might decide to use a combination of both. Such an approach might be more flexible, because different parameters can be passed to individual rule definitions in password policies for different service types.

Joining rules

Any class that implements a Rule interface is expected to provide logic in its join() method. This logic joins parameters of two rules of the same type defined for two or more accounts of different service types. If such joins are difficult or even impossible to do, parameters of one of the two similar rules can be chosen by code. The Framework does not provide any mechanism for resolving join conflicts. The author of customized rule classes resolves such conflicts by imposing a preferred mechanism in the join() method itself.

Constraining the password generator

For customized password generators, which are based on an iterative algorithm, limiting the possible number of attempts during which the password might be generated is a way of ensuring that the maximum limit of iterations is not exceeded before a valid password is produced. A valid password is one that complies with all the rules defined for it in a password policy. Each rule class implements the constrain() method that tells the generator how to generate the password.

Authors of customized rule classes might choose not to implement the constrain() method. These authors must test the process of generating the expected password. They must test with a combination of rules, including the customized rules, which are expected to be used in production environment. The test must produce an acceptable, large number of consecutive passwords are generated without triggering the IterationsExceededException. If the test is successful, the mechanism is acceptable, and can be used in the production environment. Some customized password generators (for example, those generators based on a dictionary) might not require constrains at all. In such cases, constraint() methods although always called, do not affect the way passwords are generated.

Note: The maximum limit of iterations is hardcoded 20,000.

Internationalization

Parameter values passed to the customized generator might include Unicode characters. If the passwordrules.properties file contains any Unicode characters, save it in Unicode format. IBM Verify Identity Governance automatically detects the format when the file is read. A file that contains Unicode characters must be viewed and edited with a text editor that can display these characters.

Alternatively, use the hex-encoded format to insert the Unicode characters into the file: \uXXXX or OxXXXX. This method makes it possible to view and edit the file in text format, but the generator class must interpret these character encodings. The StandardGenerator class in the password rules framework can generate passwords using Unicode characters to the extent supported by the Java™ used with the IBM Verify Identity Governance server.

The default character set used by the StandardGenerator class is uppercase and lowercase letters from the Latin alphabet. They correspond to Unicode ranges 0x0041-0x005a and 0x0061-0x007a, and most special characters such as #, $, and % that are in the ASCII set. You can extend or replace this character set by defining a parameter value for the standard generator class in the passwordrules.properties file. For example:

generator.com.access360.passwordrules.standard.StandardGenerator=
\0x0041,0x005a \0x0061,0x007a  \0x0104,0x0107  \0x0118,0x0119  \0x00d3
 \0x00f3  \0x0141,0x0144  \0x015a,0x015b  \0x0179,0x017c

The first two ranges are the standard Latin letters. The others are from Extended Latin I and II Unicode sets. Customized rule parameter values added to password policy definitions might also be required to accept Unicode characters. Again, the two ways of specifying the Unicode values and ranges of values apply here as well. XML is used to save all rules within a password policy to the LDAP directory. The interface always displays the customized rule parameters exactly as they were entered.