6.4 Implementing Access Restrictions

After you access the Digital Airlines site as a public resource (see Section 6.3, Configuring Public Access to Digital Airlines), you can configure the site for authentication and authorization requirements. This section describes the following tasks:

6.4.1 Enabling an Authentication Procedure

After hiding the internal Web server behind the Access Gateway, you can add an authentication method to the Web site by using the following procedure:

  1. In the Administration Console, click Devices > Access Gateways > Edit.

  2. Click DAL > Dallistener > Protected Resources > everything.

  3. In the Authentication Procedure field, select Name/Password - Form.

    IMPORTANT:Make sure to select the Name/Password - Form from the drop-down menu. Secure Name/Password does not work correctly if the base URL for the Identity Server is HTTP.

  4. Click OK to return to the Protected Resources page.

  5. Click Devices > Access Gateways, then click Update > OK.

    This pushes the new configuration to the server. When the configuration process is complete, the status returns to Current.

  6. To test the results, open a browser and enter the URL of your Web site.

    The Web site should now be protected and require you to log in by using a name and password.

  7. Enter the credentials of the admin user of your Administration Console.

    The Digital Airlines site appears. If you receive an error, see Common Authentication Problems.

  8. Close all sessions of the browser.

    The Digital Airlines page has a logout graphic, but it isn’t an action. The current session is active until you log out (which isn’t possible), until the session times out (the default value is 20 minutes), or you close all sessions of the browser.

  9. Continue with Section 6.4.2, Configuring a Role-Based Policy.

Common Authentication Problems

In this basic configuration there are two common configuration errors that can cause login to fail:

Error 300101015: If your Access Gateway and Identity Server do not have the same time, the assertion is invalid. Check the time of each machine.

Errors 100101043 and 100101044: The Identity Server and the Access Gateway need to be able to resolve each other’s DNS names. If you are in a lab and not using a DNS server, make sure the host files of each machine have been configured to resolve the DNS name to the IP address of the device.

The other cause for these errors, when SSL has not been enabled, is the failure to update either the Identity Server or the Access Gateway after making a change to the base URL of the Identity Server or modifying the Identity Server the Access Gateway is trusting for authentication. For information on how to force the Access Gateway to update the metadata for the Identity Server, see Embedded Service Provider Metadata in the Novell Access Manager 3.1 SP2 Identity Server Guide.

6.4.2 Configuring a Role-Based Policy

Previously in the Digital Airlines example, you learned how to set up and configure Access Manager to protect a basic Web service. Access Manager also uses role-based access control (RBAC) to conveniently assign a user to a particular job function or set of permissions within an enterprise, in order to control access.

Access Manager enables you to assign roles to users, based on attributes of their identity, and then associate policies with the roles. In designing your own actual production environment, you need to decide which roles you need (such as, sales, administrative, and accounting). You create Role policies that assign the roles to your users, and then you create Authorization and Identity Injection policies that use the roles to control access.

This section explains how to set up an Identity Injection policy that customizes the main page of the Digital Airlines site. When the index.php page has access to the user’s name, the main page displays the name. If the user belongs to the sales_role role, the Sales System button is displayed on the page.

To configure an Identity Injection policy that uses a role, complete the following tasks:

Adding an LDAP Attribute to Your Configuration

The LDAP attribute that is added in this section is an LDAP attribute assigned to the User class in eDirectory. This attribute is used to assign users to the sales role.

  1. In the Administration Console, click Devices > Identity Servers, then click Shared Settings > Custom Attributes.

  2. In the LDAP Attribute Names section, click New, type description in the Name field, then click OK.

    This adds the description attribute to the policy list of available LDAP attributes, and you can use this attribute to assign a role to your users.

  3. Click Close.

  4. Continue with Creating a Sales Role.

Creating a Sales Role

