2 — How NetCrusader/Web Works

[Previous] [Next] [Contents] [Index]

This chapter describes how the Security Adapter, a NetCrusader/Web component, maps the identity from an authentication mechanism to a universal identity. It contains the following sections:

2.1 How NetCrusader/Web Performs Authentication
2.2 How NetCrusader/Web Performs Authorization
2.3 How NetCrusader/Web Connects Web Servers Using Junctions

2.1 How NetCrusader/Web Performs Authentication

The NetCrusader/Web Security Adapter maps the identity from the supported authentication mechanisms to a universal identity (referred to as a NetCrusader identity). It is this identity that is checked against an Access Control List (ACL) during authorization. The benefit of such an approach is that you can have multiple authentication models feeding a single authorization model.

2.1.1 SSL with Basic Authentication

NetCrusader/Web can authenticate users by HTTP basic authentication over SSL. Basic Authentication provides username/password login services. NetCrusader uses the username/password to log the user in to the NetCrusader Security Server. The SSL protocol, as implemented by the web browser and web server, encrypts all communications, thus providing username/password privacy and integrity.

This authentication process results in the creation of credentials that can be used for access checking.

When a web browser user requests data from the web server, NetCrusader/Web first checks to see if public (unauthenticated) access is allowed:

1. The web browser user requests a URL specifying some piece of data. The URL is in the form http://<path> or https://<path> which directs the request to the secure HTTP port on the web server.

2. The web browser forwards the request to the web server.

3. The Security Adapter performs an authorization check on the requested object to see if the object is public (that is, to see if an unauthenticated user can access the requested object).

If the access policy has been set so that unauthenticated access to the requested object is allowed, the Security Adapter allows the request to proceed. In this case, this procedure is now complete.

If the access policy has been set so that unauthenticated access to the requested object is not allowed:

1. If there is no SSL connection (as would happen if the request were sent to the non-secure HTTP port rather than the HTTPS port), the Security Adapter returns the status code 403: Forbidden, which terminates the request.

2. The Security Adapter sends the browser a Basic Authentication challenge, which causes the browser to prompt the user for the user's name and password.

3. The web browser receives the challenge and prompts the user for the user's name and password.

4. Once the user enters the requested information, the web browser returns it in the form of an HTTP Basic Authentication header to the server using the encrypted SSL session.

5. The Security Adapter authenticates the user, caches a credential (along with other single sign-on attributes such as session UUID and client IP headers) and returns the single sign-on cookie to the browser.

6. Requests for access-controlled resources are evaluated according to the user's credentials.

NOTE: After a user has authenticated once to any NetCrusader/Web-enabled web server, the user will not be challenged on any subsequent requests to any other NetCrusader/Web protected web server in the same security domain. This is a feature of Web Single Sign-On (WSSO) as of NetCrusader/Web 4.0.

2.1.2 Forms-Based Logon

With the NetCrusader/Web Authorization Object, you can use an HTML form to acquire the user's name and password. The form calls an Active Server Page (ASP) that uses the Authorization Object to pass the user's name and password to the Security Adapter for authentication.

NetCrusader/Web authentication using forms-based logon is similar to authentication using Basic Authentication with the following important differences:

• With Basic Authentication, you have no control over the dialog box that asks for username and password. With NetCrusader/Web forms-based login, you can customize the message that asks for username and password, even placing it within a web page.

• With Basic Authentication, the Basic Authentication header is transmitted each time. With forms-based logon, only a cookie is transmitted.

• With forms-based logon, you can control the user session, logging the user out to force reauthentication as your application requires.

NetCrusader/Web can provide full authorization services when authentication is provided by certificates exchanged over SSL.

Authentication and authorization occurs as follows:

1. The web browser user requests a URL specifying some piece of data. The URL is in the form https://<path> which directs the request to the secure HTTP port on the web server.

2. The web browser forwards the request to the web server.

3. If the server configuration either enables or requires user certificates, the server sends a message to the browser requesting a user certificate.

4. The browser prompts the user to select a certificate. The user selects the certificate, and the browser returns it to the web server.

5. The Security Adapter performs an authorization check on the requested URL to see if the object is public (that is, to see if an unauthenticated user can access the requested object).

   If the access policy has been set so that unauthenticated access to the requested object is allowed, the Security Adapter allows the request to proceed. In this case, this procedure is now complete. Client certification is not required.

6. If the access policy has been set so that unauthenticated access to the requested object is not allowed, the Security Adapter attempts to establish a session with the user as described in the following steps.

   If there is no certificate, the certificate is invalid, or there is no NetCrusader identity mapped to the certificate:

   • If the server requires certificates, access is denied, the Security Adapter returns the status code 403: Forbidden, and no further processing occurs.

   • If the server accepts certificates, the user is issued a Basic Authentication challenge.

