Policies are logical and testable rules to maintain security and consistency within your Access Manager infrastructure. You can specify activation criteria, deactivation criteria, temporal constraints (such as time of day or subnet), identity constraints (such as user object attribute values), and additional separation-of-duty constraints. Identity information can come from any identity source (such LDAP, an Identity Vault, or a directory) or from the Access Manager’s Identity Server, which provides full Liberty Alliance specification support and SAML 2.0 support. Identity is available throughout the determination of rights and permissions.
Access Manager uses the policy type to define the context within which a policy is evaluated. Each type of policy differs in purpose, which in turn determines the conditions and actions that apply. For example, the conditions and actions of an Authorization policy differ from the conditions and actions of an Identity Injection policy.
When you click New on the Policies page, the system displays the predefined policy types in a drop-down list. Each policy type represents the set of conditions and actions that are available. You then configure rules to determine user roles, make decision requests, and enforce authorization decisions. You can also set up policies with no conditions, allowing actions to always take place. As policies and conditions become complex, it can be simpler and more manageable to design policies with conditions that deny or restrict access to large groups of users, rather than setting up policies that permit access to certain users.
Access Manager has the following policy types:
Access Gateway: Authorization: This policy type is used to permit or deny access to protected resources, such as Web servers. After you have set up the protected resource, you use the policy rules to define how you want to restrict access. For example, if a user is denied access to a resource, you can use the policy to redirect them to a URL where they can request access to the resource.
Access Gateway: Identity Injection: This policy type evaluates the rules for Identity Injection, which retrieves identity data from a data source (user store) and forwards it to Web applications. Such a policy can enable single sign-on. After the user has authenticated, the policy supplies the information required by the resource rather than allowing the resource to prompt the user for the information.
Access Gateway: Form Fill: This policy type creates a policy that automatically fills in the information required in a form, after the form is filled the first time. Use this policy to configure single sign-on for resources that require form data and for injecting JavaScript to an HTML page. You can also use this policy for injecting JavaScript to HTML pages.
Identity Server: Roles: This policy type evaluates rules for establishing the roles of an authenticated user. Roles are generated based on policy statements each time a user authenticates. Roles are placed into an Authentication Profile, which can be used as input in policies for Authorization or Identity Injection.
Identity Server: External Attribute Source: This policy type is used to create a policy that retrieves the attributes from external sources.
Authorization and Identity Injection policies allow you to select conditions, one of which is Roles. If you have thousands of users accessing your resources, you might want to design most of your policies to use roles. Roles are evaluated when a user logs in, and the roles assigned to the user are cached as long as the session is active. When the user accesses a resource protected by a policy that uses role conditions, the policy can be immediately evaluated because the user’s role values are available. This is not true for all conditions; the values for some conditions must be retrieved from the user store. For example, if the policy uses a condition with an LDAP attribute, the user’s value must be retrieved from the LDAP user store before the policy can be evaluated. On a system with medium traffic, this delay is not noticed. On a system with high traffic, the delay might be noticeable.
However, you can design your policies to have the same results without retrieving the LDAP attribute value at resource access. You can create a Role policy for the LDAP attribute and have users assigned to this role at authentication when they match the attribute value requirements. When users access resources, they gain immediate access or are immediately denied access because their role assignments are cached.
If the same LDAP attribute policy is used to grant access to multiple resources, chances that a user notices a delay are minimal. The first time a policy is evaluated for a user, the data required for the policy is cached and is therefore immediately available the next time it is requested.
Another option available for LDAP, Credential Profile, Liberty User Profile, and Shared Secret attributes is to have the attribute values sent with the assertion at authentication. You configure an attribute set for the attributes, and then configure the service provider for these attributes. For more information, see Configuring the Attributes Sent with Authentication.
As you design your policies, experiment and find the type that works best for your network and your customers.
In the Administration Console, click Policies > Policies.
In the Policy Container drop-down list, select the container.
If you have not created any containers, only the Master_Container is available in the list.
You can perform the following tasks from this page:
Before creating policies, you need to design your policy strategy. For example, if you are going to use role-based access, you need to decide which roles you need and which roles allow access to your protected resources. Roles, which are used by Authorization policies that grant and deny access, need to be created first. If you have already created the roles and assigned them to users in your LDAP user store, you can use the values of your role attributes in the Authorization policies rather than using Access Manager roles.
To create a policy, see the following sections:
Policies can be sorted by name and by type. On the Policies page, click Name in the Policy List, and the policies are sorted alphabetically by name. To sort alphabetically by type, click Type in the Policy List.
You can also use containers to organize your policies. For more information, see Section 6.1.4, Managing Policy Containers.
A policy cannot be deleted as long as a resource is configured to use the policy. This means that you must remove the policy from all protected resources for the Access Gateway.
Roles can be used by Authorization, Form Fill, and Identity Injection policies. Before you can delete a Role policy, you must remove any reference to the role from all other policies.
Copy: To copy a policy, select a policy, click Copy, then click OK. The new policy is named “Copy of ...” This is useful when you are creating multiple policies that require only minor variations to make them unique. You should rename the policy after making these modifications.
Rename: To rename a policy, select a policy, click Rename, specify a new name, then click OK.
Policies that are created in the Administration Console can be exported and used in another Administration Console that is managing a different group of Access Gateways and other devices. Each policy type has slightly different import requirements. See the following:
If you have made changes in policy assignments that are not reflected on the page, click Refresh References. This action can take a while to complete if you have numerous policies and have assigned them to protect numerous resources. The Administration Console needs to verify the configuration of each device.
If you have made changes in policy assignments that are not reflected on the page, click Refresh References. This action can take a while to complete if you have numerous policies and have assigned them to protect numerous resources. The Administration Console needs to verify the configuration of each device.
The Policy List table displays the following information about each policy:
|
Column |
Description |
|---|---|
|
Name |
Displays the name of the policy. To modify a policy, click its name. |
|
Type |
Specifies the type of policy (Authorization, Identity Injection, Roles, or Form Fill) and the type of resource that can use it (Identity Server or Access Gateway). |
|
Used By |
Displays the name of the Access Gateway or the Identity Server configuration that the policy is assigned to. If the policy is unassigned, this column has no value. If the policy is assigned to a protected resource, click the down-arrow button to view the names of the resources it has been assigned to. |
|
Extensions Used |
Specifies whether the policy uses any extensions. If none has been used, this column has no value. |
|
Description |
Displays a description of the policy. If no description has been specified, this column has no value. |
You use policy containers to store and organize policies, similar to how you organize files in folders. The Master_Container is a permanent policy container, but you can use the Containers tab to create new containers.
A policy container can hold up to 500 policies. When you reach that limit, you must create another container to add, copy, or import policies. For performance and for ease in finding a policy, you might want to limit a container to 200 or fewer policies. Policies in a container can be sorted by name and type, to aid you in finding a particular policy.
If you have only one administrator configuring and managing policies, you can create additional policy containers to help you keep policies organized. If you have multiple administrators creating policies, you can create a container for each administrator to use. This allows multiple administrators to modify policies at the same time. When an administrator opens a policy in a container, the container is locked, which prevents other administrators from modifying any policies in that container until changes are applied or canceled.
In the Administration Console, click Policies >Containers.
On the Containers page, click New.
Name the policy container, then click OK.
Click Close.
After you add a policy container, the system displays it in the Policy Container drop-down list on the Policy List page.
You must delete all the policies in a policy container before you can delete the policy container.
Select the check box of the policy container. Click Delete.A Confirm dialog box displays a message "Number of Containers selected: 1, Delete selected Containers?"
Click Ok to continue or Cancel to close the window
You configure rules to create a policy. The rules collectively represent a desired course of action when the required conditions are met, such as denying entry-level employees access to a secure Web site, and permitting access for employees who have a role of Manager.
When the system evaluates the policy conditions, it begins with the rule with the highest priority and evaluates the conditions, starting with the first condition group in the rule. Each rule contains one or more conditions and one or more actions. If a rule’s conditions are met, the rule’s action is performed. For some policy types, the performance of any rule’s action terminates the policy evaluation. With Authorization policies, for example, after the policy has determined that a user is either permitted or denied access to a resource, there is no reason to evaluate the policy further. However, a Role policy might identify multiple roles to which a user belongs. In this case, each rule of the policy must be evaluated to determine all roles to which the user belongs.
IMPORTANT:The interface for the policy engine is designed for flexibility. It does not protect you from creating rules that do nothing because they are always true or always false. For example, you can set up a condition where Client IP is equal to Client IP, which is always true. You are responsible for defining the condition so that it does a meaningful comparison.
To manage the list of rules for a policy:
In the Administration Console, click Policies > Policies.
Select the container.
Click the name of the policy.
In the Rule List section, select one of the following:
New: To create a new rule, click New.
You use multiple rules to coordinate how a policy operates, and the behavior varies according to the policy type. To understand how multiple rules are evaluated, see the following:
Delete: Select a rule, then click this option to delete the rule. If the policy has only one rule, you cannot delete the last rule.
Copy: Select a rule, then click this option to copy a rule. To modify the copy, click the rule number.
Enable: Select a rule, then click this option to enable a rule.
Disable: Select a rule, then click this option to disable a rule.
Click OK, then click Apply Changes.
A Role policy is used to determine which role or roles a user is assigned to. However, you can specify only one role per rule. Role policies are evaluated when a user authenticates. Role policies do not directly deny or allow access to any resource, nor do they determine if a user is authenticated. A user’s role can be used in the evaluation of an Authorization policy, but at that point the evaluation of the role policy has already occurred and is not directly part of the authorization process. The performance of an action (assigning a user to a role) does not terminate the evaluation of the policy, so subsequent rules in the policy continue to be evaluated.
When the Access Gateway discovers a rule in an Authorization policy that either permits or denies a user access to a protected resource, it stops processing the rules in the policy. Use the following guidelines in determining whether your Authorization policy needs multiple rules:
If the policy enforces multiple access requirements that can result in differing actions (either permit or deny), use separate rules to define the conditions and actions.
If you want other conditions or actions processed when a rule fails, you must create a second rule for the users that fail to match the conditions.
If you create multiple rules, you can modify the order that the rules are processed. This allows you to create policies that contain a number of Permit rules that allow access if the user matches the rule. The lowest priority rule in such a policy is a Deny rule, which denies access to everyone who has not previously matched a Permit rule.
IMPORTANT:If you create policies with multiple Permit rules, you should make the last rule in the policy a generic deny policy (a rule with no conditions and with an action of deny). This ensures that if the Result on Error Condition field in a rule is set incorrectly, the user matches the last rule and is denied access. Without this rule, a user might gain access because the user didn’t match any of the rules.
You can also create a number of policies and enable multiple policies for the same protected resource. Rule priority determines how the enabled policies interact with each other. The rules in the policies are gathered into one list, then sorted by priority. The processing rules are applied as if the rules came from one policy. It is a personal design issue whether you create a policy with multiple rules or create multiple policies that you enable on a single protected resource. Either design produces a list of rules, sorted by priority, that is applied to the user requesting access to the protected resource.
Rules in Identity Injection and Form Fill policies have actions, but no conditions. Because they have no conditions, all the rules are evaluated and the actions are performed. Identity Injection policies have two exceptions to this rule; they can insert only one authentication header and one cookie header. If you create multiple rules, each with an authentication header and a cookie header, the rule with the highest priority is processed and its actions performed. The actions in the second rule for injecting an authentication header and a cookie header are ignored.
You cannot create multiple rules for a Form Fill policy.
The policy view administrators can view the information related to rules.The rules collectively represent a desired course of action when the required conditions are met, such as denying entry-level employees access to a secure Web site, and permitting access for employees who have a role of Manager.
When the system evaluates the policy conditions, it begins with the rule with the highest priority and evaluates the conditions, starting with the first condition group in the rule. Each rule contains one or more conditions and one or more actions. If a rule’s conditions are met, the rule’s action is performed. For some policy types, the performance of any rule’s action terminates the policy evaluation.
To view the list of rules for a policy:
In the Administration Console, click Policies > Policies.
Select the container.
Click the name of the policy.
In the Rule List section, the policy view administrator can view the following details.:
Type: Displays the type of the policy.
Description: Displays the description of the policy type.
Priority: Displays the priority of the rule number to the policy type.
Actions: Displays the actions for the policy type.
If Access Manager does not supply the action, the data type, or the condition that you need for a policy, you can add a customized policy extension. For example, suppose you need a policy that permits access based on whether a user has a specific role which is assigned to users in an Oracle database. The custom extension could read the role assignments of the user from the Oracle database and return a string containing the role names. This data could then be used to determine access rights to Access Manager resources.
For information about how to create a policy extension, see the NetIQ Access Manager 4.0 Developer Kit.
After a policy extension has been created, you need to perform the following tasks to use the extension:
After you have configured the extension, you can perform the following tasks:
The policy extension can be delivered as either a .jar file or a .zip file.
To install an extension, you need to have access to the .jar file and know the following information about the extension or extensions contained within the file:
|
What you need to create |
|
|
What you need to know |
|
|
Authorization Policy: Can be used to return the following:
Identity Injection Policy: A data extension that retrieves data for injecting into a header. Identity Role Policy: Can be used to return the following:
External Attribute Source Policy: A data extension that retrieves attributes from external sources. |
If the file contains more than one extension, you need to create a configuration for each extension in the file.
Copy the .jar file to a location that you can browse to from the Administration Console.
In the Administration Console, click Policies > Extensions.
To upload the file, click Upload > Browse, select the file, then click Open.
(Conditional) If you want this .jar file to overwrite an existing version of the file, select Overwrite existing *.jar file.
Click OK.
The file is uploaded to the Administration Console, but nothing is visible on the Extensions page until you create a configuration.
To create an extension configuration, click New, then fill in the following fields:
Name: Specify a display name for the extension.
Description: (Optional) Specify the purpose of the extension and how it should be used.
Policy Type: From the drop-down list, select the type of extension you have uploaded.
Type: From the drop-down list, select the data type of the extension.
Class Name: Specify the name of the class that creates the extension, such as com.acme.policy.action.successActionFactory.
File Name: From the drop-down list, select the .jar file that contains the Java class that implements the extension and its corresponding factory. This should be the file you uploaded in Step 3.
Click OK.
(Conditional) If the extension requires data from Access Manager, click the name of the extension.
In the Configuration Parameters section, click New, specify a name and ID, then click OK.
The developer of the extension must supply the name and ID that the extension requires.
In the Mapping column, click the down-arrow, then select the required data type.
The developer of the extension must supply the data type that is required. If the data type is a data string, then the developer needs to explain the type of information you need to supply in the text field.
(Conditional) If the extension requires more than one data item, repeat Step 9 and Step 10.
Click OK.
The extension is now available for the policy type it was created for.
(Conditional) If the class can be used for multiple policy types, you need to create an extension configuration for each policy type.
For example, if an extension can be used for both an Identity Injection policy and a Role policy, you need to create an entry for both. The File Name option should contain the same value, but the other options should contain unique values.
Continue with Distributing a Policy Extension.
A .zip file with an exported extension contains both the .jar file and the extension configuration.
Copy the .zip file to a location that you can browse to from the Administration Console.
In the Administration Console, click Policies > Extensions.
To upload the file, click Upload > Browse, select the file, then click Open.
(Conditional) If you want the .jar file in the import to overwrite an existing version of the file, select Overwrite existing *.jar file.
Click OK.
The extension is imported in the Administration Console.
(Conditional) If the extension requires some customizing, click the name of the extension and follow the instructions that came with the extension.
Continue with Distributing a Policy Extension.
To distributed the policy extension to the devices that need it:
Create a policy that uses the extension:
Role Policy: To create a Role policy that uses the extension, see Section 6.2.3, Creating Roles.
Identity Injection Policy: To create an Identity Injection policy that uses the extension, see Section 6.4.2, Configuring an Identity Injection Policy.
Authorization Policy: To create an Authorization policy that uses the extension, see Section 6.3.2, Creating Access Gateway Authorization Policies.
External Attribute Source Policy: To create an External Attribute Source policy that uses the extension, see Section 6.6, External Attribute Source Policies.
Assign the policy to a device:
For a Role policy, enable it for an Identity Server.
For more information, see Section 6.2.7, Enabling and Disabling Role Policies.
For an Authorization policy, assign it to a protected resource.
For more information, see Assigning an Authorization Policy to a Protected Resource.
For an Identity Injection policy, assign it to a protected resource.
For more information, see Assigning an Identity Injection Policy to a Protected Resource.
For an External Attribute Source policy, enable it for an Identity Server.
For more information, see Section 6.6.1, Enabling External Attributes Policy.
IMPORTANT:Do not update the device at this time. The .jar files must be distributed before you update the device.
Distribute the .jar files:
Click Policies > Extensions.
Select the extension, then click Distribute JARs.
Restart Tomcat on the devices listed for reboot.
Linux: Enter the following commands:
In the Access Gateways: /etc/init.d/novell-mag restart.
In the Identity Servers: /etc/init.d/novell-idp restart.
Windows: Enter the following commands:
net stop Tomcat7
net start Tomcat7
(Conditional) If the extension is for an Authorization policy or an Identity Injection policy, update the Access Gateway.
In the Administration Console, click Policies > Extensions.
To export a policy extension, select the policy, then click Export.
To delete an extension, a policy cannot be using it. Use the Used By column to determine the policies that are using the extension. Modify the listed policies. When the extension is no longer used by any policies, select the extension, then click Delete.
To rename a policy extension, select the extension, click Rename, specify a new name, then click OK. When a policy extension is renamed and the extension is in use by a policy, the policy is updated. This causes the Apply Changes button to be active on the Policy List page.
You can modify the details of an existing extension and control the information Access Manager provides to the extension when the data is evaluated.
In the Administration Console, click Policies > Extensions.
Click the name of the extension.
You can view or modify the following details:
Description: (Optional) Specifies the purpose of the extension and how it should be used.
Class Name: Specifies the name of the class that creates the extension, for example com.acme.policy.action.successActionFactory.
File Name: Specifies the .jar file that contains the Java class that implements the extension and its corresponding factory. Select the appropriate file from the drop-down list.
(Conditional) Specify the Condition Parameters required by the extension.
The documentation for the extension should tell you the number of parameters it requires and the data type of each parameter. You create the name and ID for the parameter, and they need to be unique for the extension.
To add a configuration parameter, click New, enter a name (a string) and an ID (a number) for the parameter, then click OK. In the Mapping field, click the down-arrow, then select the data item from the list. The selected data is available whenever the extension class is called to evaluate an action, a condition, or data.
To delete a configuration parameter, select the parameter, then click Delete.
Click OK.
Policy logging is expensive; it uses processing time and disk space. In a production environment, you should enable it only under the following types of conditions:
You have created a new policy and need to verify its functionality.
You are troubleshooting a policy that is not behaving as expected.
To gather troubleshooting information, you should enable the File Logging and Echo To Console options in the Identity Server configuration and set the Component File Logger Levels for Application to at least info. Then you must update the Identity Server configuration and restart any Access Gateway Embedded Service Providers, so that the Embedded Service Providers read the logging options. See Section 17.3.1, Configuring Logging for Identity Server. When you have solved the problem, you should disable these options.
The log file on the component that executed the policy is where you should look for logging information. For example, if you have an Access Gateway: Authorization error, look at the log on the Access Gateway that executed the policy.
For additional policy troubleshooting procedures, see Section 26.7, Troubleshooting Access Manager Policies.