Use the following procedure to create a sales role for the Digital Airlines example. (For more information about Role policies, see Creating Role Policies in the Novell Access Manager 3.1 SP2 Policy Guide.)

  1. In the Administration Console, click Devices > Identity Servers, then click Edit > Roles.

  2. In the Roles Policy List section, click Manage Policies.

  3. In the Policy List section, click New, then fill in the following fields:

    Name: Specify Sales_Role.

    Type: Select Identity Server: Roles.

  4. Click OK to open the policy editor.

  5. In Condition Group 1, click New > LDAP Attribute, and assign the following values:

    LDAP Attribute: Select description. (If description is not included in the LDAP Attribute list, you can add it from this page. For instructions, see Step 5.a through Step 5.c.)

    Comparison: Select String: Contains Substring.

    Mode: Select Case Insensitive.

    Value: Select Data Entry Field (from the drop-down box); specify Sales as the value.

    Result on Condition Error: Select False.

    If the description attribute is not listed in the LDAP Attribute drop-down menu, create it by following this procedure:

    1. In Condition Group 1, click New > LDAP Attribute, scroll to the bottom of the list, then click New LDAP Attribute.

    2. In the Name field, specify description, then click OK.

    3. In the LDAP Attribute field, select description from the drop-down menu.

  6. In the Actions section, click New > Activate Role, then specify sales_role in the Do Activate Role field. Your rule should look similar to the following:

    The value for Activate Role might be case sensitive. If you are going to inject this role into a policy for a Web server, and the page on the Web server is configured so that it evaluates case, make sure the value entered here matches what is expected on the Web server. The Sales System button on the Digital Airlines site requires that this value be lowercase: sales_role.

  7. Click OK to close the Rule editor, then click OK to close the Rule List.

  8. To save the Role policy, click Apply Changes, then click Close to return to the Roles Policy List.

  9. In the Roles Policy List, select Sales_Role, then click Enable.

  10. Click OK.

  11. Update the Identity Server.

    Wait for the Status to return to Current.

  12. Continue with Creating a New User with a Sales Role.

Creating a New User with a Sales Role

After you have created a user policy, only users provisioned with that policy can access the protected Web resource. This section describes how to create a user that meets the conditions to be assigned the Sales role. These instructions assume that you are using the configuration store of the Administration Console as the LDAP user store. If you are using a different server than the LDAP user store, you need to modify these instructions:

  1. In the Administration Console, click the Roles and Task icon in the top menu bar.

  2. Click Users.

  3. Click Create User, then fill in the following fields:

    Username: Specify Tom.

    First name: Specify Tom.

    Last name: Specify Tester.

    Context: Click the Object Selector icon, then click novell. The user is automatically assigned the context of novell.

    Password: Assign a password to the user.

    Retype password: Retype the assigned password.

    Your user entry should look similar to the following:

  4. Scroll to the Description field, then click the + icon.

  5. In the Add text box, type Sales (initial uppercase), then click OK to return to the Create User page.

  6. On the Create User page, click OK, then click OK to close the Create User task.

    Tom meets the requirements to be assigned the Sales role when he logs in.

  7. Continue with Creating the Identity Injection Policy for a Custom Header.

Creating the Identity Injection Policy for a Custom Header

The following policy injects the user’s roles and DN into a custom header. The index.php page reads this information and uses it to display the user’s name. If the user is assigned the sales_role, the Sales System button is displayed on the main page.

  1. In the Administration Console, click the Access Manager icon in the top menu bar.

  2. Click Devices > Access Gateways, then click Edit > DAL > Dallistener > Protected Resources > everything.

  3. Click Identity Injection > Manage Policies.

  4. In the Policy List section, click New, then fill in the following:

    Name: Specify Custom_Injection.

    Type: Select Access Gateway: Identity Injection.

  5. In the Actions section, click New > Inject into Custom Header.

  6. To inject the user’s name, fill in the following values:

    Custom Header Name: Specify X-Name.

    Value: Select Credential Profile. The LDAP Credentials: LDAP User Name is selected automatically for you.

  7. To inject the user’s roles, click New > Inject into Custom Header, then fill in the following values for the second custom header:

    Custom Header Name: Specify X-Role.

    Value: Select Roles.

    Your policy should look similar to the following:

  8. Click OK twice, then click Apply Changes.

  9. Click Close.

  10. In the Identity Injection Policy List section, select Custom_Injection, then click Enable.

  11. Click OK.

  12. Click Devices > Access Gateways, then click Update > OK.

  13. To test Tom’s access rights, complete the following steps:

    1. Open a new browser, then enter the URL of the Digital Airlines Web site you created.

      In this example, it is am3bc.provo.novell.com.

    2. When prompted for user ID and password from Access Manager, log in with Tom’s credentials.

      The page appears with a Welcome: Tom message at the top, and the Sales System button appears in the lower right corner of the page.

    3. Click the Sales System button, and the Sales page appears.

      If the Sales System button does not appear, Tom was not assigned the sales_role:

      • Verify that the role policy is enabled for the Identity Server by clicking Policies > Policies, and confirm that the Identity Server is listed in the Used By column for the policy.

      • On the Policies page, confirm that the Access Gateway is listed in the Used By column for the Identity Injection policy.

      • Discover whether there was an error in the Role policy evaluation. Click Auditing > General Logging, then download the catalina.out (Linux) or the stdout.log (Windows) file for the Identity Server. Search for the name of the role policy and determine whether the role was successfully assigned.

      • Determine whether there was an error in Identity Injection policy evaluation. Click Auditing > General Logging, then download the catalina.out (Linux) or the stdout.log (Windows) file for the Access Gateway. Search for the name of the Identity Injection policy and determine whether its values were successfully injected.

      For more information about troubleshooting policies, see Troubleshooting Access Manager Policies in the Novell Access Manager 3.1 SP2 Policy Guide.

    4. Close all sessions of the browser.

  14. To test that the sales_role is required for the Sales System button to appear, complete the following steps:

    1. Open a new browser, then enter the URL of the Digital Airlines Web site you created.

      In this example, it is am3bc.provo.novell.com.

    2. Log in as the admin user. The page should have a Welcome: admin at the top of the page, but the Sales System button should not appear.

    3. To the URL, add /sales, and the Sales page appears.

      This illustrates that although the link is hidden, the Sales page is not protected.

    4. Close all sessions of the browser.

  15. Continue with Section 6.4.3, Assigning an Authorization Policy to Protect a Resource.

