Introduction

Administrators can configure single sign-on (SSO) for Web access of any application server using Form Fill in Novell Access Manager 3.0. This document is intended to help system administrators in configuring SSO for Web access of the iFolder server.

This document does not cover installation and setup of Novell Access Manager. For information on how to install and setup Novell Access Manager 3.0, see: http://www.novell.com/documentation/novellaccessmanager/

Prerequisites

1. The Novell Acceess Manager components, namely, Administration Console, Identity Server and Access Gateway must be installed and configured.

2. The iFolder 3.6 server is installed, configured, and is accessible through the Web using the URL https://<ifolder-server-ip>/ifolder/

Configuration Steps

1. Create a path-based multi-homing service /ifolder.

2. Specify the iFolder Web server IP address as the Web server IP address for this resource.

The iFolder Web access can then be accessible using this URL:
https://<accessgateway-published-DNS-Name>/ifolder/.

For example, https://lag-11.isecurest.com/ifolder - where lag-11.isecurest.com is the published DNS name of Access Gateway. This example is used throughout this document.

Figure 1: Creating a path-based multi-homing service

Click to view.

Note: You can also create a domain-based multi-homing service. The iFolder Web access URL then will be https://ifolder.lag-11.isecurest.com.

2. Enable the Connect Using SSL check box in the Web Servers tab.

Figure 2: Web server specific configuration

Click to view.

Note: Web access service listens on SSL port 443 in the iFolder Application Server.

This automatically changes the connection port to 443.

3. Select either the iFolder Server certificate or the Do not verify option as the Web Server Trusted Root.

4. Click the icon next to the drop-down list to auto-import the certificate from the iFolder server.

