Securing Rules

If a rule contains sensitive information, such as credentials or calls to a Java utility that might have dangerous side effects, you must secure the rule to prevent anyone from using that rule in an unintended way.

Securing rules is especially important if the rules are called from forms. Form rules run above the session, so exposed rules are available to anyone who is capable of creating a session through the API or a SOAP request.

This section provides the following information:

• Put Rules in an Appropriate Organization

• Use Authorization Types to Secure Rules

• Control Access to Rules that Reference More Secure Rules

Put Rules in an Appropriate Organization

As a convenience, most administrators put simple rules, such as those that perform calculations but have no side effects, in the All organization so that everyone granted rights to view rules can access those rules.

However, if you want to provide more security for a rule

• Do not put sensitive rules in the All organization.

• Put the rule in an appropriate organization such as Top (or another suitably high-level organization) so that only high-level administrators can execute that rule directly.

Use Authorization Types to Secure Rules

You can use authorization types (AuthType) to further scope or restrict access to a subset of objects for a given Identity Manager objectType, such as a rule. For example, you might not want your users to have access to all rules within their scope of control when populating rules to select in a user form.

For information about using authorization types, see “Using Authorization Types to Secure Objects“ inBusiness Administrator's Guide.

Control Access to Rules that Reference More Secure Rules

Users can call, view, and modify the content of a secure rule if they have been given access to a rule that references that secure rule.

Identity Manager runs an authorization check in which a wrapper calls all of the users who have a right to edit that rule. Authorized users can use that rule to call other rules without further authorization checking, which can give them indirect access to secure rules.

When you create a rule that references a secure rule and give users access rights to the less secure rule, be careful that you are not inadvertently giving them inappropriate access to the secure rule.

To create a rule that references a more secure rule, you must control both organizations containing those rules. You also must have rights to run the first rule and call the secure rule.