6.4.3 Assigning an Authorization Policy to Protect a Resource

Use the following procedure to limit access to the Sales page based on the sales role:

  1. In the Administration Console, click Devices > Access Gateways, then click Edit > DAL > Dallistener > Protected Resources.

  2. In the Protected Resource List, click New, specify sales_page for the name, then click OK.

  3. For the Authentication Procedure, select Name/Password - Form.

  4. In the URL Path List, click /*, modify it to specify /sales/*, then click OK.

    Your protected resource should look similar to the following:

  5. Click Authorization > Manage Policies.

  6. Click New, then fill in the following fields:

    Name: Specify Allow_Sales.

    Type: Select Access Gateway: Authorization.

  7. Click OK.

    The Edit Policy page appears.

  8. In Condition Group 1, click New > Roles, then specify the following values:

    Comparison: Select String: Contains Substring.

    Mode: Select Case Insensitive.

    Value: Select Roles: sales_role.

    Return on Condition Error: Select False.

  9. In the Actions section, ensure that Permit is selected.

    Your rule should look similar to the following:

    This rule allows everyone assigned to the sales_role to have access.

  10. Click OK.

  11. In the Rule List, select New.

    This second rule is a general deny rule for everyone who has not been assigned the sales_role.

  12. Make sure the Priority field is set to 10 and that the Condition Group 1 has no conditions.

  13. In the Actions section, click Permit, select Deny, then select Deny Message.

  14. Click Message Text, then in the text box, type the deny message: Sorry, you must work in sales today.

    Your rule should look similar to the following.

    With no conditions in the condition group, this creates a general deny rule that matches everyone. The users who have been assigned the sales role match the first rule that is processed. Everyone else matches this general deny rule.

  15. Click OK to close the rule editor, then click OK to close the Rule List.

  16. In the Policy List window, click Apply Changes, then click Close.

  17. In the Authorization Policy List, select the Allow_Sales policy, then click Enable.

  18. Click OK.

  19. Click the Access Gateways link, then click Update > OK.

  20. Test the results:

    1. Open a new browser, then enter the URL of the Digital Airlines Web site you created.

      In this example, it is am3bc.provo.novell.com.

    2. Log in as the admin user.

    3. Add /sales to the URL.

      You should receive the following response window with the message derived from the Access Gateway you just configured:

      Now, only users with an assigned sales role can access the Sales page.

  21. Test the results with a user who has the sales role:

    1. Open a new browser, then enter the URL of the Digital Airlines Web site you created.

      In this example, it is am3bc.provo.novell.com.

    2. Log in as Tom.

    3. Click the Sales System button or add /sales to the URL.

      The Sales page is displayed.

    4. Close all sessions of the browser.

  22. Continue with Section 6.4.4, Configuring an Identity Injection Policy for Basic Authentication.

6.4.4 Configuring an Identity Injection Policy for Basic Authentication

A common way to protect Web resources is to configure the Web server to require basic authentication for accessing a resource. The Web is configured to check for the user’s name and password in the HTTP authentication header. If you have Web resources with this type of configuration, you can enable single sign-on to these resources by creating a policy that injects the username and password into the HTTP authentication header.

This section explains how to set up the /sales directory to require basic authentication, and then how to create the Identity Injection policy.

Configuring the Web Server for Basic Authentication

It is difficult to create a configuration on the Apache Web server that provides consistent results by using LDAP SSL for basic authentication. Because this is a tutorial and is expected to be implemented in a testing environment, the following steps explain how to configure Apache to allow for a clear-text password over LDAP and how to configure basic authentication in this environment. The purpose of this section is not to explain how to configure Apache, but to explain how you can enable single sign-on for Web resources that require basic authentication.

Enabling LDAP Clear-Text Passwords

To turn off the SSL requirement on the internal LDAP user store:

  1. Log in to the Administration Console.

  2. Click the View Objects icon in the top menu bar.

  3. Click Search, then configure the following fiels.

    Context: Accept the default [root] value and leave the Search sub-containers option enabled.

    Name: Accept the default wildcard value.

    Type: Select LDAP Group from the list.

  4. In the Results section, click the LDAP Group - <your server name> object, then select Modify Object.

  5. Select the LDAP Allow Clear Text Password attribute, then click Edit.

  6. Select the check box, then click OK.

  7. Click OK or Apply at the bottom of the page.

    If you do not click one of these buttons, your modifications are not saved.

  8. To return the Administration Console machine to its default view, click the Access Manager icon in the top menu bar.

  9. From a terminal window on the Administration Console machine, log in as root.

  10. Restart eDirectory with the following command:

    /etc/init.d/ndsd restart
Enabling Basic Authentication

You need to enable the Apache server to require basic authentication for the /sales directory. On SLES 10.x or SLES 11, you need to enable two authentication modules and modify an Apache configuration file.

  1. At the Apache server machine, log in to YaST.

  2. Click Network Services > HTTP Server > Server Modules.

  3. Scroll down, then enable the ldap and authnz_ldap modules.

  4. Click Finish.

  5. In a text editor, open the /etc/apache2/httpd.conf file.

  6. Add the following section to the end of the file:

    <Directory "/srv/www/htdocs/sales">
   Options Indexes FollowSymLinks
   AllowOverride None
   order allow,deny
   allow from all
   AuthType Basic
   AuthName Internal
   AuthBasicAuthoritative off
   AuthBasicProvider ldap
   AuthzLDAPAuthoritative off
   AuthLDAPURL ldap://127.0.0.1/o=novell?uid??(objectclass=*)
   require valid-user
   AuthLDAPBindDN cn=admin,o=novell
   AuthLDAPBindPassword novell
</Directory>

    Replace the information in the AuthLDAPURL line with the information the IP address of your LDAP user store. Modify the query string to match your user store. This sample line assumes that the Web server and your LDAP user store are installed on the Administration Console, and 127.0.0.1 is its internal address.

    The AuthLDAPBindDN and AuthLDAPBindPassword contain the distinguished name of a user and that user’s password. This user needs sufficient rights to log in to the LDAP user store and to search for the users in the tree.

  7. Restart the Apache server with the following command:

     /etc/init.d/apache2 restart

  8. To test that the /sales directory now requires basic authentication:

    1. Open a new browser, then enter the URL of the Digital Airlines Web site you created.

      In this example, it is am3bc.provo.novell.com.

    2. Log in using the credentials for Tom.

      Even though Tom has logged in and been assigned the correct role, he is prompted to log in again to access the /sales directory. To enable single-sign on, you must create an Identity Injection policy that injects Tom’s credentials into the authentication header.

  9. Continue with Creating an Identity Injection Policy for Basic Authentication.

Creating an Identity Injection Policy for Basic Authentication

This section explains how to enable single sign-on by creating an Identity Injection policy that injects the user’s authentication credentials into a header. The Web server uses the credentials in the authentication header to satisfy its login requirements.

  1. In the Administration Console, click Devices > Access Gateways, then click Edit > DAL > Dallistener > Protected Resources.

  2. In the Protected Resource List, click sales_page.

  3. Click Identity Injection > Manage Policies > New.

  4. For the new policy, fill in the following fields:

    Name: Specify Basic_Auth for the name.

    Type: Select Access Gateway: Identity Injection for the type.

  5. Click OK.

  6. In the Actions section, click New, select Inject into Authentication Header, then select the following values:

    User Name: Select Credential Profile. The LDAP Credentials: LDAP User Name value is automatically selected for you. This credential is the cn attribute of the user.

    Password: Select Credential Profile. Click LDAP Credentials: LDAP User Name, then select LDAP Credentials > LDAP Password.

    Your policy should look similar to the following:

  7. Click OK to close the policy editing page, then click OK to close the Rule List page.

  8. In the Policy List page, click Apply Changes, then click Close.

  9. Select the Basic_Auth check box, click Enable, then click OK.

  10. Click OK to return to the Protected Resource List. Your list should look similar to the following:

  11. To save your configuration changes, click the Access Gateways link, then click Update > OK.

  12. To test the configuration:

    1. Open a new browser, then enter the URL of the Digital Airlines Web site you created.

      In this example, it is am3bc.provo.novell.com.

    2. Log in as Tom.

      The Digital Airlines site should appear with the Sales System button.

    3. Click the Sales System button. You should have access to the Sales System site, as shown below:

      For more information about Identity Injection policies, see Creating Identity Injection Policies in the Novell Access Manager 3.1 SP2 Policy Guide.

    4. Close all sessions of the browser.

  13. Continue with Section 6.4.5, Initiating an SSL VPN Session.

6.4.5 Initiating an SSL VPN Session

This section explains how to initiate an SSL Virtual Private Network (VPN) connection in the Digital Airlines example. The SSL VPN agent provides secure access to non-HTTP applications.

Before performing this task, you must have the SSL VPN server installed. Your Access Manager console should appear similar to the green state shown in Figure 6-3:

Figure 6-3 Dashboard Indicating the Status of Access Manager Components

The yellow status of the SSL VPN indicates that it has not been configured. For more information about installing the SSL VPN server, see the Novell Access Manager 3.1 SP2 SSL VPN Server Guide.

For the Digital Airlines example, perform the following tasks:

Configuring the ESP-Enabled SSL VPN

You can configure SSL VPN installed along with the Identity server for authentication as follows:

  1. In the Administration Console, click Devices > SSL VPNs.

  2. Click Edit to modify the configuration of the server.

  3. In the Basic Gateway Configuration section, click Authentication Configuration.

  4. Fill in the following fields:

    Identity Server Cluster: Select the configuration you have assigned to the Identity Server.

    This sets up the trust relationship between the SSL VPN server and the Identity Server that is used for authentication.

    Authentication Contract: Select the Name/password - Form option.

    Embedded Service Provider Base URL: This is the application path for the Embedded Service Provider. This needs to be DNS name of the machine with the port and the application path used by the SSL VPN server. For example, http://nam.provo.novell.com:8080/sslvpn, where nam.provo.novell.com is the DNS name of the machine.

  5. Restart the Tomcat server when prompted.

  6. To save your modifications, click OK twice, then click Update on the server page.

  7. Click Update on the Identity Server page.

  8. Configure a traffic policy. For more information see Configuring a Traffic Policy.

Configuring the Traditional SSL VPN Server

To configure the Traditional SSL VPN server to access the SSL VPN page on the Digital Airlines site, complete the following tasks:

Configuring the SSL VPN Server as a Protected Resource

To configure the SSL VPN as a protected resource, you must first create a reverse proxy for it.

  1. In the Administration Console, click Devices > Access Gateways, then click Edit > DAL.

  2. In the Proxy Service List, click New, then provide the following values:

    Proxy Service Name: Specify sslvpn.

    Multi-Homing Type: Select Path-Based. (For more information about accessing multiple resources, see Using Multi-Homing to Access Multiple Resourcesin the Novell Access Manager 3.1 SP2 Access Gateway Guide.)

    Path: Specify /sslvpn.

    Web Server IP Address: Specify the IP address of SSL VPN server. If the traditional SSL VPN server is installed with the Access Gateway Appliance, enter the localhost IP address (127.0.0.1).

    Host Header: If your SSL VPN server has a DNS name, select Web Server Host Name. Otherwise, select Forward Received Host Name.

    Web Server Host Name: Specify the DNS name of the SSL VPN server if you selected Web Server Host Name for the Host Header option.

  3. Click OK.

    The Reverse Proxy window is displayed.

  4. In the Proxy Service List, click sslvpn > Web Servers.

  5. Change the Connect Port from 80 to 8080, then click OK.

  6. Continue with Creating a Protected Resource and an Identity Injection Policy for the SSL VPN Server.

Creating a Protected Resource and an Identity Injection Policy for the SSL VPN Server

  1. In the Proxy Service List, select the sslvpn.

  2. In the Path List, select the sslvpn path, then click Enable SSL VPN.

  3. Fill in the following fields:

    Policy Container: Select Master_Container.

    Policy: Select Create SSL VPN Default Policy. In the Policy List window, click Apply Changes, then click Close.

    Name: Select Create SSL VPN Default Protected Resource.

    Your configuration should look like the following:

  4. Click OK.

    The Create SSL VPN Default Protected Resource option creates a protected resource, creates a default SSL VPN identity injection policy, then assigns it to the protected resource. When it completes, the /sslvpn Path should now indicate SSLVPN_Default as the Protected Resource.

  5. Click OK.

  6. Click Devices > Access Gateways, then click Update > OK.

  7. Click Devices > SSL VPNs, then click Update > OK.

Testing the SSL VPN Basic Configuration

Basic configuration of the SSL VPN is complete after it is protected behind your gateway and you have built your necessary identity injection policies. Test your basic configuration with the following procedure:

  1. To access the SSL VPN service, open a new browser and enter the URL for the Digital Airlines site. For this example, it is the following:

    http://am3bc.provo.novell.com

  2. Log in with any authorized username and password that is registered within your corporate domain, including the user you created in Creating a New User with a Sales Role.

  3. Click Initiate VPN Session on the Digital Airlines site.

  4. (Optional) If you have logged in by using the Internet Explorer, you might be asked to install an ActiveX control.

  5. When the SSL VPN client downloads, installs, and runs, the following page appears:

    Notice that the user’s first name (“Tom”) is injected into the header of the SSL VPN browser.

  6. Click the Logout icon, then close the browser.

Configuring a Traffic Policy

Traffic policies allow you to control access to different networks and applications protected behind the SSL VPN server. Simulate this by creating a rule that allows access to your network:

  1. In the Administration Console, click Devices > SSL VPNs, then click Edit > Traffic Policies.

  2. Click New, type sales, then click OK.

  3. Click the new, enabled sales policy, then provide the following values:

    Role: sales_role. Select the role from the Available Roles list and move it to the Assigned Roles list.

    Destination Network: This field is usually prepopulated (10.0.0.0), or you can specify the IP address of the SSL network. The network mask (255.0.0.0) is also usually prepopulated, or you can specify the value for your destination network

    Predefined Application: Any. You can also select from drop-down list to specify your network application.

    Name: Protected Network. You can also provide any descriptive name for the SSL network.

    Protocol: Any. Specifies whether the protocol is ICMP, UDP, TCP, or Any.

    Port: Port. Specifies the port number on which the service you select listens. The value of 0 allows all ports.

    Security Level: None. Specifies the minimum level of security for the client machine in order to apply this traffic policy.

    Action: Encrypt. Specifies whether the service can be encrypted or denied.

    Your rule should look similar to the following rule:

  4. Click OK to save the configuration and return to the List of Traffic Policies page.

  5. Click OK twice, then on the SSL VPNs page, click Update.

  6. Test the traffic rule:

    1. Open a new browser session and enter http://am3bc.provo.novell.com/sslvpn/login.

    2. Log in as the admin user of the Administration Console.

    3. Click Policies.

      Notice that without a sales role, the admin user has no access to the Digital Airlines network. Access is granted only when you log in with your sales credentials created in Creating a New User with a Sales Role.

    4. Log out of the SSL VPN session.

    5. Open a new SSL VPN browser session and enter http://am3bc.provo.novell.com/sslvpn/login.

    6. Log in as Tom. (See Creating a New User with a Sales Role.)

    7. Click Policies.

      Notice that the user Tom is now assigned a sales_role on the SSL VPN server because the sales policy has been applied.

For more information about traffic policies, see Configuring Traffic Policies in the Novell Access Manager 3.1 SP2 SSL VPN Server Guide.