5. Create a protected resource /ifolder/* corresponding to the the iFolder Web Access URL.

6. Select a suitable authentication contract for this resource.

Figure 3: Creating a protected resource

Click to view.

Note: The protected resource can be configured as /ifolder/*, as the ifolder Web access is available at https:///ifolder/

7. Create a Form Fill policy and attach to the protected resource ifolder-res.

Figure 4: Initial Sample Form-fill policy

Click to view.

Note: When the user requests for URL https://lag-11.isecurest.com/ifolder/, the Web server returns the following URL for login:

https://lag-11.isecurest.com/ifolder/Login.aspx?ReturnUrl=/ifolder/iFolders.aspx

This indicates that the CGI criteria used in this policy is "Login.aspx?ReturnUrl=/ifolder/iFolders.aspx".

For more information on how to select a typical CGI criteria, see:
http://www.novell.com/documentation/novellaccessmanager/adminguide/index.html?page=/documentation/novellaccessmanager/adminguide/data/b11gc7i.html

With the configuration steps mentioned above, the Web Access for iFolder can now be accessed at https://lag-11.isecurest.com/ifolder/

Problems and Solutions

Scenario 1:

User accesses iFolder Web Access through this URL:
<a href="https:///ifolder/Login.aspx">https:///ifolder/Login.aspx

In our example, we created a Form Fill policy with the CGI criterion as ReturnUrl=/ifolder/iFolders.aspx. When the user accesses the iFolder Web Access page through the URL https://lag-11.isecurest.com/ifolder/Login.aspx, the Web server returns the same URL.

As the form fails to match the CGI criterion, the Access Gateway fails to fill the login form of the iFolder server. The user must specify the URL as https://lag-11.isecurest.com/ifolder, so that the Web Server returns a form with a URL as https://lag-11.isecurest.com/ifolder/Login.aspx?ReturnUrl=/ifolder/iFolders.aspx. This matches with the CGI criteria specified in our example.

The CGI criterion must to be modified to handle this situation. If you compare the following two URLs:

• https://lag-11.isecurest.com/ifolder/Login.aspx

• https://lag-11.isecurest.com/ifolder/Login.aspx?ReturnUrl=/ifolder/iFolders.aspx

then the common part in the URL that can be used match with the CGI criteria is ?Login.aspx?

With the modifications, the new Form Fill policy will look as follows:

Figure 5: Modified FormFill Policy for success case

Click to view.

Note: The CGI criteria is modified as "Login.aspx"

Scenario 2

Users access iFolder Web Access through this URL:
https:///ifolder/iFolders.aspx

Now that the CGI criteria is modified as ?Login.aspx?, the following scenario might occur:

When the user accesses the iFolder Web Access page using the URL
https://lag-11.isecurest.com/ifolder/iFolders.aspx, the Web Server returns the URL
https://lag-11.isecurest.com/ifolder/Login.aspx?ReturnUrl=/ifolder/iFolders.aspx

As the CGI criteria is "Login.aspx", the returned URL matches with the CGI criteria. The Access Gateway successfully fills the Login form, and the user is provided access to iFolder.

Scenario 3

The Administrator configures the CGI criteria as iFolders.aspx. In this case, the CGI criterion will match when the user accesses ifolder using any of the following URLs:

• https://lag-11.isecurest.com/ifolder/iFolders.aspx

• https://lag-11isecurest.com/ifolder

In both the above cases, iFolder server returns the following URL:

https://lag-11.isecurest.com/ifolder/Login.aspx?ReturnUrl=/ifolder/iFolders.aspx
This URL matches with the CGI criterion ?iFolders.aspx? and theoretically, the user should be given access to iFolder.

However, after providing the credentials, the browser goes into an infinite loop. What causes this looping?

For our example, we had configured /ifolder/* as the path for the protected resource ifolder-res enabled for the Form Fill policy( Refer to Figure 3). With this configuration, all the forms inside the /folder path are scheduled to be filled by the Access Gateway.

Let's analyze the request-response path and the Form Fill scheduling by the Access Gateway for this configuration to understand the root-cause of this looping.

The Request-Response path is as follows:

1. The Access Gateway forwards the browser request https://lag-11.isecurest.com/ifolder/ to the iFolder Web Access Server.

2. The iFolder Web Access Server redirects it to /ifolder/Login.aspx?ReturnUrl=/ifolder/iFolders.aspx for webserver authentication.

3. Access Gateway completes the Form Fill and send it to the iFolder Web Server through POST.

4. The looping issue happens because the Web Server returns another form /ifolder/iFolders.aspx which matches the Form Fill scheduling of Access Gateway as well as the matching criteria specified in Form Fill policy.

5. Access Gateway tries to Form Fill and POST the form to the Web Server. The Web Server returns the same form back, as POST is not required for this form.

Steps 4 and 5 cause an infinite loop. To prevent looping in this particular case, the configuration can be modified in such a way that the Linux Access Gateway does not schedule ifolder/iFolders.aspx for Form Fill. You can achieve this by configuring the protected resource as /ifolder/Login.aspx instead of /ifolder/*.

However, this solution fails in Scenario 1.

The Form Fill policy given in Scenario 1 remains the final policy as it takes care of all the three scenarios.

Enhancing the iFolder Form Fill Policy

There are two more scenarios that can enhance the Form Fill policy:

a) The user logs out from iFolder Web Access.

b) The user provides wrong credentials.

User Logs Out from iFolder Web Access

When the user logs out from iFolder Web Access, the user should also be logged out of Access Manager. How does Access Gateway know that the user has logged out of the iFolder? To determine this, Access Gateway has to match the iFolder Logout page. When the logout happens the iFolder server redirects the user to the URL
https:///ifolder/Login.aspx?Message=You are now logged out of iFolder.
The Access Gateway can include this URL for CGI matching. The users are then logged out of Access Manager when they log out of iFolder.

The following 'Form Login Failure' policy, in addition to the previous Form Fill success policy (Figure 5), meets all these criteria:

Figure 6: Login Failure policy for user logout

Click to view.

Note: The CGI Matching criteria is:
Login.aspx?Message=YouLogin.aspx?Message=You are now logged out of iFolder

The users are logged out of Access Manager redirecting to the URL:
https://lag-11.isecurest.com/AGLogout

User Provides Wrong Credentials

When the user provides wrong user name or wrong password during login, the user should be asked to log in again. There are two cases to discuss here:

1. The user name and password entered is invalid for both Access Manager and the iFolder Server.

2. The user name and password entered are allowed login to Access Manager, but they are invalid for the iFolder Server.

The first case is handled by Access Manager by default and does not require any modification in the Form Fill policy.

The second case has to be handled in Form Fill policy. If the Access Gateway identifies that the user is invalid for iFolder server, then the Access Gateway must match the page returned by the iFolder Server during an invalid login attempt. When the login fails in iFolder server, it redirects the user to a URL https:///ifolder/Login.aspx?ReturnUrl=/ifolder/iFolders.aspx. As the URL is the same as the one matched by the Linux Access Gateway for logging in, this cannot be used as login failure CGI matching criteria.

The other criterion available in Form Fill policy is the Page Matching Criterion. When the login fails in iFolder server, it returns an HTML page with the text "Please re-enter your username and password" - which is not there in the case of login. This is the candidate for Page Matching criteria in case of login failure.

If the Access Gateway discovers that the user is invalid, the Form Fill policy should redirect the user to log in again. With the current design of Novell Access Manager, this is not possible, as the invalid user for iFolder server is a valid logged in user for Access Manager. So, when the user is redirected to log in again, Access Gateway matches the login page and Form Fill again with the invalid user name and password - and it ends in a loop.

The only option available with the current design is to redirect the user to /AGLogout, which will log the user out from Access Manager. The user then must log in again to get access to iFolder.

A sample policy that can be added to the other Form Fill policy is shown below:

Figure 7: Login Failure policy for invalid user

Click to view.

Note: The Page Matching criterion used in the above form failure policy is "Please re-enter your username and password".

Note: If the Form Fill policy is configured using shared secrets, login failures can be handled by redirecting to the login page. In case of shared secrets, the failure policy deletes the shared secrets before redirection; hence, the looping does not happen. Configuring shared secrets is outside the purview of this document.

The steps to configure shared secrets in Form Fill policy are available at:
http://www.novell.com/documentation/novellaccessmanager/adminguide/index.html?page=/documentation/novellaccessmanager/adminguide/data/b11gc7i.html

Conclusion

This document helps system administrators in setting up an iFolder 3.6 Web Access with Novell Access Manager 3.0. Some of the methods used to identify a form in the Form Fill success policy as well as the failure policies can be re-used for any other web based forms, especially in the following cases:

• User logout of the application

• Login failure

The final Form Fill policy for your iFolder server's Web access should contain three policies:

1. Modified Form Fill Policy for success case (Figure 5)

2. Login Failure policy for user logout (Figure 6)

3. Login Failure policy for invalid user (Figure 7)