Scenario: Using the IP authentication feature for access control by URL

About this scenario

The deployment in this scenario can be used in an organization in which users access URLs that include keys that the application servers map to specific users, for example, to a URL in the form

protocol://host/object?key=...

In this type of scenario, the appliance is configured to send the URL that the user requested to the RADIUS servers. The RADIUS servers and application servers are responsible for all activity related to authentication and determining the URLs that the users can view. All information that the application server needs is encoded in the URL. The NetCache appliance is never aware of the identity of the user who is making a request (unlike the previous scenario), and the user is never prompted for a user name and password.The RADIUS server only informs the appliance about the URL to serve.

Deployment illustrated

The following illustration shows an example in which the application server contains the components to authenticate and authorize users.

The following table provides details about the preceding illustration.

Stage	Description
1	The client logs in to a Web server (or an application server).
2	The Web server uses the IP address and user name to obtain a key from the database.
3	The Web server returns the URL and the key to the client.
4	The client opens the URL, which includes the key.
5	The NetCache appliance sends the client IP address and the requested URL to the RADIUS server.
6	The RADIUS server might process the IP address and URL itself or, as the previous illustration shows, send it on to the application server.
7	The application server obtains the key from the URL and the IP address from the request and checks the database to determine if the key is valid for the IP address. This is the authentication step. Note The key in the URL is meaningful only to the RADIUS server or application server that is deployed in front of the application server. The key is opaque to the NetCache appliance.
8	If the key is valid, the database returns the user name associated with the IP address. If the key is not valid, the user's request is rejected and the user is redirected to a URL other than the requested URL, for example, a stream that you have provided that explains the rejection.
9	If the key is valid, the IP address, user name, and URL are sent to the authorization service, for example, a billing service.
10	The service attempts to authorize the user. For example, a billing service might determine whether the user's account has enough money to allow the user to view the requested stream. The URL that the application server and then the RADIUS server return to the NetCache appliance is determined by whether the user is authorized. If the user is authorized, the URL passed to NetCache is for the requested content. If the user is not authorized, the URL passed to NetCache is of another URL you have provided, for example, the URL of a stream explaining the rejection.
11	The RADIUS server instructs the NetCache appliance to serve the URL to the client.
12	The NetCache appliance serves the content, as instructed by the RADIUS server.

Planning for configuration

Configuration of the NetCache appliance and the RADIUS server involves the following.

Configuration requirements for the appliance

Configure the following on the Setup tab > Authentication > RADIUS page:

Basic RADIUS configuration on the appliance
Use the IP Authentication Protocol option and IP Authentication Password option (on the Extensions tab of the RADIUS page)
Send URL option
The Send URL option enables the appliance to send the URL to the RADIUS server, which enables this type of deployment to function.

Programming requirements for the RADIUS server

The RADIUS server developer must program the RADIUS server to

Use the password configured in the IP Authentication Password option on the appliance to connect to the appliance
Recognize the Vendor-Netapp-1 attribute
Recognize the Auth-type value in Vendor-Netapp-2 and recognize that type as a 1 or 2
Recognize either Vendor-Netapp-4 or Vendor-Netapp-5 (not both) to redirect denied users

See Chapter 5, API--NetApp RADIUS extensions, for more details.