7. If there is a valid certificate and a NetCrusader identity is mapped to the certificate, requests for access-controlled resources are evaluated according to the user's credentials.

Both Basic Authentication and forms-based authentication result in a session cookie being sent to the browser. The single sign-on feature looks for that cookie and uses it to create a credential on the local machine, even if the user has never visited that machine before, provided the user has successfully authenticated to another server and the cookie resulting from that authentication is still valid.

2.1.5 Third-Party Authentication

With configurable header DN mapping, you can fit third-party authentication proxy servers and filters between the user and the NetCrusader/Web Security Adapter. The third-party authentication service authenticates the user. The NetCrusader/Web Security Adapter then applies NetCrusader authorization to the authenticated user by mapping a DN it receives from a specified header.

2.1.6 Summary

NetCrusader/Web supports many different authentication schemes. Table 2-1 summarizes the ones just described, noting which software component is actually performing the authentication.

Table 2-1: Summary of Authentication Schemes

Scheme	Where Authentication Occurs
SSL with Basic Authentication	NetCrusader/Web Security Adapter
SSL with Client Certificates	The web server's SSL filter
Forms-Based Logon	The NetCrusader/Web Authorization Object
NetCrusader/Web SSO	The NetCrusader/Web Authorization Object
Third-Party Authentication or Proxy Servers and Filters	At the third-party server

2.2 How NetCrusader/Web Performs Authorization

While the authentication process involves verifying the identity of a user, authorization provides a way to control exactly which operations a user can perform on a given resource.

The NetCrusader/Web Security Adapter obtains the user's identity during the authentication process. During the authorization process, it performs the authorization check on a requested object by referring to the object's ACL. If the ACL grants the requesting user permission to perform the requested operation, then the authorization check passes.

Depending on the goals of your application, you can implement authorization checks using one of the following methods:

• You can enable the Security Adapter's authorization checking to control access to files and directories in the web server's document tree. The Security Adapter uses the default ACL model, which is designed to protect static documents in a document tree, and contains permissions such as read, traverse, execute, and write.

• You can program your web application to implement custom ACL models and access checking. Custom ACL models allow the developer to define a set of permissions appropriate for the objects served by the application. (For more information on custom ACL models, see Section 3.1.2 on page 28.)

The Security Adapter performs default access checking using the default ACL model. (For more information on the default ACL model, see Section 3.1 on page 27.)

Administrators use NetCrusader Commander to assign specific user and group permissions to application objects. Commander accesses the application ACLs to make the necessary changes. Administrators can also use NetCrusader Commander to create groups of users to make ACL management easier. Group and user information is stored in the NetCrusader Security Server. For more information on Commander, see the Commander online help.

2.2.2 ACL Evaluation

This section describes how a NetCrusader/Web server component evaluates ACLs.

First, Section 2.2.2.1 on page 20 and Section 2.2.2.2 on page 20 describe how the server determines which ACL to apply to a requested object.

Then, Section 2.2.2.3 on page 21 describes how the server extracts the appropriate permissions from the ACL. (For more information on ACLs, see Chapter 3.)

2.2.2.1 How the Server Determines Which ACL to Apply

When NetCrusader/Web evaluates an ACL, it "walks" up the object tree, starting at the target object, until it encounters an object or container for which an explicit ACL exists. It evaluates the request based on this ACL. However, if the target object has an explicit (non-inherited) ACL, no "walking" occurs.

ACL evaluation for the default ACL model is somewhat more complex in that it uses the traverse function, which is described in the next section.

2.2.2.2 Role of the Traverse Permission

The traverse permission determines whether or not a user has permission to traverse a container object in the path to the target object. You can use traverse to easily restrict access to certain branches of the tree. Traverse is included in the default ACL model, and is available for use in custom ACL models.

The traverse permission affects ACL evaluation as follows:

1. When the Security Adapter receives a request for object access, it evaluates each explicit ACL in the path to the target object, starting at the root of the object tree. This check determines whether all explicit ACLs in the path allow the requesting user traverse access (permission to traverse the container object on the way to the target object).

2. If all explicit ACLs in the path allow traversal, then the server component "walks back" up the object tree, starting at the target object, until it encounters an object for which an explicit ACL exists. It evaluates the request based on this ACL.

NOTE: To allow access to an object, you need to set the traverse permission on all containers in the object's hierarchy, including the container in which the object resides. Setting a less restrictive ACL on the target object does not open access to the object if the traverse privilege is turned off for the container holding the object or for containers higher in the object's hierarchy.

2.2.2.3 How NetCrusader Extracts Requesting Users' Permissions

The following is a simplified description of how NetCrusader/Web extracts the requesting user's permissions from an ACL:

1. NetCrusader/Web processes the ACL entries that identify the user.
   • If one of these entries matches the user's identity, NetCrusader/Web uses the permissions listed in this entry.

   • If there is no match, NetCrusader/Web proceeds to the next step.

2. NetCrusader/Web processes the ACL entries for groups. It checks to see if any of the listed groups contain the identified user.
   • If the user is a member of one and only one group listed in the ACL, the server component uses the permissions listed for this group.

   • If the user is a member of multiple groups listed in the ACL, the server component ORs the permissions for these groups and uses the resulting set of permissions.

   • If the user is not a member of any of the groups listed in the ACL, NetCrusader/Web proceeds to the next step.

3. NetCrusader/Web chooses which permissions to use:
   • If the user is authenticated, NetCrusader/Web uses the any_other permissions.

   • If the user is unauthenticated, NetCrusader/Web ANDs the any_other permissions with the unauthenticated mask and uses the resulting set of permissions.

The important points of ACL evaluation are:

• User permissions override any group permissions for that user.

• If there is no entry for the user in an ACL, NetCrusader/Web uses the group permissions, if any, for that user.

• If a user is a member of multiple groups, and any one of these groups allow access, access is granted.

• If there is no entry for a group that contains the user, that user is assigned the any_other permissions.

• If the user is unauthenticated, that user is assigned the any_other permissions ANDed with the unauthenticated mask. Both any_other and unauthenticated must allow access for access to be granted to the user.

A NetCrusader/Web junction is a mechanism to proxy URL requests for another web server. Junctions make it possible to add NetCrusader security to an environment that runs non-secure web servers.

You can use a junction to:

• Add authentication and access control to a web server that has no access control, or to one that cannot run the Security Adapter.

• Control access by your users to another company's web server.

• Provide custom authentication for a downstream server by customizing the authentication header that is sent by a NetCrusader/Web junction to target servers. (For more information, see the Security Adapter configuration wizard online help.)

The ability to connect to a standard web server through a NetCrusader/Web junction server makes it possible for you to add a front line of NetCrusader authentication and access control to the standard web servers that are currently deployed in your web site.

2.3.1 Junction Servers and Target Servers

The web server on which you create a junction is referred to as the junction server. The junction server must have the NetCrusader/Web Security Adapter installed. The web server that you access through the junction is referred to as the target server.

Figure 2-1: Junction Servers and Target Servers

You create a junction by "grafting" the target server's document tree to a branch of the junction server's document tree. In effect, you join the directory of the target server to the directory of the junction server.

The point where the two directories join is called the junction name. The junction name, assigned by the administrator of the junction server, is a logical name that represents the root of the target server's document tree (see Figure 2-2).

Figure 2-2: Document Tree Graft with Junctions

The target server does not require the Security Adapter to be installed. You can access a target server, through the junction server, from a standard web browser.

2.3.2 How Junctions Work

You use a standard URL to refer to a resource accessed through a junction. For example, the URL http://darwin/Mktg/DataSheets/index.html (or https://...) points to a resource described in Figure 2-2 on page 23.

Figure 2-3 explains the individual parts of this URL.

Figure 2-3: Parts of the URL to a Junction

When the junction server detects the junction name DataSheets in the incoming URL, it strips off all elements of the URL up to and including the junction name (darwin/Mktg/DataSheets), then forwards the remaining URL string (in this case, index.html) to the target server to be fulfilled.

If the requesting application or browser has adequate permissions, the target server returns the index.html page back to the junction server.

The junction server filters the page for references back to the target server, to ensure that all links to the target server defined in the page are routed back through the junction server.

The junction server filters the page by scanning it for all hyperlinks (relative or absolute) back to the target server. For each hyperlink, the junction server replaces the name of the target server with the name of the junction server, followed by the junction pathname.

There are some limitations to what the junction server can filter. For more information, see the NetCrusader Installation and Operation Guide.

After the page is filtered, the junction server returns the page to the browser or NetCrusader/Web Client. The detection and resolution of the junction name and the forwarding of the URL request to the target server are transparent to the user.

2.3.3 Connecting a Junction Server to a Target Server

Using the Security Adapter configuration wizard, you can connect a junction server to any standard web server. The junction server communicates with the target server via the HTTP protocol using non-secure TCP/IP.

The security of this type of junction depends on the browser access and the ACL. For example, if a user accesses the junction using SSL, access through the junction is more secure than if the user accesses the junction with no encryption. If access is configured to allow only authenticated users, access through the junction is more secure than if unauthenticated users were allowed access.

[Previous] [Next] [Contents] [Index]

To make comments or ask for help, contact support@entegrity.com.

Copyright © 1996-2002 Entegrity Solutions Corporation & its subsidiaries