Deployment Guide

authentication server, and waits for the server’s reply. The exact steps taken here depend on the
selected programming language, operating system, and the type of authentication server selected.
After the authentication server has verified the user and potentially returned an access control role to
assign to the user, the script needs to tell the appliance that the user is authenticated and indicate the
role to assign to the user. The ECP informs the appliance by putting the information in the query string
of a redirection response. The redirection response sends the client’s browser to a web server running
on a specific interface and port of the appliance that hosts the client’s session. The client’s browser
normally sends a redirected request immediately and automatically.
The redirection response does not need to be signed. If it is not signed, the appliance does not use the
session attributes that are included in the redirected request. Instead, the appliance expects the
redirected request to include a user ID and password. These credentials are sent to a RADIUS server in a
standard RADIUS Access-Request. The redirected request is considered invalid if:
• The redirected request is not signed, and
◦ The redirected request does not contain a user ID or password, or
◦ The WLAN Service the client is using does not have at least one RADIUS server configured for
authentication.
An invalid redirected request is sent to a standard error page. The error page cannot be configured at
this time.
Compose the Redirection Response Sending the Browser back to the
Appliance
Signing the Redirection to Extreme Campus Controller
Signing the redirection response is a similar process to calculating the expected signature for a URL that
was received at the ECP. In fact, it is the same algorithm, but the inputs to the algorithm are not taken
from the request as the request is under construction.
There are only two steps involved in signing the redirection response from the ECP:
1. Compose the pre-signed redirection URL to be signed.
This step consists of building the request URL as described in Case 1: When a RADIUS Server
Authenticates the Client on page 107 or Case 2: When the ECP is the Final Authority on page 108
but leaving o the X-Amz-… parameters that are required for the signature.
2. Sign the URL, adding all parameters to the URL that are required to sign it.
This step consists of generating the signature, then appending all the X-Amz-… parameters used to
the URL. This processing is described in Building the String to Sign on page 101, Creating the Signing
Key on page 103, and Creating the Signature and Verifying the Request on page 105.
Related Topics
Case 1: When a RADIUS Server Authenticates the Client on page 107
Case 2: When the ECP is the Final Authority on page 108
Compose the Redirection Response Sending the
Browser back to the Appliance External Captive Portal on a Third-Party Server
106 Extreme Campus Controller Deployment Guide for version 5.46.03