7.4 Implementing Access Restrictions

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

7.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 Access Manager > Access Gateways > Edit.

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

  3. In the Contract 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 the Access Gateways link, 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. For this example, log in as the admin user of your Administration Console.

    The Digital Airlines site appears.

  7. 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 15 minutes), or you close all sessions of the browser.

  8. Continue with Section 7.4.2, Configuring a Role-Based Policy.

7.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 Access Manager > Identity Servers > 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 OK.

  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.0 SP4 Administration Guide.)

  1. In the Administration Console, click Access Manager > Identity Servers > 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 window, click 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. Click Update to 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 Users.

  2. 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:

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

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

  5. 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.

  6. 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 Access Manager > Access Gateways > Edit > DAL > Dallistener > Protected Resources > everything.

  2. Click Identity Injection > Manage Policies.

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

    Name: Specify Custom_Injection.

    Type: Select Access Gateway: Identity Injection.

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

  5. 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.

  6. 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 for Current User.

    Your policy should look similar to the following:

  7. Click OK twice, then click Apply Changes.

  8. Click Close.

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

  10. Click OK.

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

  12. 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’ve 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-hand corner of the page.

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

    4. Close all sessions of the browser.

  13. 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’ve 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.

  14. Continue with Section 7.4.3, Assigning an Authorization Policy to Protect a Resource.

7.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 Access Manager > Access Gateways > 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 Contract, 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 for Current User, 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. 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 using the following procedure:

    1. Open a new browser, then enter the URL of the Digital Airlines Web site you’ve 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’ve 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 7.4.4, Configuring an Identity Injection Policy for Basic Authentication.

7.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 behind 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. Expand the novell container.

  4. Browse to the LDAP Group - <your server name> object, click the link, 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 Roles and Tasks 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. The procedure depends upon whether your Web server is installed on SLES 9.x or SLEX 10.x:

Configuring the Apache Server on SLES 10.x for Basic Authentication

On SLES 10.x, 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’ve 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.

Configuring the Apache Server on SLES 9.x for Basic Authentication

On SLES 9.x, you need to modify an Apache configuration file.

  1. At the Apache server machine, add the following section to the end of the /etc/apache2/httpd.conf file:

    LoadModule ldap_module /usr/lib/apache2/mod_ldap.so
LoadModule auth_ldap_module /usr/lib/apache2/mod_auth_ldap.so

<Directory "/srv/www/htdocs/sales/">
   AuthType Basic
   AuthName "Sales"

   AuthLDAPURL ldap://127.0.0.1/o=novell?uid?sub
   AuthLDAPBindDN "cn=admin,o=novell"
   AuthLDAPBindPassword "novell"
   require valid-user
</Directory>

    The AuthLDAPURL line is configured for the internal IP address of the Administration Console. If you have installed your Web server on a different machine, replace the 127.0.0.1 address with the IP address of your LDAP user store. In this configuration, this is the IP address of the Administration Console because we are using the internal configuration store as the LDAP user store.

    The AuthLDAPBindDN and AuthLDAPBindPassword lines need to contain the DN and password of the administrator for the Administration Console. If you are using a different LDAP user store, make sure the search context (o=novell), the DN of the admin user, and the password are correct for your LDAP user store.

  2. Restart the Apache server with the following command:

     /etc/init.d/apache2 restart

  3. 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’ve 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.

  4. 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 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 Access Manager > Access Gateways > 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 II_of_Credentials for the name.

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

  5. Click OK.

    The Edit Policy page opens so you can create a rule for the II_of_Credentials policy.

  6. 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 II_of_Credentials 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’ve 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.0 SP4 Administration Guide.

    4. Close all sessions of the browser.

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

7.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.

Figure 7-4 GUI Button to Initiate an SSL VPN Session

Before performing this task, you must have the SSL VPN agent installed on either your Identity Server or on your Linux Access Gateway. Your Access Manager console should appear similar to the green state shown in Figure 7-5:

Figure 7-5 Access Console Indicating the Status of Access Manager Components

For more information about installing the SSL VPN server, see Installing SSL VPN in the Novell Access Manager 3.0 SP4 Installation Guide.

For the Digital Airlines example, you will perform the following tasks:

Configuring the SSL VPN as a Protected Resource

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

  1. In the Administration Console, click Access Manager > Access Gateways > 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 Resources in the Novell Access Manager 3.0 SP4 Administration Guide.)

    Path: Specify /sslvpn.

    Web Server IP Address: Specify the IP address of SSL VPN server.

    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 an SSL VPN Protected Resource and Identity Injection Policy.

Creating an SSL VPN Protected Resource and Identity Injection Policy

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

  2. In the Path List, select the SSLVPN check box, 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 the Access Gateways link, 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 servlet, open a new browser and enter 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 the Initiate VPN Session link.

  4. If requested, click OK to accept the certificate for the SSL VPN client.

  5. Verify that the SSL VPN client downloads, installs, and runs:

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

  6. Click Logout, 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. Simulate this by creating a rule that allows access to your network:

  1. In the Administration Console, click Access Manager > SSL VPNs > Edit > Traffic Policies.

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

  3. In the Traffic Policies list, select the sales check box, then click Enable.

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

    Role: sales_role. Specify this value in the Role field after clicking the + icon.

    Destination Network: 10.0.0.0. This field is usually prepopulated, or you can specify the IP address of the SSL network.

    Network Mask: 255.0.0.0. This field is 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.

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

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

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

  7. Test the traffic rule:

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

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

    3. In the left navigation window, 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. In the left navigation window, click Policies.

      Notice that the user “tom” is now assigned a sales_role on the SSL VPN server.

For more information about Traffic Policies, see Configuring Traffic Policies in the Novell Access Manager 3.0 SP4 Administration Guide.